From: Thomas Petazzoni <hidden> Date: 2012-07-02 15:39:25
Arnd, Olof,
You'll find in this patch set the seventh version of the initial
support for a new family of ARMv7-compatible Marvell SoCs.
As for the previous releases, both the Armada 370 and the Armada XP
SoCs are supported in this directory, and we are able to build a
single kernel image that boots on both SoCs. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set. We are currently using Marvell evaluation boards for
both of those SoCs, and the support for those boards is added in this
patch set.
We remained focused on a limited preliminary support which only
includes the necessary code for timer and IRQ support, the serial
controller is a standard 16550-compatible one. The diffstat looks
like:
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt | 23 +
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt | 11
Documentation/devicetree/bindings/arm/armada-370-xp.txt | 24 +
Documentation/devicetree/bindings/arm/mvebu-system-controller.txt | 17
MAINTAINERS | 8
arch/arm/Kconfig | 14
arch/arm/Makefile | 1
arch/arm/boot/dts/armada-370-db.dts | 42 +
arch/arm/boot/dts/armada-370-xp.dtsi | 68 +++
arch/arm/boot/dts/armada-370.dtsi | 35 +
arch/arm/boot/dts/armada-xp-db.dts | 50 ++
arch/arm/boot/dts/armada-xp.dtsi | 55 ++
arch/arm/configs/mvebu_defconfig | 46 ++
arch/arm/mach-mvebu/Kconfig | 16
arch/arm/mach-mvebu/Makefile | 2
arch/arm/mach-mvebu/Makefile.boot | 1
arch/arm/mach-mvebu/armada-370-xp.c | 63 ++
arch/arm/mach-mvebu/common.h | 23 +
arch/arm/mach-mvebu/include/mach/armada-370-xp.h | 22
arch/arm/mach-mvebu/include/mach/debug-macro.S | 24 +
arch/arm/mach-mvebu/include/mach/timex.h | 13
arch/arm/mach-mvebu/include/mach/uncompress.h | 43 +
arch/arm/mach-mvebu/irq-armada-370-xp.c | 133 +++++
arch/arm/mach-mvebu/system-controller.c | 105 ++++
drivers/clocksource/Kconfig | 3
drivers/clocksource/Makefile | 3
drivers/clocksource/time-armada-370-xp.c | 226 ++++++++++
include/linux/time-armada-370-xp.h | 18
28 files changed, 1088 insertions(+), 1 deletion(-)
This patch set, and the support for those SoCs, started as a
collaborative effort from Marvell engineers (who have done the initial
development work) and Free Electrons engineers (who are reshaping the
code for mainline submission, adding device tree support, etc.). This
effort has also received contributions from Ben Dooks from Codethink.
The patch set is based on your arm-soc/for-next branch (updated on
Sunday 1st July).
Changes between v6 and v7:
* Take into account comments from Thomas Gleixner on the clocksource
driver: don't check delta == 0, don't disable interrupts in
->set_next_event() and ->set_mode() as it is already done by the
clock infrastructure, and use the clockevents_config_and_register()
helper function to register the clockevents device with less code.
Changes between v5 and v6:
* Clarify the error message shown when restarting but no system
controller was configured, and use pr_err() instead of pr_warn.
* Remove the 'asmlinkage' qualifier from common.h, since it is
useless in a header file (thanks to Ben Dooks for noticing)
* Integrate two patches from Ben Dooks (fixup style/indentation, and
check result of of_match_node() in the system-controller.c
driver). Since those patches were fixing relatively minor issues, I
simply folded them into the original corresponding patches, in
order to keep a nice a clean patch set.
* Rebased on top of the latest arm-soc/for-next branch.
Changes between v4 and v5:
* For system controller mvebu_other is renamed to orion for a better
description of the subset including Dove, mv78xx0, Kirkwood and
Orion5x.
* The system controller code is improved following Arnd advices. Now
it uses pointers to data structures instead of defines and if/else
statements.
* The restart function never returns anymore, even if no system
controller was configured.
* The listing of the MVEBU family device tree in the binding
documentation for system controller is fixed.
Changes between v3 and v4:
* If the system controller device is not found during initialization,
no more warnings are issued and the function doesn't fail.
* The system controller driver becomes more generic to handle the
other mvebu SoCs. Inside the device tree it is now called either
armada-370-xp-system-controller or mvebu-other-system-controller.
Then depending of the compatibility name the driver selects the
accurate offset and bit mask. The way to handle different variants
of the same controller was inspired by the of_serial.c file.
* A documentation was added for the "system-controller" binding
* The "select CPU_V7" was moved from ARCH_MVEBU in arch/arm/Kconfig
to MACH_ARMADA_370_XP in arch/arm/mach-mvebu/Kconfig. Thanks to this
the other mvebu" machines will be able to use CPU_V5
* Some armada_370_xp strings have been renamed to armada-370-xp to
keep the coherency with other parts of the code.
Changes between v2 and v3:
* The timer support code has been moved to drivers/clocksource/ and
the necessary related changes have been made
* There is now a minimal "system-controller" driver that gets
instantiated through DT entries. This driver allows to expose the
features made available through a set of miscellaneous registers
that do not belong to any specific device in the SoC. For the
moment, we only use it to implement the .restart() hook.
* The defconfig has been changed to allow the support for up to four
8250-compatible serial ports, since Armada XP has four such
ports. The DTS file has been modified to enable those four ports,
and they have all been tested successfully on the Armada XP DB
development platform.
* Moved the "arm: mach-mvebu: add compilation/configuration change"
patch towards the end of the patch set
* Marked the "serial" device as "disabled" in the .dtsi file, and
enable the ones that are actually used in the board specific .dts
file.
* Dropped the _dt suffix as the device tree support is implicit now.
* Don't use anymore a MVEBU_REGS_PHYS_BASE define and reintroduce a
ARMADA_370_XP_REGS_PHYS_BASE define.
Changes between v1 and v2:
* Use the mach-mvebu directory as suggested on the mailing-list. So
far, this directory only contains the support for Armada 370/XP,
but the plan is that it should ultimately contain the support for
all other SoCs produced by the Marvell Engineering Business Unit.
* Converted most the "armada" word by the "mvebu", but as some code
remains specific to the Armada 370 and Armada XP SOC, then created
also the aramada_370_xp suffix for this part. This suffix was
dedicated for the irq and timer part. It was also used for the
register related to the reset part. And of course it was also used
for the device tree part.
* Merged axp-dt.c and a370-dt.c files in one single
armada_370_xp-dt.c file.
* Deleted most of the mapping address in include/mach/armada.h and
split it in two headers file:
- mvebu.h which contains the virtual and physical mapping for the
internal registers of the mvebu SOC. This ones are mainly used for
the early print during boot.
- armada_370_xp which contains the registers offset and mask for
resetting the CPU.
* Removed unused headers such as
- hardware.h by directly including accurate header when needed
- gpio.h by removing the dependencies to PLAT-ORION
- io.h no more needed for CPI
- irqs.h by using SPARSE_IRQ
- system.h no more needed for new SOC
* Removed the PCI related code as it was not necessary for the
initial submission
* Removed all the PLAT-ORION dependencies remaining
* Ensured property reading checks for error when getting data from
device tree in the timer file. This was a patch from Ben Dooks with
the following comments:
"The call to of_property_read_u32() only checks for the value that
the clk variable is set to being non-zero, and not the return value
of the call itself.
This caused a system without the clock-frequency attribute to fail
to boot as it used a random value on the stack to setup the system
timers and thus cause an interrupt storm.
Also ensure clk is set to zero, to avoid warnings."
* Converted irq controller code to use SPARSE_IRQ
* Added the following bug fixes and improvements in irq.c from Ben
Dooks
- MPIC: BUG_ON() if the of_iomap() fails: Ensure that if either
resource is missing, we stop the kernel in a reasonably fatal way.
- MPIC: Move main register base to base of MPIC registers: The
current kernel driver had the MPIC base at the base of the block
containing the MPIC and not the MPIC itself. Change this value in
the driver and the .dtsi file
Also change the register size in the .dtsi to be the size of the
register range for the MIPC and not the block it is in.
- MPIC: Move per-cpu register base: The current kernel driver had
the MPIC per-cpu register base at the base of the per-cpu register
block and not at the base of the specific per-cpu interrupt
registers.
Move the driver and .dtsi to use the correct base and size.
- MPIC: number fetch should use irqd_to_hwirq(): The mask and unmask
routines are assuming that d->irq is a 1:1 mapping with the
interrupt hardware. Use the irqd_to_hwirq() call to map the
irq_data to the hardware irq number directly.
- MPIC: read number of interrupts from control register: Read the
number of MPIC interrupts from the controller and only register
that many.
Best regards,
Thomas Petazzoni
@@ -0,0 +1,105 @@+/*+*SystemcontrollersupportforArmada370andXPplatforms.+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*TheArmada370andArmadaXPSoCsbothhavearangeof+*miscellaneousregisters,thatdonotbelongtoaparticulardevice,+*butratherprovidesystem-levelfeatures.Thisbasic+*system-controllerdriverprovidesadevicetreebindingforthose+*registers,andimplementsutilityfunctionsofferingvarious+*featuresrelatedtothoseregisters.+*+*Fornow,thefeaturesetislimitedtorestartingtheplatformbya+*soft-reset,butitmightbeextendedinthefuture.+*/++#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/of_address.h>+#include<linux/io.h>++staticvoid__iomem*system_controller_base;++structmvebu_system_controller{+u32rstoutn_mask_offset;+u32system_soft_reset_offset;++u32rstoutn_mask_reset_out_en;+u32system_soft_reset;+};+staticstructmvebu_system_controller*mvebu_sc;++conststructmvebu_system_controllerarmada_370_xp_system_controller={+.rstoutn_mask_offset=0x60,+.system_soft_reset_offset=0x64,+.rstoutn_mask_reset_out_en=0x1,+.system_soft_reset=0x1,+};++conststructmvebu_system_controllerorion_system_controller={+.rstoutn_mask_offset=0x108,+.system_soft_reset_offset=0x10c,+.rstoutn_mask_reset_out_en=0x4,+.system_soft_reset=0x1,+};++staticstructof_device_idof_system_controller_table[]={+{+.compatible="marvell,orion-system-controller",+.data=(void*)&orion_system_controller,+},{+.compatible="marvell,armada-370-xp-system-controller",+.data=(void*)&armada_370_xp_system_controller,+},+{/* end of list */},+};++voidmvebu_restart(charmode,constchar*cmd)+{+if(!system_controller_base){+pr_err("Cannot restart, system-controller not available: check the device tree\n");+}else{+/*+*EnablesoftresettoassertRSTOUTn.+*/+writel(mvebu_sc->rstoutn_mask_reset_out_en,+system_controller_base++mvebu_sc->rstoutn_mask_offset);+/*+*Assertsoftreset.+*/+writel(mvebu_sc->system_soft_reset,+system_controller_base++mvebu_sc->system_soft_reset_offset);+}++while(1)+;+}++staticint__initmvebu_system_controller_init(void)+{+structdevice_node*np;++np=of_find_matching_node(NULL,of_system_controller_table);+if(np){+conststructof_device_id*match=+of_match_node(of_system_controller_table,np);+BUG_ON(!match);+system_controller_base=of_iomap(np,0);+mvebu_sc=(structmvebu_system_controller*)match->data;+}++return0;+}++arch_initcall(mvebu_system_controller_init);
@@ -0,0 +1,68 @@+/*+*DeviceTreeIncludefileforMarvellArmada370andArmadaXPSoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*BenDooks<ben.dooks@codethink.co.uk>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ThisfilecontainsthedefinitionsthatarecommontotheArmada+*370andArmadaXPSoC.+*/++/include/"skeleton.dtsi"++/{+model="Marvell Armada 370 and XP SoC";+compatible="marvell,armada_370_xp";++cpus{+cpuat0{+compatible="marvell,sheeva-v7";+};+};++mpic:interrupt-controlleratd0020000{+compatible="marvell,mpic";+#interrupt-cells=<1>;+#address-cells=<1>;+#size-cells=<1>;+interrupt-controller;+};++soc{+#address-cells=<1>;+#size-cells=<1>;+compatible="simple-bus";+interrupt-parent=<&mpic>;+ranges;++serialatd0012000{+compatible="ns16550";+reg=<0xd00120000x100>;+reg-shift=<2>;+interrupts=<41>;+status="disabled";+};+serialatd0012100{+compatible="ns16550";+reg=<0xd00121000x100>;+reg-shift=<2>;+interrupts=<42>;+status="disabled";+};++timeratd0020300{+compatible="marvell,timer";+reg=<0xd00203000x30>;+interrupts=<37>,<38>,<39>,<40>;+};+};+};+
@@ -0,0 +1,35 @@+/*+*DeviceTreeIncludefileforMarvellArmada370familySoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ContainsdefinitionsspecifictotheArmada370SoCthatarenot+*commontoallArmadaSoCs.+*/++/include/"armada-370-xp.dtsi"++/{+model="Marvell Armada 370 family SoC";+compatible="marvell,armada370","marvell,armada-370-xp";++mpic:interrupt-controlleratd0020000{+reg=<0xd0020a000x1d0>,+<0xd00218700x58>;+};++soc{+system-controlleratd0018200{+compatible="marvell,armada-370-xp-system-controller";+reg=<0xd00182000x100>;+};+};+};
@@ -0,0 +1,55 @@+/*+*DeviceTreeIncludefileforMarvellArmadaXPfamilySoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*BenDooks<ben.dooks@codethink.co.uk>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ContainsdefinitionsspecifictotheArmada370SoCthatarenot+*commontoallArmadaSoCs.+*/++/include/"armada-370-xp.dtsi"++/{+model="Marvell Armada XP family SoC";+compatible="marvell,armadaxp","marvell,armada-370-xp";++mpic:interrupt-controlleratd0020000{+reg=<0xd0020a000x1d0>,+<0xd00218700x58>;+};++soc{+serialatd0012200{+compatible="ns16550";+reg=<0xd00122000x100>;+reg-shift=<2>;+interrupts=<43>;+status="disabled";+};+serialatd0012300{+compatible="ns16550";+reg=<0xd00123000x100>;+reg-shift=<2>;+interrupts=<44>;+status="disabled";+};++timeratd0020300{+marvell,timer-25Mhz;+};++system-controlleratd0018200{+compatible="marvell,armada-370-xp-system-controller";+reg=<0xd00182000x500>;+};+};+};
@@ -2,6 +2,15 @@ if ARCH_MVEBUmenu"Marvell SOC with device tree"+configMACH_ARMADA_370_XP+bool"Marvell Armada 370 and Aramada XP boards"+selectARMADA_370_XP_TIMER+selectCPU_V7+help++Say'Y'hereifyouwantyourkerneltosupportboardsbasedon+MarvellArmada370orArmadaXPwithdevicetree.+endmenuendif
@@ -0,0 +1,23 @@+Marvell Armada 370 and Armada XP Interrupt Controller+-----------------------------------------------------++Required properties:+- compatible: Should be "marvell,mpic"+- interrupt-controller: Identifies the node as an interrupt controller.+- #interrupt-cells: The number of cells to define the interrupts. Should be 1.+ The cell is the IRQ number+- reg: Should contain PMIC registers location and length. First pair+ for the main interrupt registers, second pair for the per-CPU+ interrupt registers++Example:++ mpic: interrupt-controller at d0020000 {+ compatible = "marvell,mpic";+ #interrupt-cells = <1>;+ #address-cells = <1>;+ #size-cells = <1>;+ interrupt-controller;+ reg = <0xd0020000 0x1000>,+ <0xd0021000 0x1000>;+ };
@@ -0,0 +1,11 @@+Marvell Armada 370 and Armada XP Global Timers+----------------------------------------------++Required properties:+- compatible: Should be "marvell,timer"+- interrupts: Should contain the list of Global Timer interrupts+- reg: Should contain the base address of the Global Timer registers++Optional properties:+- marvell,timer-25Mhz: Tells whether the Global timer supports the 25+ Mhz fixed mode (available on Armada XP and not on Armada 370)
@@ -0,0 +1,24 @@+Marvell Armada 370 and Armada XP Platforms Device Tree Bindings+---------------------------------------------------------------++Boards with a SoC of the Marvell Armada 370 and Armada XP families+shall have the following property:++Required root node property:++compatible: must contain "marvell,armada-370-xp"++In addition, boards using the Marvell Armada 370 SoC shall have the+following property:++Required root node property:++compatible: must contain "marvell,armada370"++In addition, boards using the Marvell Armada XP SoC shall have the+following property:++Required root node property:++compatible: must contain "marvell,armadaxp"+
@@ -0,0 +1,46 @@+CONFIG_EXPERIMENTAL=y+CONFIG_SYSVIPC=y+CONFIG_NO_HZ=y+CONFIG_HIGH_RES_TIMERS=y+CONFIG_LOG_BUF_SHIFT=14+CONFIG_BLK_DEV_INITRD=y+CONFIG_EXPERT=y+CONFIG_SLAB=y+CONFIG_MODULES=y+CONFIG_MODULE_UNLOAD=y+CONFIG_ARCH_MVEBU=y+CONFIG_MACH_ARMADA_370_XP=y+CONFIG_AEABI=y+CONFIG_HIGHMEM=y+CONFIG_USE_OF=y+CONFIG_ZBOOT_ROM_TEXT=0x0+CONFIG_ZBOOT_ROM_BSS=0x0+CONFIG_ARM_APPENDED_DTB=y+CONFIG_VFP=y+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"+CONFIG_SERIAL_8250=y+CONFIG_SERIAL_8250_CONSOLE=y+CONFIG_SERIAL_OF_PLATFORM=y+CONFIG_EXT2_FS=y+CONFIG_EXT3_FS=y+# CONFIG_EXT3_FS_XATTR is not set+CONFIG_ISO9660_FS=y+CONFIG_JOLIET=y+CONFIG_UDF_FS=m+CONFIG_MSDOS_FS=y+CONFIG_VFAT_FS=y+CONFIG_TMPFS=y+CONFIG_NLS_CODEPAGE_437=y+CONFIG_NLS_CODEPAGE_850=y+CONFIG_NLS_ISO8859_1=y+CONFIG_NLS_ISO8859_2=y+CONFIG_NLS_UTF8=y+CONFIG_MAGIC_SYSRQ=y+CONFIG_DEBUG_FS=y+# CONFIG_SCHED_DEBUG is not set+CONFIG_TIMER_STATS=y+# CONFIG_DEBUG_BUGVERBOSE is not set+CONFIG_DEBUG_INFO=y+CONFIG_DEBUG_USER=y+CONFIG_DEBUG_LL=y+CONFIG_EARLY_PRINTK=y
@@ -533,6 +533,18 @@ config ARCH_IXP4XXhelpSupportforIntel'sIXP4XX(XScale)familyofprocessors.+configARCH_MVEBU+bool"Marvell SOCs with Device Tree support"+selectGENERIC_CLOCKEVENTS+selectMULTI_IRQ_HANDLER+selectSPARSE_IRQ+selectCLKSRC_MMIO+selectGENERIC_IRQ_CHIP+selectIRQ_DOMAIN+selectCOMMON_CLK+help+SupportfortheMarvellSoCFamilywithdevicetreesupport+configARCH_DOVEbool"Marvell Dove"selectCPU_V7
@@ -987,6 +999,8 @@ endchoice# Kconfigs may be included either alphabetically (according to the# plat- suffix) or along side the corresponding mach-* source.#+source"arch/arm/mach-mvebu/Kconfig"+source"arch/arm/mach-at91/Kconfig"source"arch/arm/mach-bcmring/Kconfig"
@@ -894,6 +894,14 @@ ARM/MAGICIAN MACHINE SUPPORT M: Philipp Zabel <philipp.zabel@gmail.com> S: Maintained+ARM/Marvell Armada 370 and Armada XP SOC support+M: Gregory Clement <gregory.clement@free-electrons.com>+M: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>+M: Lior Amsalem <alior@marvell.com>+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)+S: Maintained+F: arch/arm/mach-mvebu/+ ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support M: Jason Cooper <jason@lakedaemon.net> M: Andrew Lunn <andrew@lunn.ch>
From: Thomas Petazzoni <hidden> Date: 2012-07-02 15:39:34
From: Ben Dooks <redacted>
Read the number of MPIC interrupts from the controller and only register
that many.
[gregory.clement at free-electrons.com: rename armada symbol name to fit
with new name: armada_370_xp]
Signed-off-by: Ben Dooks <redacted>
Signed-off-by: Gregory CLEMENT <redacted>
Signed-off-by: Thomas Petazzoni <redacted>
Signed-off-by: Lior Amsalem <redacted>
---
arch/arm/mach-mvebu/irq-armada-370-xp.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
From: Thomas Gleixner <hidden> Date: 2012-07-02 17:40:10
On Mon, 2 Jul 2012, Thomas Petazzoni wrote:
From: Gregory Clement <redacted>
Timer 0 is used as free-running clocksource, while timer 1 is used as
clock_event_device.
Signed-off-by: Gregory CLEMENT <redacted>
Signed-off-by: Thomas Petazzoni <redacted>
Signed-off-by: Lior Amsalem <redacted>
Hi Thomas
What physical address does this come out to? All Orion platforms have
the serial port at the same place, 0xf1012000. If 370/XP is the same,
i suggest dropping this #include, hard code the address, and we share
the implementation for all SoCs.
If however, the ASIC engineers have decided to move it, we need some
extra logic to handle different base addresses for Dove and 370/XP
which should be supportable in one kernel binary.
Andrew
From: Thomas Petazzoni <hidden> Date: 2012-07-02 19:08:38
Hello Andrew,
Le Mon, 2 Jul 2012 20:33:30 +0200,
Andrew Lunn [off-list ref] a ?crit :
What physical address does this come out to? All Orion platforms have
the serial port at the same place, 0xf1012000. If 370/XP is the same,
i suggest dropping this #include, hard code the address, and we share
the implementation for all SoCs.
If however, the ASIC engineers have decided to move it, we need some
extra logic to handle different base addresses for Dove and 370/XP
which should be supportable in one kernel binary.
As per armada-370-xp.h:
#define ARMADA_370_XP_REGS_PHYS_BASE 0xd0000000
The physical address of the internal registers is 0xd0000000. It does
not seem to be configurable using the address decoding mechanism.
OMAP has some logic to handle this kind of problems, see
plat-omap/include/plat/uncompress.h. We can quite certainly overcome
this problem somehow.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
OMAP has some logic to handle this kind of problems, see
plat-omap/include/plat/uncompress.h. We can quite certainly overcome
this problem somehow.
That file says:
* Initialize the port based on the machine ID from the bootloader.
Which when using DT we don't have.
As you said, we can overcome this somehow. We just need to be aware
there will be changes here.
It would also be nice if Marvell ASIC engineers didn't randomly move
things around in the address space....
Andrew
OMAP has some logic to handle this kind of problems, see
plat-omap/include/plat/uncompress.h. We can quite certainly overcome
this problem somehow.
That file says:
* Initialize the port based on the machine ID from the bootloader.
Which when using DT we don't have.
As you said, we can overcome this somehow. We just need to be aware
there will be changes here.
It would also be nice if Marvell ASIC engineers didn't randomly move
things around in the address space....
For now, I'd suggest you don't try too hard to make this work for the
a combination of the mvebu platforms. There has been some discussion
about a solution that will work across multiple platform directories.
While that might take a little longer, I assume that we will find some
way to do it, so let's first unify all the other header files within
mvebu.
Arnd
It would also be nice if Marvell ASIC engineers didn't randomly move
things around in the address space....
They didn't. The _software_ engineers did.
As you might know, the Orion and Kirkwood SOCs have programmable
physical windows for most things, including PCI IO window, PCI mem
window, SDRAM window, NAND controller window, bridge peripheral window,
etc.
So you can change your physical address space as you wish. This was
made to accommodate whether you are a PCI host or a PCI client (think
wifi cards which are in the later category but still with this window
control block). This is also how the various SDRAM banks are remapped to
appear as a contiguous chunk of physical memory regardless of the
populated memory size in each bank.
Most of this is being partly set up (or set again) in the various
addr-map.c files.
Now it seems that all the u-Boot implementations for Orion/Kirkwood out
there have always moved the window containing the serial ports from its
default 0xd0000000 address to 0xf1000000. Why they did that I have no
idea. And Linux simply took those remapped physical addresses as
authoritative.
And whether or not Armada 370/XP still have this physical remap ability
I don't know. And if it does, then why didn't it follow the same
0xf1000000 tradition as all the other mvebu targets before them I don't
know either. Maybe this could be considered?
Nicolas
On Mon, Jul 02, 2012 at 11:48:42PM -0400, Nicolas Pitre wrote:
On Mon, 2 Jul 2012, Andrew Lunn wrote:
quoted
It would also be nice if Marvell ASIC engineers didn't randomly move
things around in the address space....
They didn't. The _software_ engineers did.
Ah, interesting. I never got that deep into the address mapping, i
just mechanically refactered it across all Orions without take too
much time to really understand what its doing.
Now it seems that all the u-Boot implementations for Orion/Kirkwood out
there have always moved the window containing the serial ports from its
default 0xd0000000 address to 0xf1000000. Why they did that I have no
idea. And Linux simply took those remapped physical addresses as
authoritative.
And whether or not Armada 370/XP still have this physical remap ability
I don't know. And if it does, then why didn't it follow the same
0xf1000000 tradition as all the other mvebu targets before them I don't
know either. Maybe this could be considered?
Thomas, Gregory, could you look at this?
Are the uboot source open, or are you using a proprietary Marvell
version?
When Arnd first proposed moving everything into one directory, i had a
quick look at the memory map. The Orions have more than just the
serial ports at the same address. If i remember correctly, I2C, SPI,
PCIE0, USB0, XOR, and ETH0 are all at the same physical
address. Unfortunately, they have different virtual addresses. So I
played around unifying the virtual address map.
Doing this will allow some code simplification, header file
simplification, and sharing of some .dtsi and DT across all Orion
systems.
Its not something i want to do right now, but having 370/XP the same
as Orion would be a step towards this.
Andrew
From: Thomas Petazzoni <hidden> Date: 2012-07-03 07:20:40
Hello,
Le Tue, 3 Jul 2012 09:09:27 +0200,
Andrew Lunn [off-list ref] a ?crit :
quoted
Now it seems that all the u-Boot implementations for Orion/Kirkwood out
there have always moved the window containing the serial ports from its
default 0xd0000000 address to 0xf1000000. Why they did that I have no
idea. And Linux simply took those remapped physical addresses as
authoritative.
And whether or not Armada 370/XP still have this physical remap ability
I don't know. And if it does, then why didn't it follow the same
0xf1000000 tradition as all the other mvebu targets before them I don't
know either. Maybe this could be considered?
Thomas, Gregory, could you look at this?
Yes, we will look into this with Marvell engineers.
Are the uboot source open, or are you using a proprietary Marvell
version?
As far as I know, there is no support in upstream U-Boot for Armada 370
and XP. We're currently using the internal Marvell U-Boot.
When Arnd first proposed moving everything into one directory, i had a
quick look at the memory map. The Orions have more than just the
serial ports at the same address. If i remember correctly, I2C, SPI,
PCIE0, USB0, XOR, and ETH0 are all at the same physical
address. Unfortunately, they have different virtual addresses. So I
played around unifying the virtual address map.
Doing this will allow some code simplification, header file
simplification, and sharing of some .dtsi and DT across all Orion
systems.
Its not something i want to do right now, but having 370/XP the same
as Orion would be a step towards this.
That sounds like a good idea of course, if possible.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Hi Thomas
"marvell,timer" is too generic. I would suggest using
marvell,armada-370-xp-timer, the same prefix as for the system
controller. It allows us to extend the code to handle Orion platforms,
in the same way the system controller does.
Andrew
@@ -0,0 +1,105 @@+/*+*SystemcontrollersupportforArmada370andXPplatforms.+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*TheArmada370andArmadaXPSoCsbothhavearangeof+*miscellaneousregisters,thatdonotbelongtoaparticulardevice,+*butratherprovidesystem-levelfeatures.Thisbasic+*system-controllerdriverprovidesadevicetreebindingforthose+*registers,andimplementsutilityfunctionsofferingvarious+*featuresrelatedtothoseregisters.+*+*Fornow,thefeaturesetislimitedtorestartingtheplatformbya+*soft-reset,butitmightbeextendedinthefuture.+*/++#include<linux/kernel.h>+#include<linux/init.h>+#include<linux/of_address.h>+#include<linux/io.h>++staticvoid__iomem*system_controller_base;++structmvebu_system_controller{+u32rstoutn_mask_offset;+u32system_soft_reset_offset;++u32rstoutn_mask_reset_out_en;+u32system_soft_reset;+};+staticstructmvebu_system_controller*mvebu_sc;++conststructmvebu_system_controllerarmada_370_xp_system_controller={+.rstoutn_mask_offset=0x60,+.system_soft_reset_offset=0x64,+.rstoutn_mask_reset_out_en=0x1,+.system_soft_reset=0x1,+};++conststructmvebu_system_controllerorion_system_controller={+.rstoutn_mask_offset=0x108,+.system_soft_reset_offset=0x10c,+.rstoutn_mask_reset_out_en=0x4,+.system_soft_reset=0x1,+};++staticstructof_device_idof_system_controller_table[]={+{+.compatible="marvell,orion-system-controller",+.data=(void*)&orion_system_controller,+},{+.compatible="marvell,armada-370-xp-system-controller",+.data=(void*)&armada_370_xp_system_controller,+},+{/* end of list */},+};++voidmvebu_restart(charmode,constchar*cmd)+{+if(!system_controller_base){+pr_err("Cannot restart, system-controller not available: check the device tree\n");+}else{+/*+*EnablesoftresettoassertRSTOUTn.+*/+writel(mvebu_sc->rstoutn_mask_reset_out_en,+system_controller_base++mvebu_sc->rstoutn_mask_offset);+/*+*Assertsoftreset.+*/+writel(mvebu_sc->system_soft_reset,+system_controller_base++mvebu_sc->system_soft_reset_offset);+}++while(1)+;+}++staticint__initmvebu_system_controller_init(void)+{+structdevice_node*np;++np=of_find_matching_node(NULL,of_system_controller_table);+if(np){+conststructof_device_id*match=+of_match_node(of_system_controller_table,np);+BUG_ON(!match);+system_controller_base=of_iomap(np,0);+mvebu_sc=(structmvebu_system_controller*)match->data;+}++return0;+}++arch_initcall(mvebu_system_controller_init);
--
1.7.9.5
Acked-by: Andrew Lunn <andrew@lunn.ch>
I also already sent a tested-by: which you failed to add. I don't
think the changed are particularly significant, so please keep it.
Andrew
@@ -0,0 +1,68 @@+/*+*DeviceTreeIncludefileforMarvellArmada370andArmadaXPSoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*BenDooks<ben.dooks@codethink.co.uk>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ThisfilecontainsthedefinitionsthatarecommontotheArmada+*370andArmadaXPSoC.+*/++/include/"skeleton.dtsi"++/{+model="Marvell Armada 370 and XP SoC";+compatible="marvell,armada_370_xp";++cpus{+cpuat0{+compatible="marvell,sheeva-v7";+};+};++mpic:interrupt-controlleratd0020000{+compatible="marvell,mpic";+#interrupt-cells=<1>;+#address-cells=<1>;+#size-cells=<1>;+interrupt-controller;+};++soc{+#address-cells=<1>;+#size-cells=<1>;+compatible="simple-bus";+interrupt-parent=<&mpic>;+ranges;++serialatd0012000{+compatible="ns16550";+reg=<0xd00120000x100>;+reg-shift=<2>;+interrupts=<41>;+status="disabled";+};+serialatd0012100{+compatible="ns16550";+reg=<0xd00121000x100>;+reg-shift=<2>;+interrupts=<42>;+status="disabled";+};++timeratd0020300{+compatible="marvell,timer";+reg=<0xd00203000x30>;+interrupts=<37>,<38>,<39>,<40>;+};+};+};+
@@ -0,0 +1,35 @@+/*+*DeviceTreeIncludefileforMarvellArmada370familySoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ContainsdefinitionsspecifictotheArmada370SoCthatarenot+*commontoallArmadaSoCs.+*/++/include/"armada-370-xp.dtsi"++/{+model="Marvell Armada 370 family SoC";+compatible="marvell,armada370","marvell,armada-370-xp";++mpic:interrupt-controlleratd0020000{+reg=<0xd0020a000x1d0>,+<0xd00218700x58>;+};++soc{+system-controlleratd0018200{+compatible="marvell,armada-370-xp-system-controller";+reg=<0xd00182000x100>;+};+};+};
@@ -0,0 +1,55 @@+/*+*DeviceTreeIncludefileforMarvellArmadaXPfamilySoC+*+*Copyright(C)2012Marvell+*+*LiorAmsalem<alior@marvell.com>+*GregoryCLEMENT<gregory.clement@free-electrons.com>+*ThomasPetazzoni<thomas.petazzoni@free-electrons.com>+*BenDooks<ben.dooks@codethink.co.uk>+*+*ThisfileislicensedunderthetermsoftheGNUGeneralPublic+*Licenseversion2.Thisprogramislicensed"as is"withoutany+*warrantyofanykind,whetherexpressorimplied.+*+*ContainsdefinitionsspecifictotheArmada370SoCthatarenot+*commontoallArmadaSoCs.+*/++/include/"armada-370-xp.dtsi"++/{+model="Marvell Armada XP family SoC";+compatible="marvell,armadaxp","marvell,armada-370-xp";++mpic:interrupt-controlleratd0020000{+reg=<0xd0020a000x1d0>,+<0xd00218700x58>;+};++soc{+serialatd0012200{+compatible="ns16550";+reg=<0xd00122000x100>;+reg-shift=<2>;+interrupts=<43>;+status="disabled";+};+serialatd0012300{+compatible="ns16550";+reg=<0xd00123000x100>;+reg-shift=<2>;+interrupts=<44>;+status="disabled";+};++timeratd0020300{+marvell,timer-25Mhz;+};++system-controlleratd0018200{+compatible="marvell,armada-370-xp-system-controller";+reg=<0xd00182000x500>;+};+};+};
@@ -2,6 +2,15 @@ if ARCH_MVEBUmenu"Marvell SOC with device tree"+configMACH_ARMADA_370_XP+bool"Marvell Armada 370 and Aramada XP boards"+selectARMADA_370_XP_TIMER+selectCPU_V7+help++Say'Y'hereifyouwantyourkerneltosupportboardsbasedon+MarvellArmada370orArmadaXPwithdevicetree.+endmenuendif
@@ -533,6 +533,18 @@ config ARCH_IXP4XXhelpSupportforIntel'sIXP4XX(XScale)familyofprocessors.+configARCH_MVEBU+bool"Marvell SOCs with Device Tree support"+selectGENERIC_CLOCKEVENTS+selectMULTI_IRQ_HANDLER+selectSPARSE_IRQ+selectCLKSRC_MMIO+selectGENERIC_IRQ_CHIP+selectIRQ_DOMAIN+selectCOMMON_CLK+help+SupportfortheMarvellSoCFamilywithdevicetreesupport+configARCH_DOVEbool"Marvell Dove"selectCPU_V7
@@ -987,6 +999,8 @@ endchoice# Kconfigs may be included either alphabetically (according to the# plat- suffix) or along side the corresponding mach-* source.#+source"arch/arm/mach-mvebu/Kconfig"+source"arch/arm/mach-at91/Kconfig"source"arch/arm/mach-bcmring/Kconfig"
From: Ben Dooks <hidden> Date: 2012-07-03 17:20:40
On 02/07/12 16:39, Thomas Petazzoni wrote:
Arnd, Olof,
You'll find in this patch set the seventh version of the initial
support for a new family of ARMv7-compatible Marvell SoCs.
As for the previous releases, both the Armada 370 and the Armada XP
SoCs are supported in this directory, and we are able to build a
single kernel image that boots on both SoCs. Both SoCs use the PJ4B
processor, a Marvell-developed ARM core that implements the ARMv7
instruction set. We are currently using Marvell evaluation boards for
both of those SoCs, and the support for those boards is added in this
patch set.
We remained focused on a limited preliminary support which only
includes the necessary code for timer and IRQ support, the serial
controller is a standard 16550-compatible one. The diffstat looks
like:
I've built and it got to looking for a root-fs.
Tested-by: Ben Dooks <redacted>
I will have another run through the series tomorrow and do a last
pass review.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Monday, July 02, 2012 6:39 PM
To: Arnd Bergmann; Olof Johansson
Cc: Ben Dooks; Jason Cooper; Andrew Lunn; Nicolas Pitre; Lior Amsalem;
Maen Suleiman; linux-arm-kernel at lists.infradead.org; Thomas Petazzoni;
Gregory Clement; Jon Masters; David Marlin; Tawfik Bayouk; Shadi
Ammouri; Eran Ben-Avi; Yehuda Yitschak; Nadav Haklai; Eric Miao
Subject: [PATCH v7] arm: Add basic support for new Marvell Armada 370 and
Armada XP SoC
Arnd, Olof,
You'll find in this patch set the seventh version of the initial support for a
new family of ARMv7-compatible Marvell SoCs.
As for the previous releases, both the Armada 370 and the Armada XP SoCs
are supported in this directory, and we are able to build a single kernel
image that boots on both SoCs. Both SoCs use the PJ4B processor, a Marvell-
developed ARM core that implements the ARMv7 instruction set. We are
currently using Marvell evaluation boards for both of those SoCs, and the
support for those boards is added in this patch set.
Hi, tested by me on Armada XP board. So,
Tested-By: Yehuda Yitschak <redacted>
[snip]
-----Original Message-----
From: Yehuda Yitschak
Sent: Wednesday, July 04, 2012 3:11 PM
To: Thomas Petazzoni; Arnd Bergmann; Olof Johansson
Cc: Ben Dooks; Jason Cooper; Andrew Lunn; Nicolas Pitre; Lior Amsalem;
Maen Suleiman; linux-arm-kernel at lists.infradead.org; Gregory Clement; Jon
Masters; David Marlin; Tawfik Bayouk; Shadi Ammouri; Eran Ben-Avi; Nadav
Haklai; Eric Miao
Subject: RE: [PATCH v7] arm: Add basic support for new Marvell Armada 370
and Armada XP SoC
quoted
-----Original Message-----
From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
Sent: Monday, July 02, 2012 6:39 PM
To: Arnd Bergmann; Olof Johansson
Cc: Ben Dooks; Jason Cooper; Andrew Lunn; Nicolas Pitre; Lior Amsalem;
Maen Suleiman; linux-arm-kernel at lists.infradead.org; Thomas Petazzoni;
Gregory Clement; Jon Masters; David Marlin; Tawfik Bayouk; Shadi
Ammouri; Eran Ben-Avi; Yehuda Yitschak; Nadav Haklai; Eric Miao
Subject: [PATCH v7] arm: Add basic support for new Marvell Armada 370
and
quoted
Armada XP SoC
Arnd, Olof,
You'll find in this patch set the seventh version of the initial support for a
new family of ARMv7-compatible Marvell SoCs.
As for the previous releases, both the Armada 370 and the Armada XP SoCs
are supported in this directory, and we are able to build a single kernel
image that boots on both SoCs. Both SoCs use the PJ4B processor, a
Marvell-
quoted
developed ARM core that implements the ARMv7 instruction set. We are
currently using Marvell evaluation boards for both of those SoCs, and the
support for those boards is added in this patch set.
Hi, tested by me on Armada XP board. So,
Tested-By: Yehuda Yitschak <redacted>
Hi Thomas, Thanks!
Tested by me on both Armada XP and 370 DB boards.
Tested-By: Lior Amsalem <redacted>