- 20 Nov, 2012 40 commits
-
-
Thomas Petazzoni authored
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Sebastian Hesselbarth authored
With DT support for Marvell XOR DMA engine, make use of it on Dove. Also remove the now redundant code in DT board init for xor engines. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Andrew Lunn authored
Use DT to describe the two XOR DMA engines on Kirkwood. Remove the C code initialization. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Andrew Lunn authored
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: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
The ->probe() and ->remove() functions were missing the usual __devinit and __devexit qualifiers. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: devicetree-discuss@lists.ozlabs.org
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
The backpointer from mv_xor_chan to mv_xor_device is now useless, get rid of it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
It was only used in places where we could get the 'struct device *' pointer through a different way. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
The to_mv_xor_device() macro is not being used by the driver, so we can get rid of it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
'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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
This member of the platform_data structure is no longer used, so get rid of it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
Now that xor0 and xor1 are registered in a single driver manner, the orion_xor_init_channels() function has become useless. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
Instead of registering one 'mv_xor_shared' device for the XOR engine, and then two 'mv_xor' devices for the XOR channels, pass the channels properties as platform_data for the main 'mv_xor_shared' device. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
Instead of registering one 'mv_xor_shared' device for the XOR engine, and then two 'mv_xor' devices for the XOR channels, pass the channels properties as platform_data for the main 'mv_xor_shared' device. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Thomas Petazzoni authored
The usage of dev_printk() is deprecated, and the dev_err(), dev_info() and dev_notice() functions should be used instead. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Andrew Lunn authored
With true DT clock providers available switch Kirkwood clock setup in DT- enabled boards. While AUXDATA can be removed completely from bus probing, some devices still don't know about DT. Therefore, some clkdev aliases are created until these devices also move to DT. Signed-off-by: Andrew Lunn <andrew@lunn.ch>
-
Sebastian Hesselbarth authored
With true DT clock providers available switch Dove clock setup in DT- enabled boards. While AUXDATA can be removed completely from bus probing, some devices still don't know about DT at all. Therefore, some clock aliases are created until the devices also move to DT. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Gregory CLEMENT authored
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Tested-by Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Gregory CLEMENT authored
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Gregory CLEMENT authored
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Sebastian Hesselbarth authored
This driver allows to provide DT clocks for clock gates found on Marvell Dove and Kirkwood SoCs. The clock gates are referenced by the phandle index of the corresponding bit in the clock gating control register to ease lookup in the datasheet. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Gregory CLEMENT authored
Add Armada 370/XP specific CPU clocks Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-