Kconfig and Makefile conflicts so put them in right order (sprd ones after
stm ones)
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The used 0x1f mask is only valid for am335x family of SoC, different family
using this type of crossbar might have different number of electable
events. In case of am43xx family 0x3f mask should have been used for
example.
Instead of trying to handle each family's mask, just use u8 type to store
the mux value since the event offsets are aligned to byte offset.

Fixes: 42dbdcc6 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Commit adfa543e ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605Signed-off-by: NAdam Wallis <awallis@codeaurora.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This reverts commit 847449f2: ("dmaengine: rcar-dmac: use TCRB instead
of TCR for residue") as it breaks small serial console.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

If source and destination bus width differs pack/unpack MDMA
feature has to be activated for alignment.
This pack/unpack feature implies to have both source/destination address
and buffer length aligned on bus width.

Fixes: a4ffb13c ("dmaengine: Add STM32 MDMA driver")
Signed-off-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Since commit 3cab1e71 ("lib/vsprintf: refactor duplicate code
to special_hex_number()") %pad doesn't need 0x prefix so drop that.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Since commit 3cab1e71 ("lib/vsprintf: refactor duplicate code
to special_hex_number()") %pad doesn't need 0x prefix so drop that.
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

As discussed at ELCE 2017 there is little to anticipate from me in the
future with regard to the driver, and since I have many things to keep
an eye on, I would like to step down to simple designated reviewer.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.
Signed-off-by: NRomain Perier <romain.perier@collabora.com>
Acked-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Tested-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch adds the DMA controller driver for Spreadtrum SC9860 platform.
Signed-off-by: NBaolin Wang <baolin.wang@spreadtrum.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch adds the binding documentation for Spreadtrum SC9860 DMA
controller device.
Signed-off-by: NBaolin Wang <baolin.wang@spreadtrum.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

To avoid introduction of a new compatible for each small SoC/DMA controller
variation, move the definition of the channel count to the devicetree.

The number of vchans is no longer explicit, but limited by the highest
port/DMA request number. The result is a slight overallocation for SoCs
with a sparse port mapping.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

By default, we build Broadcom SBA RAID driver as loadable module for
iProc SOCs so that kernel image is little smaller and we load SBA RAID
driver only when required.
Signed-off-by: NAnup Patel <anup.patel@broadcom.com>
Reviewed-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

This patch makes the comment header of Broadcom SBA RAID driver
similar to the GPL comment header used across Broadcom driver
sources.
Signed-off-by: NAnup Patel <anup.patel@broadcom.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Each mailbox channel used by Broadcom SBA RAID driver is
a separate HW ring.

Currently, Broadcom SBA RAID driver creates one DMA channel
using one or more mailbox channels. When we are using more
than one mailbox channels for a DMA channel, the sba_request
are distributed evenly among multiple mailbox channels which
results in sba_request being completed out-of-order.

The above described out-of-order completion of sba_request
breaks the dma_async_is_complete() API because it assumes
DMA cookies are completed in orderly fashion.

To ensure correct behaviour of dma_async_is_complete() API,
this patch updates Broadcom SBA RAID driver to use only
single mailbox channel. If additional mailbox channels are
specified in DT then those will be ignored.
Signed-off-by: NAnup Patel <anup.patel@broadcom.com>
Reviewed-by: NRay Jui <ray.jui@broadcom.com>
Reviewed-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

As-per documentation in driver/dma/dmaengine.h, the
dma_cookie_complete() API should be called with lock
held.

This patch ensures that Broadcom SBA RAID driver calls
the dma_cookie_complete() API with reqs_lock held.
Signed-off-by: NAnup Patel <anup.patel@broadcom.com>
Reviewed-by: NRay Jui <ray.jui@broadcom.com>
Reviewed-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

If two concurrent threads call pl330_get_desc() when DMAC descriptor
pool is empty it is possible that allocation for one of threads will fail
with message:

kernel: dma-pl330 20078000.dma-controller: pl330_get_desc:2469 ALERT!

Here how that can happen. Thread A calls pl330_get_desc() to get
descriptor. If DMAC descriptor pool is empty pl330_get_desc() allocates
new descriptor on shared pool using add_desc() and then get newly
allocated descriptor using pluck_desc(). At the same time thread B calls
pluck_desc() and take newly allocated descriptor. In that case descriptor
allocation for thread A will fail.

Using on-stack pool for new descriptor allow avoid the issue described.
The patch modify pl330_get_desc() to use on-stack pool for allocation
new descriptors.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below.

        TCR       TCRB
[SOURCE] -> [DMAC] -> [SINK]

In the MEM_TO_DEV direction, what really matters is how much data has
been written to the device. If the DMA is interrupted between read and
write, then, the data doesn't end up in the destination, so shouldn't
be counted. TCRB is thus the register we should use in this cases.

In the DEV_TO_MEM direction, the situation is more complex. Both the
read and write side are important. What matters from a data consumer
point of view is how much data has been written to memory.
On the other hand, if the transfer is interrupted between read and
write, we'll end up losing data. It can also be important to report.

In the MEM_TO_MEM direction, what matters is of course how much data
has been written to memory from data consumer point of view.
Here, because read and write have independent data buffers, it will
take a while for TCR and TCRB to become equal. Thus we should check
TCRB in this case, too.

Thus, all cases we should check TCRB instead of TCR.

Without this patch, Sound Capture has noise after PluseAudio support
(= 07b7acb5 ("ASoC: rsnd: update pointer more accurate")), because
the recorder will use wrong residue counter which indicates transferred
from sound device, but in reality the data was not yet put to memory
and recorder will record it.
Signed-off-by: NHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
[Kuninori: added detail information in log]
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The A64 SoC has the same dma engine as the H3 (sun8i), with a
reduced amount of physical channels. To allow future reuse of the
compatible, leave the channel count etc. in the config data blank
and retrieve it from the devicetree.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The A64 is register compatible with the H3, but has a different number
of dma channels and request ports.

Attach additional properties to the node to allow future reuse of the
compatible for controllers with different number of channels/requests.

If dma-requests is not specified, the register layout defined maximum
of 32 is used.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Preparatory patch: If the same compatible is used for different SoCs which
have a common register layout, but different number of channels, the
channel count can no longer be stored in the config. Store it in the
device structure instead.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with
a width of 1, 2, 4 or 8 bytes.

The register value for the the width is log2-encoded, change the
conversion function to provide the correct value for width == 8.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The current code mixes three distinct operations when transforming
the slave config to register settings:

  1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0
  2. range checking
  3. conversion of raw to register values

As the range checks depend on the specific SoC, move these out of the
conversion to distinct operations.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

For the H3, the burst lengths field offsets in the channel configuration
register differs from earlier SoC generations.

Using the A31 register macros actually configured the H3 controller
do to bursts of length 1 always, which although working leads to higher
bus utilisation.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The H83T uses a compatible string different from the A23, but requires
the same clock autogating register setting.

The H3 also requires setting the clock autogating register, but has
the register at a different offset.

Add three suitable callbacks for the existing controller generations
and set it in the controller config structure.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Add runtime PM support to disable the clock when the h/w is not in use.
The existing clock_prepare_enable is removed from probe() as the clock
is no longer permanently enabled.
Signed-off-by: NEd Blake <ed.blake@sondrel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>