Update email-id to a personal one, as I have changed employment.
Signed-off-by: NJassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Although Documentation explicitly mentions the expectations, the comment in
header can be lead to different expectation so clear up the confusion
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

same issue as commit 7f5ae355:
"Without DMA_PRIVATE the driver is not able to allocate more than one channel.
Since it uses dma_get_any_slave_channel that calls private_candidate, the
second allocation fails at
/* some channels are already publicly allocated */
"
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The dma-cells value in the example was 2 instead of 1.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Lock taken when entering the function but unlock missing before it
returns.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The total size of the transfer was wrong in at_xdmac_prep_slave_sg()
resulting in bad computation of the transfer residue by
at_xdmac_tx_status().
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

According to the Atmel eXtended DMA controller datasheet, requesting a
DMA transfer flush for a channel is only revelant when this transfer is
source peripheral synchronized.

So we have to check this condition before requesting a channel flush by
writing the channel bit into the Global channel SoftWare Flush (GSWF)
register then waiting for flush to complete by monitoring the end of
Flush Interrupt Status (FIS) bit in the Channel Interrupt Status (CIS)
register.

Indeed, for non source peripheral synchronized transfer, writing the
channel bit into the GSWF register does nothing. Especially, the FIS bit
is never set into the CIS register. The former code looped forever
waiting for this bit to be set.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Remove chancnt affectation since it is done in dma_async_device_regiser.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

_relaxed version of readl and writel are not implemented on all
architecture so COMPILE_TEST has to be removed in order to not cause
some build failures.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

As documented in printk-formats.txt the dma_addr_t should be printed with
%pad specfiers. This way it works on all archs.

 make.cross ARCH=s390

All warnings:

   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_slave_sg':
>> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:621:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:628:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),
       ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
>> drivers/dma/at_xdmac.c:663:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan), "%s: buf_addr=0x%08x, buf_len=%d, period_len=%d, dir=%s, flags=0x%lx\n",
     ^
>> drivers/dma/at_xdmac.c:690:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:709:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:716:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),

>> drivers/dma/at_xdmac.c:731:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan),
     ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
>> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan), "%s: src=0x%08x, dest=0x%08x, len=%d, flags=0x%lx\n",
     ^
>> drivers/dma/at_xdmac.c:765:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan), "%s: remaining_size=%u\n", __func__, remaining_size);
                              ^
>> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
      dev_dbg(chan2dev(chan),
      ^
>> drivers/dma/at_xdmac.c:845:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/at_xdmac.c:852:4: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
       dev_dbg(chan2dev(chan),
       ^
   drivers/dma/at_xdmac.c: In function 'at_xdmac_tx_status':
>> drivers/dma/at_xdmac.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
     dev_dbg(chan2dev(chan),
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

As documented in printk-formats.txt the size_t should be printed with
%zu/%zd specfiers. This way it works on all archs.

make.cross ARCH=avr32

All warnings:

   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_cyclic':
>> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 6 has type 'size_t'
>> drivers/dma/at_xdmac.c:663: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
   drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_dma_memcpy':
>> drivers/dma/at_xdmac.c:765: warning: format '%d' expects type 'int', but argument 7 has type 'size_t'
>> drivers/dma/at_xdmac.c:794: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'
>> drivers/dma/at_xdmac.c:815: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t'
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This driver uses read_relaxed and writel_relaxed to read, write to IO
memory. the config defines COMPILE_TEST so gets compiled on different archs.
This causes issue as few archs like x86 etc don't define it.
So use readl/writel which is defined in all archs
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

drivers/dma/at_xdmac.c:702:3-4: Unneeded semicolon

 Removes unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.

drivers/dma/k3dma.c:790:12: warning: 'k3_dma_suspend' defined but not used [-Wunused-function]
drivers/dma/k3dma.c:806:12: warning: 'k3_dma_resume' defined but not used [-Wunused-function]
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NZhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SET_SYSTEM_SLEEP_PM_OPS are only used
when the CONFIG_PM_SLEEP is enabled.

drivers/dma/sirf-dma.c:838:12: warning: 'sirfsoc_dma_pm_suspend' defined but not used [-Wunused-function]
drivers/dma/sirf-dma.c:879:12: warning: 'sirfsoc_dma_pm_resume' defined but not used [-Wunused-function]
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch simply adds a new DMATYPE for SAI which's included
in i.MX6 Solo X.
Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch fixes a race condition about a list of shdma-base driver.
If we don't apply this patch, a dma slave driver (especially a usb
peripheral driver) may not be able to start the transfer.

If a dma slave driver has a callback, __ld_cleanup() will call
the callback before this driver removes the list. After the callback,
since the return value of __ld_cleanup() is not zero,
shdma_chan_ld_cleanup() calls __ld_cleanup() again. And, __ld_clean()
will removes the list.

At this time, if a dma slave driver calls dmaengine_submit() before
this driver removes the list, this driver will set schan->pm_state
to SHDMA_PM_PENDING in shdma_tx_submit(). And then, even if a dma
slave driver calls dma_async_issue_pending(), this driver don't
start the transfer because the schan->pm_state is SHDMA_PM_PENDING
in shdma_issue_pending().

So, this patch adds a new condition in __ld_clean() to check if the
schan->pm_state is SHDMA_PM_PENDING or not.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Add compatible string for BAM v1.3.0 in the DT bindings documentation. Mentioned
a few more SoCs which have BAM v1.4.0 in them.
Reviewed-by: NKumar Gala <galak@codeaurora.org>
Reviewed-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

We currently have register offset information only for BAM IPs with revision
1.4.0. We add register offset table entries for the legacy (v1.3.0) version
of BAM IPs found on SoCs like APQ8064 and MSM8960.

The register offset table pointers are stored in DT data corresponding to the
BAM IP version specified in the compatible string.
Reviewed-by: NKumar Gala <galak@codeaurora.org>
Reviewed-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The BAM DMA IP comes in different versions. The register offset layout varies
among these versions. The layouts depend on which generation/family of SoCs they
belong to.

The current SoCs(like 8084, 8074) have a layout where the Top level registers
come in the beginning of the address range, followed by pipe and event
registers. The BAM revision numbers fall above 1.4.0.

The older SoCs (like 8064, 8960) have a layout where the pipe registers come
first, and the top level come later. These have BAM revision numbers lesser than
1.4.0.

It isn't suitable to have macros provide the register offsets with the layouts
changed. Future BAM revisions may have different register layouts too. The
register addresses are now calculated by referring a table which contains a base
offset and multipliers for pipe/evnt/ee registers.

We have a common function bam_addr() which computes addresses for all the
registers. When computing address of top level/ee registers, we pass 0 to the
pipe argument in addr() since they don't have any multiple instances.

Some of the unused register definitions are removed. We can add new registers as
we need them.
Reviewed-by: NKumar Gala <galak@codeaurora.org>
Reviewed-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The A23 SoC has the same dma engine as the A31 (sun6i), with a
reduced amount of endpoints and physical channels. Add the proper
config data and compatible string to support it.

A slight difference in sun8i is an undocumented register needs
to be toggled for dma to function.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch adds support for hardware parameters tied to compatible
strings, so similar hardware can reuse the driver.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

When platform_driver_probe() is not used, sdma_probe() can be called
by bind/unbind via sysfs. In addition, sdma_init() can be called by
sdma_probe(). Thus, __init annotation should be removed from sdma_init(),
Also, this patch fixes section mismatch warning.

WARNING: drivers/dma/built-in.o(.text+0xd6e4): Section mismatch in reference from the function sdma_probe() to the function
.init.text:sdma_init()
The function sdma_probe() references
the function __init sdma_init().
This is often because sdma_probe lacks a __init
annotation or the annotation of sdma_init is wrong.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Commit f6f2421c removed pl330_info structure by embedding it into
pl330_dmac structure, but did not ensure that the dmac->ddma.dev
pointer gets initialised before use. When dma_alloc_coherent() gets
called on arm64 a WARN() gets triggered due to dev being NULL.

------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at arch/arm64/mm/dma-mapping.c:49 __dma_alloc_coherent+0xd0/0xe0()
Use an actual device structure for DMA allocation
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #5
Call trace:
[<ffffffc000087f24>] dump_backtrace+0x0/0x130
[<ffffffc000088064>] show_stack+0x10/0x1c
[<ffffffc0004e8af8>] dump_stack+0x74/0xb8
[<ffffffc0000aa444>] warn_slowpath_common+0x8c/0xb4
[<ffffffc0000aa4b8>] warn_slowpath_fmt+0x4c/0x58
[<ffffffc000092580>] __dma_alloc_coherent+0xcc/0xe0
[<ffffffc000092734>] __dma_alloc_noncoherent+0x64/0x158
[<ffffffc000312cd8>] pl330_probe+0x650/0x8f0
[<ffffffc00030e1d4>] amba_probe+0xa0/0xc8
[<ffffffc000350240>] really_probe+0xc4/0x22c
[<ffffffc0003504b4>] __driver_attach+0xa0/0xa8
[<ffffffc00034e5fc>] bus_for_each_dev+0x54/0x98
[<ffffffc00034fd8c>] driver_attach+0x1c/0x28
[<ffffffc00034fa08>] bus_add_driver+0x14c/0x204
[<ffffffc000350b84>] driver_register+0x64/0x130
[<ffffffc00030dcf8>] amba_driver_register+0x50/0x5c
[<ffffffc0006a60d0>] pl330_driver_init+0x10/0x1c
[<ffffffc0000814ac>] do_one_initcall+0x88/0x19c
[<ffffffc00068dab8>] kernel_init_freeable+0x140/0x1e0
[<ffffffc0004e5e18>] kernel_init+0x10/0xd4
---[ end trace 76f2d47a444e523e ]---
(NULL device *): dmac_alloc_resources:1821 Can't allocate memory!
(NULL device *): Unable to create channels for DMAC

This patch will also ensure that any dev_err messages are printed
with the appropriate device name.
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NAndrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch modifies the icg field to match the description
as mentioned in the DMA Linux framework.
Signed-off-by: NSrikanth Thokala <sthokal@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch adds a sanity check to see if frame_size is 1.
Signed-off-by: NSrikanth Thokala <sthokal@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The segment list in a descriptor should be checked for empty, else
it will try to access invalid address for the first call.  This
patch fixes this issue.
Signed-off-by: NSrikanth Thokala <sthokal@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

There is no need to init .owner field.

Based on the patch from Peter Griffin <peter.griffin@linaro.org>
"mmc: remove .owner field for drivers using module_platform_driver"

This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway."
Signed-off-by: NKiran Padwal <kiran.padwal@smartplayin.com>
[for nvidia]
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

chanctnt is already filled by dma_async_device_register, which uses the channel
list to know how much channels there is.

Since it's already filled, we can safely remove it from the drivers' probe
function.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>