Even through the usage of devm_*() functions is generally recommended
over their classic variants, in the case of devm_request_irq()
combined with irq_of_parse_and_map(), it doesn't work nicely.

We have the following scenario:

 irq_of_parse_and_map(...)
 devm_request_irq(...)

For some reason, the driver initialization fails at a later
point. Since irq_of_parse_and_map() is no device-managed, we do a:

 irq_dispose_mapping(...)

Unfortunately, this doesn't work, because the free_irq() must be done
prior to calling irq_dispose_mapping(). But with the devm mechanism,
the automatic free_irq() would happen only after we get out of the
->probe() function.

So basically, we revert to using request_irq() with traditional error
handling, so that in case of error, free_irq() gets called before
irq_dispose_mapping().
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The XOR channels on Marvell SoCs have a Window Override Control
register that allow to do some fancy things with addresses. Those
features are not used by the driver, but some U-Boot versions anyway
modify those registers.

For some reason, the U-Boot on OpenBlocks AX3-4 was setting an invalid
value in those registers when the addition 2 GB DRAM chip was plugged
into the board, causing the XOR driver to fail in using the XOR
engines.

By setting those registers to 0 during the driver initialization, we
ensure that the registers are configured according with the driver
operation model.

Thanks to Lior Amsalem <alior@marvell.com> for his help in debugging
this problem.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The dmatest module for DMA engines calls

device_control(dtc->chan, DMA_TERMINATE_ALL, 0);

after completing the tests. The documentation in
include/linux/dmaengine.h suggests this function is optional and
dma_async_device_register() also does not BUG_ON() when not passed a
function. However, dmatest is not the only code in the kernel
unconditionally calling device_control. So add an implementation
indicating all operations are not implemented.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The ->probe() and ->remove() functions were missing the usual
__devinit and __devexit qualifiers.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

This patch finally adds a Device Tree binding to the mv_xor
driver. Thanks to the previous cleanup patches, the Device Tree
binding is relatively simply: one DT node per XOR engine, with
sub-nodes for each XOR channel of the XOR engine. The binding
obviously comes with the necessary documentation.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree-discuss@lists.ozlabs.org

Even though the driver cannot be unloaded at the moment, it is still
good to properly free the IRQ handlers in the channel removal function.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The pool_size is always PAGE_SIZE, and since it is a software
configuration paramter (and not a hardware description parameter), we
cannot make it part of the Device Tree binding, so we'd better remove
it from the platform_data as well.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

There is no need for the platform_data to give this ID, it is simply
the channel number, so we can compute it inside the driver when
registering the channels.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The backpointer from mv_xor_chan to mv_xor_device is now useless, get
rid of it.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Now that mv_xor_device is no longer used to designate the per-channel
DMA devices, use it know to designate the XOR engine themselves
(currently composed of two XOR channels).

So, now we have the nice organization where:

 - mv_xor_device represents each XOR engine in the system
 - mv_xor_chan   represents each XOR channel of a given XOR engine
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Even though the DMA engine infrastructure has support for multiple
channels per device, the mv_xor driver registers one DMA engine device
for each channel, because the mv_xor channels inside the same XOR
engine have different capabilities, and the DMA engine infrastructure
only allows to express capabilities at the DMA engine device level.

The mv_xor driver has therefore been registering one DMA engine device
and one DMA engine channel for each XOR channel since its introduction
in the kernel. However, it kept two separate internal structures,
mv_xor_device and mv_xor_channel, which didn't make a lot of sense
since there was a 1:1 mapping between those structures.

This patch gets rid of this duplication, and merges everything into
the mv_xor_chan structure.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

In preparation for the removal of the mv_xor_device structure, we
directly pass mv_xor_chan pointers to the self-test functions included
in the driver. These functions were anyway selecting the first (and
only channel) available in each DMA device, so the behaviour is
unchanged.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The mv_xor_device structure embeds a 'struct dma_device', which is
named 'common', a not very meaningful name. Rename it to 'dmadev',
which will help avoid confusions later as we merge the mv_xor_device
and mv_xor_chan structures together.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The mv_xor_chan structure embeds a 'struct dma_chan', which is named
'common', a not very meaningful name. Rename it to 'dmachan', which
will help avoid confusions later as we merge the mv_xor_device and
mv_xor_chan structures together.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

It was only used in places where we could get the 'struct device *'
pointer through a different way.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

In many place, we need to get the 'struct device *' pointer from a
'struct mv_chan *', so we add a helper that makes this a bit
easier. It will also help reducing the change noise in further
patches.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

In mv_xor_memcpy_self_test() and mv_xor_xor_self_test(), all DMA
functions are called by passing dma_chan->device->dev as the 'device
*', except the calls to dma_sync_single_for_cpu() which uselessly goes
through mv_chan->device->pdev->dev.

