Update MAINTAINERS for SiFive PDMA driver.
Signed-off-by: NGreen Wan <green.wan@sifive.com>
Link: https://lore.kernel.org/r/20191107084955.7580-5-green.wan@sifive.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add PDMA driver, sf-pdma, to enable DMA engine on HiFive Unleashed
Rev A00 board.

 - Implement dmaengine APIs, support MEM_TO_MEM async copy.
 - Tested by DMA Test client
 - Supports 4 channels DMA, each channel has 1 done and 1 err
   interrupt connected to platform-level interrupt controller (PLIC).
 - Depends on DMA_ENGINE and DMA_VIRTUAL_CHANNELS

The datasheet is here:

  https://static.dev.sifive.com/FU540-C000-v1.0.pdf

Follow the DMAengine controller doc,
"./Documentation/driver-api/dmaengine/provider.rst" to implement DMA
engine. And use the dma test client in doc,
"./Documentation/driver-api/dmaengine/dmatest.rst", to test.

Each DMA channel has separate HW regs and support done and error ISRs.
4 channels share 1 done and 1 err ISRs. There's no expander/arbitrator
in DMA HW.

   ------               ------
   |    |--< done 23 >--|ch 0|
   |    |--< err  24 >--|    |     (dma0chan0)
   |    |               ------
   |    |               ------
   |    |--< done 25 >--|ch 1|
   |    |--< err  26 >--|    |     (dma0chan1)
   |PLIC|               ------
   |    |               ------
   |    |--< done 27 >--|ch 2|
   |    |--< err  28 >--|    |     (dma0chan2)
   |    |               ------
   |    |               ------
   |    |--< done 29 >--|ch 3|
   |    |--< err  30 >--|    |     (dma0chan3)
   ------               ------
Signed-off-by: NGreen Wan <green.wan@sifive.com>
Link: https://lore.kernel.org/r/20191107084955.7580-4-green.wan@sifive.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add DT bindings document for Platform DMA(PDMA) driver of board,
HiFive Unleashed Rev A00.
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NPragnesh Patel <pragnesh.patel@sifive.com>
Signed-off-by: NGreen Wan <green.wan@sifive.com>
Link: https://lore.kernel.org/r/20191107084955.7580-2-green.wan@sifive.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

In the probe method dmam_pool_create is used. Therefore, there is no
need to explicitly call dmam_pool_destroy in remove method as this
will be automatically taken care by devres
Signed-off-by: NSatendra Singh Thakur <sst2005@gmail.com>
Link: https://lore.kernel.org/r/20191109113609.6159-1-sst2005@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

When devm_request_irq fails, currently, the function
dma_async_device_unregister gets called. This doesn't free
the resources allocated by of_dma_controller_register.
Therefore, we have called of_dma_controller_free for this purpose.
Signed-off-by: NSatendra Singh Thakur <sst2005@gmail.com>
Link: https://lore.kernel.org/r/20191109113523.6067-1-sst2005@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

There is a statement that is indented too deeply, remove
the extraneous indentation.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20191112191143.282814-1-colin.king@canonical.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

platform_get_irq() prints the error message, so caller need not do so,
remove the error line in this driver for platform_get_irq()
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20191106163128.1980714-2-vkoul@kernel.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

platform_get_irq() prints the error message, so caller need not do so,
remove the error line in this driver for platform_get_irq()
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20191106163128.1980714-1-vkoul@kernel.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

The remove misses to disable and unprepare jzdma->clk.
Add a call to clk_disable_unprepare to fix it.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Acked-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20191104161622.11758-1-hslester96@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add support for probing the dma-jz4780 driver on the X1000 Soc.
Signed-off-by: NZhou Yanjie <zhouyanjie@zoho.com>
Reviewed-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/1571937670-30828-3-git-send-email-zhouyanjie@zoho.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add the dmaengine bindings for the X1000 Soc from Ingenic.
Signed-off-by: NZhou Yanjie <zhouyanjie@zoho.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1571937670-30828-2-git-send-email-zhouyanjie@zoho.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add support for AXI Multichannel Direct Memory Access (AXI MCDMA)
core, which is a soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream target peripherals.
The AXI MCDMA core provides scatter-gather interface with multiple
independent transmit and receive channels. The driver supports
device_prep_slave_sg slave transfer mode.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571763622-29281-7-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Extend dma_config structure to store irq routine handle. It enables runtime
handler selection based on xdma_ip_type and serves as preparatory patch for
adding MCDMA IP support.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Suggested-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/1571763622-29281-6-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

The AXI DMA multichannel support is deprecated in the IP and it is no
longer actively supported. For multichannel support, refer to the AXI
multichannel direct memory access IP product guide(PG228) and MCDMA
driver. So inline with it remove axidma multichannel support from
from the driver.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571763622-29281-5-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Add devicetree binding for Xilinx AXI Multichannel Direct Memory Access
(AXI MCDMA) IP. The AXI MCDMA provides high-bandwidth direct memory
access between memory and AXI4-Stream target peripherals. The AXI MCDMA
core provides a scatter-gather interface with multiple channel support
with independent configuration.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1571763622-29281-4-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Trivial formatting(keep compatible string one per line, caps change etc).
It doesn't modify the content of the binding.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1571763622-29281-3-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

