From: Thomas Petazzoni <hidden> Date: 2012-08-06 09:42:16
Andrew, Jason, Gr?gory,
Here is a small patch set that introduces basic support for address
decoding on Armada 370 and Armada XP. The aim of this basic support is
essentially to be able to configure a window to remap the BootROM,
which is needed to startup the secondary CPUs for the SMP support.
As we had discussed already, the address decoding configuration is not
described in the Device Tree, it is for now hardcoded on a per-SoC
basis. We might later discuss how to extend this to the Device Tree.
This patch set has five patches:
(*) First patch reworks the addr-map code to use void __iomem * where
appropriate instead of u32, as per the suggestion of Arnd
Bergmann.
(*) Second patch introducing PLAT_ORION_LEGACY, which allows the
Marvell 370/XP platforms to be part of PLAT_ORION, and therefore
re-use the existing address decoding code.
(*) Third patch making a small change to an address decoding
structure so that we can define at runtime the virtual address of
the configuration registers. This is needed as on Armada 370/XP
the address decoding "controller" is declared in the Device Tree.
(*) Fourth patch adding the 370/XP address decoding code itself. For
now, it only maps the BootROM on Armada XP.
(*) Fifth path adding the necessary DT code to instantiate the
address decoding "controller".
Changes since v2:
* Remove one more useless (void __iomem *) cast in the Armada 370/XP
addr-map.c file, as noticed by Arnd Bergmann.
Changes since v1:
* Use void __iomem * in addr-map code. Suggested by Arnd Bergmann.
* Add Acked-by on patches 2->5 from Gr?gory Cl?ment
Thanks,
Thomas Petazzoni
From: Thomas Petazzoni <hidden> Date: 2012-08-06 09:42:17
Use 'void __iomem *' instead of u32 where appropriate in the addr-map
code. It requires adding a few casts in SoC-specific addr-map.c files,
but those casts will disappear once those SoC are migrated to the
device tree, in which case the address will come from the DT instead
of from #define values.
Signed-off-by: Thomas Petazzoni <redacted>
---
arch/arm/mach-dove/addr-map.c | 2 +-
arch/arm/mach-kirkwood/addr-map.c | 5 +++--
arch/arm/mach-mv78xx0/addr-map.c | 4 ++--
arch/arm/mach-orion5x/addr-map.c | 5 +++--
arch/arm/plat-orion/addr-map.c | 11 ++++-------
arch/arm/plat-orion/include/plat/addr-map.h | 4 ++--
6 files changed, 15 insertions(+), 16 deletions(-)
@@ -16,7 +16,7 @@ extern struct mbus_dram_target_info orion_mbus_dram_info;structorion_addr_map_cfg{constintnum_wins;/* Total number of windows */constintremappable_wins;-constu32bridge_virt_base;+void__iomem*constbridge_virt_base;/* If NULL, the default cpu_win_can_remap will be used, usingthevalueinremappable_wins*/
From: Thomas Petazzoni <hidden> Date: 2012-08-06 09:42:18
Until now, the PLAT_ORION configuration option was common to all the
Marvell EBU SoCs, and selecting this option had the effect of enabling
the MPP code, GPIO code, address decoding and PCIe code from
plat-orion, as well as providing access to driver-specific header
files from plat-orion/include.
However, the Armada 370 and XP SoCs will not use the MPP and GPIO code
(instead some proper pinctrl and gpio drivers are in preparation), and
generally, we want to move away from plat-orion and instead have
everything in mach-mvebu.
That said, in the mean time, we want to leverage the driver-specific
headers as well as the address decoding code, so we introduce
PLAT_ORION_LEGACY. The older Marvell SoCs need to select
PLAT_ORION_LEGACY, while the newer Marvell SoCs need to select
PLAT_ORION. Of course, when PLAT_ORION_LEGACY is selected, it
automatically selects PLAT_ORION.
Then, with just PLAT_ORION, you have the address decoding code plus
the driver-specific headers. If you add PLAT_ORION_LEGACY to this, you
gain the old MPP, GPIO and PCIe code.
Again, this is only a temporary solution until we make all Marvell EBU
platforms converge into the mach-mvebu directory. This solution avoids
duplicating the existing address decoding code into mach-mvebu.
Signed-off-by: Thomas Petazzoni <redacted>
Acked-by: Gregory CLEMENT <redacted>
---
arch/arm/Kconfig | 13 +++++++++----
arch/arm/plat-orion/Makefile | 9 ++++-----
2 files changed, 13 insertions(+), 9 deletions(-)
@@ -2,9 +2,8 @@# Makefile for the linux kernel.#-obj-y:=irq.opcie.otime.ocommon.ompp.oaddr-map.o-obj-m:=-obj-n:=-obj-:=+obj-y+=addr-map.o-obj-$(CONFIG_GENERIC_GPIO)+=gpio.o+orion-gpio-$(CONFIG_GENERIC_GPIO)+=gpio.o+obj-$(CONFIG_PLAT_ORION_LEGACY)+=irq.opcie.otime.ocommon.ompp.o+obj-$(CONFIG_PLAT_ORION_LEGACY)+=$(orion-gpio-y)
From: Thomas Petazzoni <hidden> Date: 2012-08-06 09:42:19
For the Armada 370 and XP SoCs where the DT is used, we need to fill
at runtime the bridge_virt_base field on the
orion_addr_map_cfg. Therefore, remove the 'const' qualifier on this
field.
Signed-off-by: Thomas Petazzoni <redacted>
Acked-by: Gregory CLEMENT <redacted>
---
arch/arm/plat-orion/include/plat/addr-map.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -16,7 +16,7 @@ extern struct mbus_dram_target_info orion_mbus_dram_info;structorion_addr_map_cfg{constintnum_wins;/* Total number of windows */constintremappable_wins;-void__iomem*constbridge_virt_base;+void__iomem*bridge_virt_base;/* If NULL, the default cpu_win_can_remap will be used, usingthevalueinremappable_wins*/
From: Thomas Petazzoni <hidden> Date: 2012-08-06 09:42:20
This commit adds basic support for address decoding configuration for
the Armada 370 and Armada XP SoCs, re-using the infrastructure
provided in plat-orion.
For now, only a BootROM window is configured on Armada XP, which is
needed to get the non-boot CPUs started and is therefore a requirement
for SMP support.
Signed-off-by: Thomas Petazzoni <redacted>
Acked-by: Gregory CLEMENT <redacted>
---
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/addr-map.c | 134 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-mvebu/addr-map.c
@@ -0,0 +1,134 @@+/*+*AddressmapfunctionsforMarvell370/XPSoCs+*+*Copyright(C)2012Marvell+*+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*/++#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/mbus.h>+#include<linux/io.h>+#include<linux/of.h>+#include<linux/of_address.h>+#include<plat/addr-map.h>++/*+*GenericAddressDecodeWindowsbitsettings+*/+#define ARMADA_XP_TARGET_DEV_BUS 1+#define ARMADA_XP_ATTR_DEV_BOOTROM 0x1D+#define ARMADA_XP_TARGET_ETH1 3+#define ARMADA_XP_TARGET_PCIE_0_2 4+#define ARMADA_XP_TARGET_ETH0 7+#define ARMADA_XP_TARGET_PCIE_1_3 8++#define ARMADA_370_TARGET_DEV_BUS 1+#define ARMADA_370_ATTR_DEV_BOOTROM 0x1D+#define ARMADA_370_TARGET_PCIE_0 4+#define ARMADA_370_TARGET_PCIE_1 8++#define ARMADA_WINDOW_8_PLUS_OFFSET 0x90+#define ARMADA_SDRAM_ADDR_DECODING_OFFSET 0x180++staticconststruct__initdataorion_addr_map_info+armada_xp_addr_map_info[]={+/*+*WindowfortheBootROM,neededforSMPonArmadaXP+*/+{0,0xfff00000,SZ_1M,ARMADA_XP_TARGET_DEV_BUS,+ARMADA_XP_ATTR_DEV_BOOTROM,-1},+/* End marker */+{-1,0,0,0,0,0},+};++staticconststruct__initdataorion_addr_map_info+armada_370_addr_map_info[]={+/* End marker */+{-1,0,0,0,0,0},+};++staticstructof_device_idof_addr_decoding_controller_table[]={+{.compatible="marvell,armada-addr-decoding-controller"},+{/* end of list */},+};++staticvoid__iomem*+armada_cfg_base(conststructorion_addr_map_cfg*cfg,intwin)+{+unsignedintoffset;++/* The register layout is a bit annoying and the below code+*triestocopewithit.+*-Atoffset0x0,therearetheregistersforthefirst8+*windows,with4registersof32bitsperwindow(ctrl,+*base,remaplow,remaphigh)+*-Thenatoffset0x80,thereisaholeof0x10bytesfor+*theinternalregistersbaseaddressandinternalunits+*syncbarrierregister.+*-Thenatoffset0x90,theretheregistersfor12+*windows,withonly2registersof32bitsperwindow+*(ctrl,base).+*/+if(win<8)+offset=(win<<4);+else+offset=ARMADA_WINDOW_8_PLUS_OFFSET+(win<<3);++returncfg->bridge_virt_base+offset;+}++staticstruct__initdataorion_addr_map_cfgaddr_map_cfg={+.num_wins=20,+.remappable_wins=8,+.win_cfg_base=armada_cfg_base,+};++staticint__initarmada_setup_cpu_mbus(void)+{+structdevice_node*np;+void__iomem*mbus_unit_addr_decoding_base;+void__iomem*sdram_addr_decoding_base;++np=of_find_matching_node(NULL,of_addr_decoding_controller_table);+if(!np)+return-ENODEV;++mbus_unit_addr_decoding_base=of_iomap(np,0);+BUG_ON(!mbus_unit_addr_decoding_base);++sdram_addr_decoding_base=+mbus_unit_addr_decoding_base++ARMADA_SDRAM_ADDR_DECODING_OFFSET;++addr_map_cfg.bridge_virt_base=mbus_unit_addr_decoding_base;++/*+*Disable,clearandconfigurewindows.+*/+if(of_machine_is_compatible("marvell,armadaxp"))+orion_config_wins(&addr_map_cfg,armada_xp_addr_map_info);+elseif(of_machine_is_compatible("marvell,armada370"))+orion_config_wins(&addr_map_cfg,armada_370_addr_map_info);+else{+pr_err("Unsupported SoC\n");+return-EINVAL;+}++/*+*SetupMBUSdramtargetinfo.+*/+orion_setup_cpu_mbus_target(&addr_map_cfg,+sdram_addr_decoding_base);+return0;+}++/* Using a early_initcall is needed so that this initialization gets+*donebeforetheSMPinitialization,whichrequirestheBootROMto+*beremapped.*/+early_initcall(armada_setup_cpu_mbus);
From: Jason Cooper <hidden> Date: 2012-08-16 13:28:39
On Mon, Aug 06, 2012 at 11:42:16AM +0200, Thomas Petazzoni wrote:
Andrew, Jason, Gr?gory,
Here is a small patch set that introduces basic support for address
decoding on Armada 370 and Armada XP. The aim of this basic support is
essentially to be able to configure a window to remap the BootROM,
which is needed to startup the secondary CPUs for the SMP support.
As we had discussed already, the address decoding configuration is not
described in the Device Tree, it is for now hardcoded on a per-SoC
basis. We might later discuss how to extend this to the Device Tree.
This patch set has five patches:
(*) First patch reworks the addr-map code to use void __iomem * where
appropriate instead of u32, as per the suggestion of Arnd
Bergmann.
(*) Second patch introducing PLAT_ORION_LEGACY, which allows the
Marvell 370/XP platforms to be part of PLAT_ORION, and therefore
re-use the existing address decoding code.
(*) Third patch making a small change to an address decoding
structure so that we can define at runtime the virtual address of
the configuration registers. This is needed as on Armada 370/XP
the address decoding "controller" is declared in the Device Tree.
(*) Fourth patch adding the 370/XP address decoding code itself. For
now, it only maps the BootROM on Armada XP.
(*) Fifth path adding the necessary DT code to instantiate the
address decoding "controller".
Changes since v2:
* Remove one more useless (void __iomem *) cast in the Armada 370/XP
addr-map.c file, as noticed by Arnd Bergmann.
Changes since v1:
* Use void __iomem * in addr-map code. Suggested by Arnd Bergmann.
* Add Acked-by on patches 2->5 from Gr?gory Cl?ment
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
thx,
Jason.
From: Jason Cooper <hidden> Date: 2012-08-16 18:37:08
On Thu, Aug 16, 2012 at 09:28:39AM -0400, Jason Cooper wrote:
On Mon, Aug 06, 2012 at 11:42:16AM +0200, Thomas Petazzoni wrote:
quoted
Andrew, Jason, Gr?gory,
Here is a small patch set that introduces basic support for address
decoding on Armada 370 and Armada XP. The aim of this basic support is
essentially to be able to configure a window to remap the BootROM,
which is needed to startup the secondary CPUs for the SMP support.
As we had discussed already, the address decoding configuration is not
described in the Device Tree, it is for now hardcoded on a per-SoC
basis. We might later discuss how to extend this to the Device Tree.
This patch set has five patches:
(*) First patch reworks the addr-map code to use void __iomem * where
appropriate instead of u32, as per the suggestion of Arnd
Bergmann.
(*) Second patch introducing PLAT_ORION_LEGACY, which allows the
Marvell 370/XP platforms to be part of PLAT_ORION, and therefore
re-use the existing address decoding code.
(*) Third patch making a small change to an address decoding
structure so that we can define at runtime the virtual address of
the configuration registers. This is needed as on Armada 370/XP
the address decoding "controller" is declared in the Device Tree.
(*) Fourth patch adding the 370/XP address decoding code itself. For
now, it only maps the BootROM on Armada XP.
(*) Fifth path adding the necessary DT code to instantiate the
address decoding "controller".
Changes since v2:
* Remove one more useless (void __iomem *) cast in the Armada 370/XP
addr-map.c file, as noticed by Arnd Bergmann.
Changes since v1:
* Use void __iomem * in addr-map code. Suggested by Arnd Bergmann.
* Add Acked-by on patches 2->5 from Gr?gory Cl?ment
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
I'm getting the following build error with orion_nand enabled:
CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No
such file or directory
compilation terminated.
I don't have time to look at it right now, hopefully I can look at it
tomorrow or this weekend.
thx,
Jason.
From: Thomas Petazzoni <hidden> Date: 2012-08-17 13:21:56
Hello,
Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper [off-list ref] a ?crit :
quoted
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
I'm getting the following build error with orion_nand enabled:
CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No
such file or directory
compilation terminated.
I don't have time to look at it right now, hopefully I can look at it
tomorrow or this weekend.
I have just built your boards-for-v3.7 for Kirkwood (which includes the
orion_nand driver) and it builds just fine.
Are you perhaps trying to enable the orion_nand driver for a mach-mvebu
platform (Armada 370 or XP)? If it's the case, then yes, this build
breakage is expected: we haven't enabled any of the I/O for now, so we
don't have hardware.h yet. This is not something that is broken due to
the address decoding changes.
If however my guess was wrong, could you send me the failing .config so
that I can reproduce and investigate?
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: Jason Cooper <hidden> Date: 2012-08-19 01:23:03
On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper [off-list ref] a ?crit :
quoted
quoted
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
I'm getting the following build error with orion_nand enabled:
CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No
such file or directory
compilation terminated.
Are you perhaps trying to enable the orion_nand driver for a mach-mvebu
platform (Armada 370 or XP)? If it's the case, then yes, this build
breakage is expected: we haven't enabled any of the I/O for now, so we
don't have hardware.h yet. This is not something that is broken due to
the address decoding changes.
Ok, I've added Arnd and Olof to the CC. The above is exactly what I
did.
Arnd, how extensive is the 'make randconfig' testing in next? Is this
something that needs to be fixed before we push? I found it by a fluke,
but the right randconfig would light it up as well.
thx,
Jason.
On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
quoted
Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper [off-list ref] a ?crit :
quoted
quoted
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
I'm getting the following build error with orion_nand enabled:
CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No
such file or directory
compilation terminated.
Are you perhaps trying to enable the orion_nand driver for a mach-mvebu
platform (Armada 370 or XP)? If it's the case, then yes, this build
breakage is expected: we haven't enabled any of the I/O for now, so we
don't have hardware.h yet. This is not something that is broken due to
the address decoding changes.
Ok, I've added Arnd and Olof to the CC. The above is exactly what I
did.
Arnd, how extensive is the 'make randconfig' testing in next? Is this
something that needs to be fixed before we push? I found it by a fluke,
but the right randconfig would light it up as well.
If there is a bug you know about, you should fix it. In the above
example, I would guess that you should not actually need to include
mach/hardware.h, so the fix should be simple. In general, we should
eliminate mach/hardware.h where we can and put register locations
into resource, and offsets into the drivers themselves.
Arnd
From: Thomas Petazzoni <hidden> Date: 2012-08-21 09:46:30
Le Sat, 18 Aug 2012 21:23:03 -0400,
Jason Cooper [off-list ref] a ?crit :
On Fri, Aug 17, 2012 at 03:21:56PM +0200, Thomas Petazzoni wrote:
quoted
Le Thu, 16 Aug 2012 14:37:08 -0400,
Jason Cooper [off-list ref] a ?crit :
quoted
quoted
Whole series applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7
I'm getting the following build error with orion_nand enabled:
CC drivers/mtd/nand/orion_nand.o
drivers/mtd/nand/orion_nand.c:24:27: fatal error: mach/hardware.h: No
such file or directory
compilation terminated.
Are you perhaps trying to enable the orion_nand driver for a mach-mvebu
platform (Armada 370 or XP)? If it's the case, then yes, this build
breakage is expected: we haven't enabled any of the I/O for now, so we
don't have hardware.h yet. This is not something that is broken due to
the address decoding changes.
Ok, I've added Arnd and Olof to the CC. The above is exactly what I
did.
Arnd, how extensive is the 'make randconfig' testing in next? Is this
something that needs to be fixed before we push? I found it by a fluke,
but the right randconfig would light it up as well.
Well, this build failure is not caused by the address decoding changes
themselves. So the breakage you're seeing with that particular
configuration already exists. We would like to get these address
decoding changes merged so that we can make progress on the SMP support.
In parallel to that, we will start enabling the different I/O: network
interfaces, SATA, XOR engines, USB, etc. During this work, we'll
progressively make all these drivers compatible with mach-mvebu and
Armada 370/XP, and therefore fix the build issues like the one you're
seeing.
Or maybe, you want me to change the "depends on PLAT_ORION" of the
Orion NAND driver to "depends on PLAT_ORION_LEGACY" so that this driver
cannot be selected for now with mach-mvebu? As part of the PLAT_ORION
-> PLAT_ORION_LEGACY conversion, it would make sense. Of course, I
would do it for the other drivers as well (crypto, dma, etc.).
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On 8/21/12, Thomas Petazzoni [off-list ref] wrote:
Or maybe, you want me to change the "depends on PLAT_ORION" of the
Orion NAND driver to "depends on PLAT_ORION_LEGACY" so that this driver
cannot be selected for now with mach-mvebu? As part of the PLAT_ORION
-> PLAT_ORION_LEGACY conversion, it would make sense. Of course, I
would do it for the other drivers as well (crypto, dma, etc.).
Thomas,
I have reworked addr-map to allow for both Armada 370/XP and Orion SoCs
merging into mach-mvebu. Instead of reusing PLAT_ORION this is totally
independent but reusing as much code as possible. I can send it hopefully
today if I get it cleaned up. I also have irq-mvebu, irq-orion, and time-mvebu
patches that merge code. With that patches booting Dove into mach-mvebu
works until DMA kicks in because XOR hasn't event touched for DT support
and is still missing.
Armada 370/XP should still work as they do with current patches in for-3.7
with little changes in DT. But that of course must be tested by you.
Sebastian
From: Thomas Petazzoni <hidden> Date: 2012-08-21 11:50:45
Le Tue, 21 Aug 2012 12:37:24 +0200,
Sebastian Hesselbarth [off-list ref] a ?crit :
I have reworked addr-map to allow for both Armada 370/XP and Orion SoCs
merging into mach-mvebu. Instead of reusing PLAT_ORION this is totally
independent but reusing as much code as possible. I can send it hopefully
today if I get it cleaned up. I also have irq-mvebu, irq-orion, and time-mvebu
patches that merge code. With that patches booting Dove into mach-mvebu
works until DMA kicks in because XOR hasn't event touched for DT support
and is still missing.
Armada 370/XP should still work as they do with current patches in for-3.7
with little changes in DT. But that of course must be tested by you.
Ok, I will look at your code, but the purpose of
PLAT_ORION/PLAT_ORION_LEGACY was not only to re-use the addr-map code,
but also to allow drivers to access the header files containing their
platform_data structure and other stuff (i.e, all the header files from
arch/arm/plat-orion/include/). How do you handle this problem if
MACH_MVEBU is not a PLAT_ORION platform?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On 8/21/12, Thomas Petazzoni [off-list ref] wrote:
Ok, I will look at your code, but the purpose of
PLAT_ORION/PLAT_ORION_LEGACY was not only to re-use the addr-map code,
but also to allow drivers to access the header files containing their
platform_data structure and other stuff (i.e, all the header files from
arch/arm/plat-orion/include/). How do you handle this problem if
MACH_MVEBU is not a PLAT_ORION platform?
Hmm, ok I wasn't aware of that. But I have a bad feeling about joining
PLAT_ORION into MACH_MVEBU if you want to have ORION replaced
by MVEBU in the future. Maybe it is better here to put all you need into
mach-mvebu/include/mach/legacy.h that can be easily abandoned when
everything is ported to something more general.
I know it is code duplication but it is only for the purpose of removing
PLAT_ORION later on.
Sebastian
From: Thomas Petazzoni <hidden> Date: 2012-08-27 23:35:27
Jason,
I investigated a little bit, and found out that orion_nand driver was
the only PLAT_ORION driver needing <mach/hardware.h>, and in fact this
include was not needed. The attached patch therefore removes this
include from orion_nand.
Thanks,
Thomas
From: Thomas Petazzoni <hidden> Date: 2012-08-27 23:35:28
Commit c085d965fb63ac3b4cc7379d45588c0b39e2bdb0 made the ARCH_MVEBU
platform select PLAT_ORION, which means that now all Orion drivers can
be enabled on ARCH_MVEBU. This works fine for most drivers, except for
orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does
not have a mach/hardware.h header (it is considered as a deprecated
practice).
It turns out that the <mach/hardware.h> include in orion_nand is not
necessary: the driver builds perfectly fine without it, so we simply
get rid of it.
Signed-off-by: Thomas Petazzoni <redacted>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd at lists.infradead.org
Cc: Artem Bityutskiy <dedekind1@gmail.com>
---
drivers/mtd/nand/orion_nand.c | 1 -
1 file changed, 1 deletion(-)
On Tue, Aug 28, 2012 at 01:35:28AM +0200, Thomas Petazzoni wrote:
quoted hunk
Commit c085d965fb63ac3b4cc7379d45588c0b39e2bdb0 made the ARCH_MVEBU
platform select PLAT_ORION, which means that now all Orion drivers can
be enabled on ARCH_MVEBU. This works fine for most drivers, except for
orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does
not have a mach/hardware.h header (it is considered as a deprecated
practice).
It turns out that the <mach/hardware.h> include in orion_nand is not
necessary: the driver builds perfectly fine without it, so we simply
get rid of it.
Signed-off-by: Thomas Petazzoni <redacted>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd at lists.infradead.org
Cc: Artem Bityutskiy <dedekind1@gmail.com>
---
drivers/mtd/nand/orion_nand.c | 1 -
1 file changed, 1 deletion(-)
Hi Thomas
I compiled tested on Dove, Kirkwood, Orion5x and mv78xx0.
Tested-by: Andrew Lunn <andrew@lunn.ch>
One other driver you might want to look at is:
drivers/watchdog/orion_wdt.c
It uses <mach/bridge-regs.h>
Andrew
One other driver you might want to look at is:
drivers/watchdog/orion_wdt.c
It uses <mach/bridge-regs.h>
Andrew, Thomas,
both current watchdog and timer are using the bridge-regs to clear the
interrupt cause. On orion the cause register is located in bridge-regs.
From the work on timer together with Gregory, I expect Armada 370/XP
to have the watchdog cause bit also within timer registers.
Sebastian
From: Thomas Petazzoni <hidden> Date: 2012-08-28 12:22:36
Le Tue, 28 Aug 2012 11:11:39 +0200,
Andrew Lunn [off-list ref] a ?crit :
I compiled tested on Dove, Kirkwood, Orion5x and mv78xx0.
Tested-by: Andrew Lunn <andrew@lunn.ch>
Thanks! Will Jason take care of merging this on top of the previous
address decoding patches? Note that if you want to keep build
bisectability, it should be merged before my "arm: plat-orion: introduce
PLAT_ORION_LEGACY hidden config option" patch.
One other driver you might want to look at is:
drivers/watchdog/orion_wdt.c
It uses <mach/bridge-regs.h>
This driver is:
config ORION_WATCHDOG
tristate "Orion watchdog"
depends on ARCH_ORION5X || ARCH_KIRKWOOD
so it isn't selectable with ARCH_MVEBU, so it will not cause problems
for now. Of course, at some point, we'll have a look at the watchdog
driver but for now, it's fine.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: Jason Cooper <hidden> Date: 2012-08-28 18:12:47
On Tue, Aug 28, 2012 at 01:35:28AM +0200, Thomas Petazzoni wrote:
Commit c085d965fb63ac3b4cc7379d45588c0b39e2bdb0 made the ARCH_MVEBU
platform select PLAT_ORION, which means that now all Orion drivers can
be enabled on ARCH_MVEBU. This works fine for most drivers, except for
orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does
not have a mach/hardware.h header (it is considered as a deprecated
practice).
It turns out that the <mach/hardware.h> include in orion_nand is not
necessary: the driver builds perfectly fine without it, so we simply
get rid of it.
Signed-off-by: Thomas Petazzoni <redacted>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd at lists.infradead.org
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Applied to:
git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2
thx,
Jason.
On Tue, 2012-08-28 at 01:35 +0200, Thomas Petazzoni wrote:
Commit c085d965fb63ac3b4cc7379d45588c0b39e2bdb0 made the ARCH_MVEBU
platform select PLAT_ORION, which means that now all Orion drivers can
be enabled on ARCH_MVEBU. This works fine for most drivers, except for
orion_nand, because it includes <mach/hardware.h>, but mach-mvebu does
not have a mach/hardware.h header (it is considered as a deprecated
practice).
It turns out that the <mach/hardware.h> include in orion_nand is not
necessary: the driver builds perfectly fine without it, so we simply
get rid of it.
Signed-off-by: Thomas Petazzoni <redacted>