Simplify this by using dma_chan->device->dev direclty in
dma_sync_single_for_cpu() calls.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The to_mv_xor_device() macro is not being used by the driver, so we
can get rid of it.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The 'shared' word no longer makes sense in a number of places as we
renamed the 'mv_xor_shared' driver to 'mv_xor'.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Since we got rid of the per-XOR channel 'mv_xor' driver, now the
per-XOR engine driver that used to be called 'mv_xor_shared' can
simply be named 'mv_xor'.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

'struct mv_xor_shared_platform_data' used to be the platform_data
structure for the 'mv_xor_shared', but this driver is going to be
renamed simply 'mv_xor', so also rename its platform_data structure
accordingly.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

mv_xor_platform_data used to be the platform_data structure associated
to the 'mv_xor' driver. This driver no longer exists, and this data
structure really contains the properties of each XOR channel part of a
given XOR engine. Therefore 'struct mv_xor_channel_data' is a more
appropriate name.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Now that XOR channels are directly registered by the main
'mv_xor_shared' device ->probe() function and all users of the
'mv_xor' device have been removed, we can get rid of the latter.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Extend the XOR engine driver (currently called "mv_xor_shared") so
that XOR channels can be passed in the platform_data structure, and be
registered from there.

This will allow the users of the driver to be converted to the single
platform_driver variant of the mv_xor driver.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Instead of doing the initialization/cleanup of the XOR channels
directly in the ->probe() and ->remove() hooks, we create separate
utility functions mv_xor_channel_add() and mv_xor_channel_remove().

This will allow to easily introduce in a future patch a different way
of registering XOR channels: instead of having one platform_device per
channel, we'll trigger the registration of all XOR channels of a given
XOR engine directly from the XOR engine ->probe() function.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The driver currently pokes into the platform_data structure during its
normal operation to get the pool_size value. Poking into the
platform_data structure is not nice when moving to the Device Tree, so
this commit adds a new pool_size field in the mv_xor_device structure,
which gets initialized at ->probe() time. The driver then uses this
field instead of the platform_data.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The usage of dev_printk() is deprecated, and the dev_err(), dev_info()
and dev_notice() functions should be used instead.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Platform data for device drivers should be defined in
include/linux/platform_data/*.h, not in the architecture
and platform specific directories.

This moves such data out of the orion include directories
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <djbw@fb.com>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Ball <cjb@laptop.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Liam Girdwood <lrg@ti.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>

Some orion platforms can gate the XOR driver clock. If the clock
exisits, unable/disable it as appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NJamie Lentin <jm@lentin.co.uk>
Signed-off-by: NMike Turquette <mturquette@linaro.org>

Ensure all DMA engine drivers initialize their cookies in the same way,
so that they all behave in a similar fashion.  This means their first
issued cookie will be 2 rather than 1, and will increment to INT_MAX
before returning 1 and starting over.

In connection with this, Dan Williams said:
> Russell King wrote:
> > Secondly, some DMA engine drivers initialize the dma_chan cookie to 0,
> > others to 1.  Is there a reason for this, or are these all buggy?
>
> I know that ioat and iop-adma expect 0 to mean "I have cleaned up this
> descriptor and it is idle", and would break if zero was an in-flight
> cookie value.  The reserved usage of zero is an driver internal
> concern, but I have no problem formalizing it as a reserved value.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Now that we have the completed cookie in the dma_chan structure, we
can consolidate the tx_status functions by providing a function to set
the txstate structure and returning the DMA status.  We also provide
a separate helper to set the residue for cookies which are still in
progress.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Everyone deals with assigning DMA cookies in the same way (it's part of
the API so they should be), so lets consolidate the common code into a
helper function to avoid this duplication.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Add a local private header file to contain definitions and declarations
which should only be used by DMA engine drivers.

We also fix linux/dmaengine.h to use LINUX_DMAENGINE_H to guard against
multiple inclusion.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Every DMA engine implementation declares a last completed dma cookie
in their private dma channel structures.  This is pointless, and
forces driver specific code.  Move this out into the common dma_chan
structure.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

mv_xor's is_complete_cookie is only ever written to, but never read.
This is silly, remove the write-only structure member.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJassi Brar <jassisinghbrar@gmail.com>
[imx-sdma.c & mxs-dma.c]
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Use an getter function in plat-orion/addr-map.c to get the address map
structure, rather than pass it to drivers in the platform_data
structures. When the drivers are built for none orion platforms, a
dummy function is provided instead which returns NULL.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NMichael Walle <michael@walle.cc>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>

Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Dan Williams <dan.j.williams@intel.com> (supporter:ASYNCHRONOUS TRAN...)
Cc: Vinod Koul <vinod.koul@intel.com> (supporter:DMA GENERIC OFFLO...)
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

Several fixes as well where the +1 was missing.

Done via coccinelle scripts like:

@@
struct resource *ptr;
@@

- ptr->end - ptr->start + 1
+ resource_size(ptr)

and some grep and typing.

Mostly uncompiled, no cross-compilers.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch makes BUG_ON() usage correct in drivers/dma/mv_xor.c

Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NColy Li <bosong.ly@taobao.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>