[PATCH] Device Tree binding for the 'mv_xor' XOR engine DMA driver

[Thomas Petazzoni]

Hello,

This patch set adds a Device Tree binding for the Marvell XOR engine
driver, which allows to support these XOR engines in the Armada 370
and Armada XP SoCs.

As one can immediatly see, this Device Tree binding patch set is not
as simple as most Device Tree bindings additions. This is due to the
fact that the mv_xor driver has a fairly odd organization. Instead of
registering a single platform_driver having platform_device structures
being instantiated together with platform_data structures describing
their specificities, this driver was organized around *two*
platform_driver:

 * One platform_driver named 'mv_xor_shared', for which one device was
   registered for each XOR engine (usually two in each Marvell SoC)

 * One platform_driver named 'mv_xor', for which one device was
   registered for each XOR channel (usually two per XOR engine). When
   those devices were registered, they contained a reference to the
   corresponding 'mv_xor_shared' device.

This unusual organization is:

 * useless, because the channels description can just as well be passed
   through platform_data of the 'mv_xor_shared' driver.

 * annoying, as it prevents the addition of a simple Device Tree
   binding for the driver.

Therefore, before adding the Device Tree binding, we cleanup and
reorganize the driver so that it registers a single platform_driver.

The patch set is organized as follows:

 * Patch 1 and 2 are basic cleanups, not really important.

 * Patch 3 to 8 are needed to remove the 'mv_xor'
   platform_driver. Instead of doing that as one big patch, we do it
   progressively, in small chunks, where each chunk builds and runs
   properly on the hardware.

   - Patch 3 moves the channel registration/cleanup logic into
     separate utility functions, so that they can be used for both the
     old-style probing (through the 'mv_xor' sub-driver) and the
     new-style probing (through platform_data passed to the main
     'mv_xor_shared' driver).

   - Patch 4 adds the possibility of registering channels through
     platform_data passed to the 'mv_xor_shared' main driver.

   - Patch 5 and Patch 6 respectively convert the XOR0 and XOR1 engine
     registrations to the new style probing.

   - Patch 7 removes some code that became useless in the process.

   - Patch 8 removes the sub-driver 'mv_xor'.

 * Patch 8 to 26 are further cleanups to the driver, mainly fixing the
   following problems:

   - All reference to the notion of 'shared' driver are removed.

   - The mv_xor driver registers one DMA engine and one DMA channel
     per XOR channel, because the different XOR channels in a given
     XOR engine have different capabilities. However, the mv_xor
     driver was internally keeping two structures having a 1:1
     mapping: mv_xor_device and mv_xor_chan, which was useless. We
     progressively convert the driver so that mv_xor_device represents
     one XOR engine, and mv_xor_chan represents one XOR channel.

   - Removing useless properties from the platform_data in order to
     simplify the Device Tree binding.

 * Patch 27 is a bug fix for the removal path, but it isn't very
   important as the driver cannot be compiled as a module.

 * Patch 28 adds the Device Tree binding itself and its documentation.

 * Patch 29 adds the Device Tree data to register the XOR engines on
   Armada 370/XP SoCs. Not Device Tree data is needed at the board
   level since those devices are purely internal to the SoC.

The resulting patch set is fully bisectable, and has been tested with
the built-in XOR engine self-test of the driver on both a Kirkwood
platform and a Armada XP platform.

The code is also available in the 'mvebu-xor' branch in the following
Git repository:

  git at github.com:MISL-EBU-System-SW/mainline-public.git

Note that PATCH 29 requires the clk patches from Grégory Clement for
the Armada 370/XP SoCs, which have already been Ack'ed, but not merged
yet.

Best regards,

Thomas