The OpenBlocks AX3-4 has a Seiko Instruments S-35390A as the RTC
controller. This patch enables this RTC device in the OpenBlocks
AX3-4 Device Tree.
[Thomas Petazzoni: updated with other OpenBlocks changes, rephrased
commit log.]
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The OpenBlocks AX3-4 board, based on the Armada XP SoC, has an I2C
bus. This patch enables this bus and sets the clock frequency of the
bus.
[Thomas Petazzoni: updated with other changes on OpenBlocks, rephrased
commit log.]
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Armada 370 and Armada XP have the same I2C controllers as previous
Marvell SoCs, so the existing mv64xxx-i2c driver works fine.
[Thomas Petazzoni: updated on top of other Armada 370/XP changes,
rephrased the commit log].
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEABECAAYFAlCmB6oACgkQ9lPLMJjT96elAwCfQyZY9HP0PW+0y2VRbKLYlrTW
vaQAoJMNKRaxjBwnF5As4I4/5g0rsE/H
=hRb7
-----END PGP SIGNATURE-----
Merge tag 'marvell-boards-net-for-3.8' of github.com:MISL-EBU-System-SW/mainline-public into test-the-merge
Marvell boards changes related to Ethernet, for 3.8
Conflicts:
arch/arm/boot/dts/armada-370-xp.dtsi
arch/arm/boot/dts/armada-xp-db.dts
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEABECAAYFAlCrmS8ACgkQ9lPLMJjT96cnsgCgsZ+TZb7UWOMlV4yLzdPS/CIf
qJEAniDrzpCgwrBhF2pJt3YpNz5ylaJK
=lCQA
-----END PGP SIGNATURE-----
Merge tag 'marvell-sata-3.8' of github.com:MISL-EBU-System-SW/mainline-public into test-the-merge
Marvell Armada 370/XP support for 3.8
The mvneta driver for the Marvell Armada 370/XP Ethernet devices has
gained proper clock framework integration, and the corresponding
Device Tree nodes now have a correct 'clocks' pointer.
The 'clock-frequency' properties in the various .dts files for Armada
370/XP boards have therefore become useless.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The mvneta driver now understands a standard 'clocks' clock pointer
property in the Device Tree nodes for the Ethernet devices, so we add
the right clock reference for the different Ethernet ports of the
Armada 370/XP SoCs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
mvneta_deinit() can be called from the ->probe() hook in the error
path, so it shouldn't be marked as __devexit. It fixes the following
section mismatch warning:
WARNING: vmlinux.o(.devinit.text+0x239c): Section mismatch in reference
from the function mvneta_probe() to the function .devexit.text:mvneta_deinit()
The function __devinit mvneta_probe() references
a function __devexit mvneta_deinit().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that the Armada 370/XP platform has gained proper integration with
the clock framework, we add clk support in the Marvell Armada 370/XP
Ethernet driver.
Since the existing Device Tree binding that exposes a
'clock-frequency' property has never been exposed in any stable kernel
release, we take the freedom of removing this property to replace it
with the standard 'clocks' clock pointer property.
The Device Tree binding documentation is updated accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by checkpatch, the multiline comments for net/ and
drivers/net/ have a slightly different format than the one used in the
rest of the kernel, so we adjust our multiline comments accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by checkpatch, the multiline comments for net/ and
drivers/net/ have a slightly different format than the one used in the
rest of the kernel, so we adjust our multiline comment accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As suggested by checkpatch, using <linux/delay.h> instead of
<asm/delay.h> is appropriate.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEABECAAYFAlCrmS8ACgkQ9lPLMJjT96cnsgCgsZ+TZb7UWOMlV4yLzdPS/CIf
qJEAniDrzpCgwrBhF2pJt3YpNz5ylaJK
=lCQA
-----END PGP SIGNATURE-----
Merge tag 'marvell-sata-3.8' of github.com:MISL-EBU-System-SW/mainline-public into test-the-merge
Marvell Armada 370/XP support for 3.8
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>
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>
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>
The ->probe() and ->remove() functions were missing the usual
__devinit and __devexit qualifiers.
Signed-off-by: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