The AXI DMA multichannel support is deprecated in the IP and it is no
longer actively supported. For multichannel support, refer to the AXI
multichannel direct memory access IP product guide(PG228) and MCDMA
driver(added in the subsequent commits). Inline with it remove axidma
multichannel optional properties i.e xlnx,mcdma and dma-channels from
the binding description.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1571763622-29281-2-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Like paRAM slots, channels could be used by other cores and in this case
we need to make sure that the driver do not alter these channels.

Handle the generic dma-channel-mask property to mark channels in a bitmap
which can not be used by Linux and convert the legacy rsv_chans if it is
provided by platform_data.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20191025073056.25450-4-peter.ujfalusi@ti.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Similarly to paRAM slots, channels can be used by other cores.

The common dma-channel-mask property can be used for specifying the
available channels.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191025073056.25450-3-peter.ujfalusi@ti.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Make the dma-channel-mask to be usable for controllers with more than 32
channels.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191025073056.25450-2-peter.ujfalusi@ti.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Clang warns:

drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:25: warning: variable 'cfg' is
uninitialized when used within its own initialization [-Wuninitialized]
        DPDMAI_CMD_CREATE(cmd, cfg);
        ~~~~~~~~~~~~~~~~~~~~~~~^~~~
drivers/dma/fsl-dpaa2-qdma/dpdmai.c:42:24: note: expanded from macro
'DPDMAI_CMD_CREATE'
        typeof(_cfg) (cfg) = (_cfg); \
                      ~~~     ^~~~
1 warning generated.

Looking at the preprocessed source, we can see that this is true.

