From: Thomas Petazzoni <hidden> Date: 2012-08-03 13:10:26
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 four patches:
(*) First 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.
(*) Second 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.
(*) Third patch adding the 370/XP address decoding code itself. For
now, it only maps the BootROM on Armada XP.
(*) Fourth path adding the necessary DT code to instantiate the
address decoding "controller".
Thanks,
Thomas Petazzoni
From: Thomas Petazzoni <hidden> Date: 2012-08-03 13:10:27
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>
---
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-03 13:10:28
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>
---
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;-constu32bridge_virt_base;+u32bridge_virt_base;/* If NULL, the default cpu_win_can_remap will be used, usingthevalueinremappable_wins*/
From: Thomas Petazzoni <hidden> Date: 2012-08-03 13:10:29
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>
---
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);++return(void__iomem*)(cfg->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=(u32)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,+(u32)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);
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>
[...]
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
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>
[...]
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
his 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>
[...]
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
@@ -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;+u32bridge_virt_base;/* If NULL, the default cpu_win_can_remap will be used, usingthevalueinremappable_wins*/
It would be nice to also change the type of this to void __iomem*, since you are
already touching the bridge_virt_base.
Arnd
From: Thomas Petazzoni <hidden> Date: 2012-08-03 13:48:56
Le Fri, 3 Aug 2012 13:41:32 +0000,
Arnd Bergmann [off-list ref] a ?crit :
quoted
+ u32 bridge_virt_base; /* If NULL, the default cpu_win_can_remap will be used, using the value in remappable_wins */
It would be nice to also change the type of this to void __iomem*, since you are
already touching the bridge_virt_base.
Yeah, I was also thinking about this cleanup. Will rework my patch
series to include a patch fixing this before doing the other changes.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
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.
Makes sense. I wonder if there is a proper way to describe the
setting in the device tree anyway, given that there is more than one
valid option to do it.
Arnd
From: Thomas Petazzoni <hidden> Date: 2012-08-04 16:27:30
Le Fri, 3 Aug 2012 14:23:09 +0000,
Arnd Bergmann [off-list ref] a ?crit :
On Friday 03 August 2012, Thomas Petazzoni wrote:
quoted
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.
Makes sense. I wonder if there is a proper way to describe the
setting in the device tree anyway, given that there is more than one
valid option to do it.
Well, we could do something like:
addr-decoding at d0020000 {
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
window at 0 {
/* Window number */
cell-index = <0>;
/* Physical address and size at which the device will be mapped. */
reg = <0xfff00000 0x100000>;
/* Which device is being mapped. Can either have 1
integer (for "big" devices) or 2 integers (for devices
in the "Device Bus") */
marvell,target = <0x1 0x1d>;
/* Optional. Remapping address */
marvell,remap = <...>;
};
window at 12 {
cell-index = <12>;
reg = <0x... 0x....>;
marvell,target = <0x4>;
};
};
This is just a rough draft, just written in the mail, I haven't even
tried writing code that would work with it, but it should be relatively
easy to do.
Would that make sense? Of course, suggestions welcome, I'm not an
expert on how to decide what is the best DT encoding for such data.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
On Saturday 04 August 2012, Thomas Petazzoni wrote:
Well, we could do something like:
addr-decoding at d0020000 {
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
window at 0 {
/* Window number */
cell-index = <0>;
/* Physical address and size at which the device will be mapped. */
reg = <0xfff00000 0x100000>;
/* Which device is being mapped. Can either have 1
integer (for "big" devices) or 2 integers (for devices
in the "Device Bus") */
marvell,target = <0x1 0x1d>;
/* Optional. Remapping address */
marvell,remap = <...>;
};
window at 12 {
cell-index = <12>;
reg = <0x... 0x....>;
marvell,target = <0x4>;
};
};
This is just a rough draft, just written in the mail, I haven't even
tried writing code that would work with it, but it should be relatively
easy to do.
Would that make sense? Of course, suggestions welcome, I'm not an
expert on how to decide what is the best DT encoding for such data.
The point that I'm wondering about is where the physical address
comes from. This one is not describing the hardware at all, and the OS
is free to pick any other address, so why would be put that particular
one into the device tree?
Maybe you can find a way to better represent the actual address hierarchy
in a way that shows the remapping. I don't understand how the remapping
works, but I think what we would need for this is an intermediate
large address space and a ranges property that translate the large
addresses into bus addresses, but with the option of the driver for that
intermediate bus overriding the mapping.
remapped-bus at d0020000 {
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
#address-cells = <3>;
#size-cells = <1>;
ranges = <0x1 0x1d 0x0 /* device 1 address */
0xfff00000 /* host address */
0x100000> /* length */
<02 0x1e 0x0 /* device 2 address */
0xffe00000 /* host address */
0x100000> /* length */
device at 1.1d.0 {
compatible = "some-device";
reg = <0x1 0x1d 0x0 0x5000>
};
};
Arnd