Arnd, Olof,
You'll find in this patch set the third version of the initial support
for a new family of ARMv7-compatible Marvell SoCs.
As for the previous release, 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 +
MAINTAINERS | 8 +
arch/arm/Kconfig | 15 +
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 | 15 +
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 | 78 +++
drivers/clocksource/Kconfig | 3 +
drivers/clocksource/Makefile | 3 +-
drivers/clocksource/time-armada-370-xp.c | 242 +++++++++
include/linux/time-armada-370-xp.h | 18 +
27 files changed, 1060 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.). And for this new version we
got contributions from Ben Dooks from Codethink.
The patch set is based on your arm-soc/for-next branch (updated on Monday
11th June).
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,
Gregory Clement
@@ -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";++mpic:interrupt-controlleratd0020000{+reg=<0xd0020a000x1d0>,+<0xd00218700x58>;+};++soc{+system-controlleratd0018200{+compatible="marvell,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,system-controller";+reg=<0xd00182000x500>;+};+};+};
@@ -2,6 +2,14 @@ if ARCH_MVEBUmenu"Marvell SOC with device tree"+configMACH_ARMADA_370_XP+bool"Marvell Armada 370 and Aramada XP boards"+selectARMADA_370_XP_TIMER+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,19 @@ config ARCH_IXP4XXhelpSupportforIntel'sIXP4XX(XScale)familyofprocessors.+configARCH_MVEBU+bool"Marvell SOCs with Device Tree support"+selectCPU_V7+selectGENERIC_CLOCKEVENTS+selectMULTI_IRQ_HANDLER+selectSPARSE_IRQ+selectCLKSRC_MMIO+selectGENERIC_IRQ_CHIP+selectIRQ_DOMAIN+selectCOMMON_CLK+help+SupportfortheMarvellSoCFamilywithdevicetreesupport+configARCH_DOVEbool"Marvell Dove"selectCPU_V7
@@ -986,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: 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(-)
@@ -533,6 +533,19 @@ config ARCH_IXP4XXhelpSupportforIntel'sIXP4XX(XScale)familyofprocessors.+configARCH_MVEBU+bool"Marvell SOCs with Device Tree support"+selectCPU_V7+selectGENERIC_CLOCKEVENTS+selectMULTI_IRQ_HANDLER+selectSPARSE_IRQ+selectCLKSRC_MMIO+selectGENERIC_IRQ_CHIP+selectIRQ_DOMAIN+selectCOMMON_CLK+help+SupportfortheMarvellSoCFamilywithdevicetreesupport+
Hi Gregory
How is this going to work when we move DT supported kirkwood, Orion5x,
Dove, etc into here?
Maybe this should be called ARCH_MVEBU_CPU_V7 for these two SoCs plus
Dove and we have a second config ARCH_MVEBU_CPU_V5 for Kirkwood,
Orion5x, MV78xx0?
Andrew
@@ -533,6 +533,19 @@ config ARCH_IXP4XXhelpSupportforIntel'sIXP4XX(XScale)familyofprocessors.+configARCH_MVEBU+bool"Marvell SOCs with Device Tree support"+selectCPU_V7+selectGENERIC_CLOCKEVENTS+selectMULTI_IRQ_HANDLER+selectSPARSE_IRQ+selectCLKSRC_MMIO+selectGENERIC_IRQ_CHIP+selectIRQ_DOMAIN+selectCOMMON_CLK+help+SupportfortheMarvellSoCFamilywithdevicetreesupport+
Hi Gregory
How is this going to work when we move DT supported kirkwood, Orion5x,
Dove, etc into here?
Maybe this should be called ARCH_MVEBU_CPU_V7 for these two SoCs plus
Dove and we have a second config ARCH_MVEBU_CPU_V5 for Kirkwood,
Orion5x, MV78xx0?
I agree. Even at the arm level, the final goal will be to have
different kernels for ARM v4/5 and ARM v6/7.
Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
How is this going to work when we move DT supported kirkwood, Orion5x,
Dove, etc into here?
Maybe this should be called ARCH_MVEBU_CPU_V7 for these two SoCs plus
Dove and we have a second config ARCH_MVEBU_CPU_V5 for Kirkwood,
Orion5x, MV78xx0?
I think having one top-level option is fine, we can make sure you
only select compatible ones inside the merged Kconfig, e.g.
config ARCH_ORION5X
bool "Marvell Orion"
depends on !CPU_V7
select CPU_V5
config ARCH_KIRKWOOD
bool "Marvell Kirkwood"
depends on !CPU_V7
select CPU_V5
config ARCH_DOVE
bool "Marvell Dove"
select CPU_V7
config ARCH_ARMADA370
bool Marvell Armada 370"
select CPU_V7
config ARCH_ARMADAXP
bool Marvell ArmadaXP"
select CPU_V7
Arnd
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>
Looks fine to me, but you forgot to Cc the clocksource maintainers.
This will need an Ack from John and/or Thomas.
Arnd
Much better than before, but there are now two problems:
* You look for a generic "marvell,system-controller" node, which does not tell
you at all which kind it is. I'm sure that inside of Marvell there has been more
than one peripheral that can be described as a system controller, so please
be more specific here.
* You should not issue a warning if the device is not found. The initialization
comes from a platform independent arch_initcall, so in a future combined
kernel, it will be executed on all machines including non-Marvell ones.
Arnd
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>
Looks fine to me, but you forgot to Cc the clocksource maintainers.
This will need an Ack from John and/or Thomas.
You're right! I planned to add them, but I used the wrong command line
when I pushed the patches :(
Arnd
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
$ grep -hr "#define RSTOUTn "*
#define RSTOUTn_MASK (BRIDGE_VIRT_BASE | 0x0108)
#define RSTOUTn_MASK (ORION5X_BRIDGE_VIRT_BASE | 0x108)
#define RSTOUTn_MASK (BRIDGE_VIRT_BASE | 0x0108)
#define RSTOUTn_MASK (BRIDGE_VIRT_BASE | 0x0108)
$ grep -rh "#define SYSTEM_SOFT_RESET" *
#define SYSTEM_SOFT_RESET (BRIDGE_VIRT_BASE | 0x010c)
#define SYSTEM_SOFT_RESET (BRIDGE_VIRT_BASE | 0x010c)
#define SYSTEM_SOFT_RESET (BRIDGE_VIRT_BASE | 0x010c)
/* Orion5x also puts it at 0x10c, but has a different name! */
So, it looks like the Marvell ASIC engineers moved it for the latest
SoCs. Could you add a child property of marvell,system-controller
which indicates where within the system controller the reset
subcontroller is? Since the two registers are always next to each
other, we just need one address.
Thanks
Andrew
+void __init armada_370_xp_timer_init(void)
+{
+ u32 u;
+ struct device_node *np;
+ unsigned int timer_clk;
+ int ret;
+ np = of_find_compatible_node(NULL, NULL, "marvell,timer");
+ timer_base = of_iomap(np, 0);
+ WARN_ON(!timer_base);
+
+ if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
+ /* The fixed 25MHz timer is available so let's use it */
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u | TIMER0_25MHZ | TIMER1_25MHZ,
+ timer_base + TIMER_CTRL_OFF);
+ timer_clk = 25000000;
+ } else {
+ u32 clk = 0;
+ ret = of_property_read_u32(np, "clock-frequency", &clk);
+ WARN_ON(!clk || ret < 0);
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
+ timer_base + TIMER_CTRL_OFF);
+ timer_clk = clk / TIMER_DIVIDER;
+ }
Hi Gregory
This all looks very similar to plat-orion/timer.c. The biggest
difference is the support for this 25Mhz timer mode. Maybe, so long as
this property is not used, the code will work for all orion platforms.
If so, we should drop all the armada_370_xp prefixes and just call it
orion.
I will try to test it on a Kirkwood today/tomorrow.
Andrew
+void __init armada_370_xp_timer_init(void)
+{
+ u32 u;
+ struct device_node *np;
+ unsigned int timer_clk;
+ int ret;
+ np = of_find_compatible_node(NULL, NULL, "marvell,timer");
+ timer_base = of_iomap(np, 0);
+ WARN_ON(!timer_base);
+
+ if (of_find_property(np, "marvell,timer-25Mhz", NULL)) {
+ /* The fixed 25MHz timer is available so let's use it */
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u | TIMER0_25MHZ | TIMER1_25MHZ,
+ timer_base + TIMER_CTRL_OFF);
+ timer_clk = 25000000;
+ } else {
+ u32 clk = 0;
+ ret = of_property_read_u32(np, "clock-frequency", &clk);
+ WARN_ON(!clk || ret < 0);
+ u = readl(timer_base + TIMER_CTRL_OFF);
+ writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
+ timer_base + TIMER_CTRL_OFF);
+ timer_clk = clk / TIMER_DIVIDER;
+ }
Hi Gregory
This all looks very similar to plat-orion/timer.c. The biggest
difference is the support for this 25Mhz timer mode. Maybe, so long as
this property is not used, the code will work for all orion platforms.
If so, we should drop all the armada_370_xp prefixes and just call it
orion.
I will try to test it on a Kirkwood today/tomorrow.
I wait for your results, and if it works for you then I drop all the
armada_370_xp prefixes. About calling it orion, it should be mvebu I
think.
Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+33 602 196 044
About calling it orion, it should be mvebu I think.
I guess that's another discussion. All current device drivers, except
Ethernet and I2C are called orion. Orion currently means anything
shared by orion5x, kirkwood, dove, mv78xx0. It seems unlikely we are
going to rename all the device drivers. So calling it mvebu will just
add to the confusion, not reduce the confusion. I personally would
say, anything inside mach-mvebu which is shared by multiple SoCs, can
be prefixed mvebu_. However, anything outside mach-mvebu should remain
orion_.
But that is just my opinion....
Andrew
About calling it orion, it should be mvebu I think.
I guess that's another discussion. All current device drivers, except
Ethernet and I2C are called orion. Orion currently means anything
shared by orion5x, kirkwood, dove, mv78xx0. It seems unlikely we are
going to rename all the device drivers. So calling it mvebu will just
add to the confusion, not reduce the confusion. I personally would
say, anything inside mach-mvebu which is shared by multiple SoCs, can
be prefixed mvebu_. However, anything outside mach-mvebu should remain
orion_.
Well, a halfway cleanup is potentially even more confusing than a
complete one. So it would be best to also rename "orion" to "mvebu" for
stuff outside of mach-mvebu.
Your point holds for things which are shared beyond the mvebu SOCs
though, such as mv643 or sata_mv.
Nicolas
From: Thomas Petazzoni <hidden> Date: 2012-06-15 18:13:59
Le Fri, 15 Jun 2012 12:07:34 +0200,
Andrew Lunn [off-list ref] a ?crit :
So, it looks like the Marvell ASIC engineers moved it for the latest
SoCs. Could you add a child property of marvell,system-controller
which indicates where within the system controller the reset
subcontroller is? Since the two registers are always next to each
other, we just need one address.
I must say I'm a bit confused in my understanding of what category of
information should be encoded in the Device Tree.
Do we want to encode all the register offsets, bit locations and so on
in the Device Tree? I.e, is the Device Tree suppose to allow porting to
a new SoC without any code modification? Or only to a new board with no
code modification?
For example http://article.gmane.org/gmane.linux.linaro.devel/10554
seems to suggest that the Device Tree will only be used to encode
board-level informations, but not SoC level informations. In that
specific e-mail, the case of the internal SoC clocks are mentioned, and
the OMAP maintainers seem to agree that all the internal SoC clocks
should be listed in C code rather than inside the Device Tree.
On the other hand, the current suggestion of encoding register offsets
inside the Device Tree seems to indicate that we want to encode
SoC-level details inside the Device Tree, which to me (but I might have
gotten everything wrong) contradicts the statement of the OMAP
maintainers mentioned previously.
I'm kind of puzzled by where's the limit between what should be encoded
in the Device Tree and what should remain C code, and I have the
feeling (hopefully incorrect one) that the different sub-architectures
maintainers do not have the same vision on this.
Could anyone show me the direction of the light? :-)
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Le Fri, 15 Jun 2012 12:07:34 +0200,
Andrew Lunn [off-list ref] a ?crit :
quoted
So, it looks like the Marvell ASIC engineers moved it for the latest
SoCs. Could you add a child property of marvell,system-controller
which indicates where within the system controller the reset
subcontroller is? Since the two registers are always next to each
other, we just need one address.
I must say I'm a bit confused in my understanding of what category of
information should be encoded in the Device Tree.
Do we want to encode all the register offsets, bit locations and so on
in the Device Tree? I.e, is the Device Tree suppose to allow porting to
a new SoC without any code modification? Or only to a new board with no
code modification?
This is usually left up to the platform maintainer.
For example http://article.gmane.org/gmane.linux.linaro.devel/10554
seems to suggest that the Device Tree will only be used to encode
board-level informations, but not SoC level informations. In that
specific e-mail, the case of the internal SoC clocks are mentioned, and
the OMAP maintainers seem to agree that all the internal SoC clocks
should be listed in C code rather than inside the Device Tree.
On the other hand, the current suggestion of encoding register offsets
inside the Device Tree seems to indicate that we want to encode
SoC-level details inside the Device Tree, which to me (but I might have
gotten everything wrong) contradicts the statement of the OMAP
maintainers mentioned previously.
I'm kind of puzzled by where's the limit between what should be encoded
in the Device Tree and what should remain C code, and I have the
feeling (hopefully incorrect one) that the different sub-architectures
maintainers do not have the same vision on this.
Could anyone show me the direction of the light? :-)
We definitely want to encode all or almost all of the differences between
boards in the device tree.
For anything that is part of the soc itself, it depends a lot on
how many different parts there are and how similar they are. The goal
should be to minimize the total amount of code that is necessary
In case of Tegra, we only have very few SoCs (tegra20, tegra30 so
far, a few more in the future), so it's usually easier to have large
parts of the differences hardcoded and just detected by the
"compatible" property. In case of at91, we have dozes of different
SoCs that are all quite similar, so it makes more sense to have a
rather generic abstraction in the source and put a lot of the
data into the device tree.
mvebu is somewhere in the middle between those, so either way makes
sense. In most cases, I would not want to go as far as describing
individual bits in the device tree, but I think it's reasonable to
fully abstract for instance the mvebu interrupt controller because
the only difference is the number and location of the 32-bit
blocks.
For the reset logic I believe we have three variants, so I would
suggest using different "compatible" values to tell these apart.
Arnd