int dpdmai_create(struct fsl_mc_io *mc_io, u32 cmd_flags,
                  const struct dpdmai_cfg *cfg, u16 *token)
{
        struct fsl_mc_command cmd = { 0 };
        int err;

        cmd.header = mc_encode_cmd_header((((0x90E) << 4) | 0), cmd_flags, 0);
        do {
                typeof(cmd)(cmd) = (cmd);
                typeof(cfg)(cfg) = (cfg);
                ((cmd).params[0] |= mc_enc((8), (8), (cfg)->priorities[0]));
                ((cmd).params[0] |= mc_enc((16), (8), (cfg)->priorities[1]));
        } while (0);

I cannot see a good reason to create another version of cfg when the
parameter one will work perfectly fine and cmd can just be used as is.
Remove them to fix this warning.

Fixes: f2835adf ("dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support")
Link: https://github.com/ClangBuiltLinux/linux/issues/746Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Link: https://lore.kernel.org/r/20191022171648.37732-1-natechancellor@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

platform_get_irq_byname() might return -errno which later would be cast
to an unsigned int and used in IRQ handling code leading to usage of
wrong ID and errors about wrong irq_base.
Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NPeng Ma <peng.ma@nxp.com>
Tested-by: NPeng Ma <peng.ma@nxp.com>
Link: https://lore.kernel.org/r/20191004150826.6656-1-krzk@kernel.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

The symbols were not exported leading to error:

WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-dpaa2-qdma/dpdmai.o
see include/linux/module.h for more information
GZIP    arch/arm64/boot/Image.gz
ERROR: "dpdmai_enable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_set_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_tx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_rx_queue" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_get_attributes" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_open" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_close" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_disable" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
ERROR: "dpdmai_reset" [drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.ko] undefined!
WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [sub-make] Error 2

So export it.
Signed-off-by: NPeng Ma <peng.ma@nxp.com>
Reported-by: NAnders Roxell <anders.roxell@linaro.org>
Link: https://lore.kernel.org/r/20191023045617.22764-1-peng.ma@nxp.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Whenever we reset the channel, we need to clear desc_pendingcount
along with desc_submitcount. Otherwise when a new transaction is
submitted, the irq coalesce level could be programmed to an incorrect
value in the axidma case.

This behavior can be observed when terminating pending transactions
with xilinx_dma_terminate_all() and then submitting new transactions
without releasing and requesting the channel.
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-8-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

The driver should not run out of tx segments in normal operation. But,
if the user attempts to prepare a transaction with a large sg list,
the driver may not have enough free segments to accommodate the request.

Log a message at the debug level to inform the user in case they are
experiencing issues.
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-7-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Take advantage of dmaengine_desc_get_callback_invoke which allows either
a callback or callback_result to be specified. This can be useful when
using the AXI DMA transfer unknown quantities of data where the residue
contained in the result can be used to calculate the number of bytes
transferred.
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-6-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Introduce a function that can calculate residues for IPs that support it:
AXI DMA and CDMA.
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-5-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

There is no use of storing channel data residue field. So clean it up.
In tx_status simply pass calculated residue to dma_set_residue.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-4-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

The dma api provides a single interface to get the appropriate callback
and invoke it directly. Prefer using it.
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-3-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

In descriptor cleanup the call to desc_callback_valid can be safely
removed as both callback pointers i.e callback_result and callback
are anyway checked in invoke(). There is no much benefit in having
redundant checks.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: NNicholas Graumann <nick.graumann@gmail.com>
Reviewed-by: NAppana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
Link: https://lore.kernel.org/r/1571150904-3988-2-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Driver for Socionext Milbeaut XDMAC controller. The controller only
supports Mem-To-Mem transfers over upto 8 configurable channels.
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Link: https://lore.kernel.org/r/20191015033219.14713-1-jassisinghbrar@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Document the devicetree bindings for Socionext Milbeaut XDMAC
controller. Controller only supports Mem->Mem transfers. Number
of physical channels are determined by the number of irqs registered.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Link: https://lore.kernel.org/r/20191015033157.14656-1-jassisinghbrar@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Driver for Socionext Milbeaut HDMAC controller. The controller has
upto 8 floating channels, that need a predefined slave-id to work
from a set of slaves.
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Link: https://lore.kernel.org/r/20191015033359.14925-1-jassisinghbrar@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Document the devicetree bindings for Socionext Milbeaut HDMAC
controller. Controller has upto 8 floating channels, that need
a predefined slave-id to work from a set of slaves.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJassi Brar <jaswinder.singh@linaro.org>
Link: https://lore.kernel.org/r/20191015033350.14866-1-jassisinghbrar@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

DPPA2(Data Path Acceleration Architecture 2) qDMA supports
virtualized channel by allowing DMA jobs to be enqueued into
different work queues. Core can initiate a DMA transaction by
preparing a frame descriptor(FD) for each DMA job and enqueuing
this job through a hardware portal. DPAA2 components can also
prepare a FD and enqueue a DMA job through a hardware portal.
The qDMA prefetches DMA jobs through DPAA2 hardware portal. It
then schedules and dispatches to internal DMA hardware engines,
which generate read and write requests. Both qDMA source data and
destination data can be either contiguous or non-contiguous using
one or more scatter/gather tables.
The qDMA supports global bandwidth flow control where all DMA
transactions are stalled if the bandwidth threshold has been reached.
Also supported are transaction based read throttling.

Add NXP dppa2 qDMA to support some of Layerscape SoCs.
such as: LS1088A, LS208xA, LX2, etc.
Signed-off-by: NPeng Ma <peng.ma@nxp.com>
Link: https://lore.kernel.org/r/20190930020440.7754-2-peng.ma@nxp.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

The MC(Management Complex) exports the DPDMAI(Data Path DMA Interface)
object as an interface to operate the DPAA2(Data Path Acceleration
Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based
requests to qDMA and receiving back confirmation response on transaction
completion, utilizing the DPAA2 QBMan(Queue Manager and Buffer Manager
hardware) infrastructure. DPDMAI object provides up to two priorities for
processing qDMA requests.
The following list summarizes the DPDMAI main features and capabilities:
	1. Supports up to two scheduling priorities for processing
	service requests.
	- Each DPDMAI transmit queue is mapped to one of two service
	priorities, allowing further prioritization in hardware between
	requests from different DPDMAI objects.
	2. Supports up to two receive queues for incoming transaction
	completion confirmations.
	- Each DPDMAI receive queue is mapped to one of two receive
	priorities, allowing further prioritization between other
	interfaces when associating the DPDMAI receive queues to DPIO
	or DPCON(Data Path Concentrator) objects.
	3. Supports different scheduling options for processing received
	packets:
	- Queues can be configured either in 'parked' mode (default),
	or attached to a DPIO object, or attached to DPCON object.
	4. Allows interaction with one or more DPIO objects for
	dequeueing/enqueueing frame descriptors(FD) and for
	acquiring/releasing buffers.
	5. Supports enable, disable, and reset operations.

Add dpdmai to support some platforms with dpaa2 qdma engine.
Signed-off-by: NPeng Ma <peng.ma@nxp.com>
Link: https://lore.kernel.org/r/20190930020440.7754-1-peng.ma@nxp.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Renesas RZ/G2N (R8A774B1) SoC also has the R-Car gen2/3 compatible
DMA controllers, therefore document RZ/G2N specific bindings.
Signed-off-by: NBiju Das <biju.das@bp.renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1569580629-55677-1-git-send-email-biju.das@bp.renesas.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Use the new helper that wraps the calls to platform_get_resource()
and devm_ioremap_resource() together, which can simpify the code.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Link: https://lore.kernel.org/r/1af3efdac3b217203cace090c8947386854c0144.1569554639.git.baolin.wang@linaro.orgSigned-off-by: NVinod Koul <vkoul@kernel.org>

In dma probe, the driver checks for devm_clk_get return and print error
message in the failing case. However for -EPROBE_DEFER this message is
confusing so avoid it.
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/1569495060-18117-5-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>

Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource(). It simplifies the flow and there
is no functional change.

Fixes below cocinelle warning-
WARNING: Use devm_platform_ioremap_resource for xdev -> regs
Signed-off-by: NRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Link: https://lore.kernel.org/r/1569495060-18117-4-git-send-email-radhey.shyam.pandey@xilinx.comSigned-off-by: NVinod Koul <vkoul@kernel.org>