[PATCH v2 0/8] Enable CONFIG_TIMER for all Kirkwood / MVEBU boards

[PATCH v2 0/8] Enable CONFIG_TIMER for all Kirkwood / MVEBU boards

[Stefan Roese]

This patchset enhaces the recently added Orion Timer driver to support
all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
timer support is then enabled per default for those platforms, so that
the board config files don't need to be changed. Also necessary is
some dts hacking, so that the timer DT node is available in early
U-Boot stages.

I've successfully tested this patchset on an Armada XP board. Additional
test on other boards and platforms are very welcome and necessary.

Thanks,
Stefan

Stefan Roese (8):
  timer: orion-timer: Use timer_conv_64() to fix timer wrap around
  timer: orion-timer: Add support for other Armada SoC's
  timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
  arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
  arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step
  arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1
  arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot,dm-pre-reloc" to timer
    DT node
  kirkwood: lsxl: Sync defconfigs

 arch/arm/Kconfig                          |  4 ++
 arch/arm/dts/Makefile                     |  6 ++-
 arch/arm/dts/armada-375.dtsi              |  4 +-
 arch/arm/dts/mvebu-u-boot.dtsi            | 11 +++++
 arch/arm/mach-mvebu/include/mach/config.h |  5 ---
 configs/lschlv2_defconfig                 |  3 --
 configs/lsxhl_defconfig                   |  3 --
 drivers/timer/Kconfig                     |  5 ++-
 drivers/timer/orion-timer.c               | 53 +++++++++++++++++++++--
 9 files changed, 75 insertions(+), 19 deletions(-)

-- 
2.37.3

[PATCH v2 1/8] timer: orion-timer: Use timer_conv_64() to fix timer wrap around

[Stefan Roese]

While testing on some Kirkwood platforms it was noticed that the timer
did not function correctly all the time. The driver did not correctly
handle 32bit timer value wrap arounds. Using the timer_conv_64()
conversion function fixes this issue.

Suggested-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier-oss@weidmueller.com>
Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- New patch

 drivers/timer/orion-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
index fd30e1bf036c..d7d1a1b24462 100644
--- a/drivers/timer/orion-timer.c
+++ b/drivers/timer/orion-timer.c
@@ -19,7 +19,7 @@ static uint64_t orion_timer_get_count(struct udevice *dev)
 {
 	struct orion_timer_priv *priv = dev_get_priv(dev);
 
-	return ~readl(priv->base + TIMER0_VAL);
+	return timer_conv_64(~readl(priv->base + TIMER0_VAL));
 }
 
 static int orion_timer_probe(struct udevice *dev)
-- 
2.37.3

Re: [PATCH v2 1/8] timer: orion-timer: Use timer_conv_64() to fix timer wrap around

[Michael Walle]

Am 2022-09-02 08:25, schrieb Stefan Roese:
> While testing on some Kirkwood platforms it was noticed that the timer
> did not function correctly all the time. The driver did not correctly
> handle 32bit timer value wrap arounds. Using the timer_conv_64()
> conversion function fixes this issue.

Fixes: e9e73d78a8fb ("timer: add orion-timer support")

Ahh. Sorry about that. I've missed that conversation which is also
in lib/time.c in a different call tree.

Maybe this can be picked to master (if this series is going into
next)?

-michael

Re: [PATCH v2 1/8] timer: orion-timer: Use timer_conv_64() to fix timer wrap around

[Stefan Roese]

On 02.09.22 09:44, Michael Walle wrote:
> Am 2022-09-02 08:25, schrieb Stefan Roese:
>> While testing on some Kirkwood platforms it was noticed that the timer
>> did not function correctly all the time. The driver did not correctly
>> handle 32bit timer value wrap arounds. Using the timer_conv_64()
>> conversion function fixes this issue.
> 
> Fixes: e9e73d78a8fb ("timer: add orion-timer support")
> 
> Ahh. Sorry about that. I've missed that conversation which is also
> in lib/time.c in a different call tree.
> 
> Maybe this can be picked to master (if this series is going into
> next)?

That's my plan. To pull this patch only in this release cycle and
queue the rest for next.

Thanks,
Stefan

[PATCH v2 2/8] timer: orion-timer: Add support for other Armada SoC's

[Stefan Roese]

This patch adds support for other Marvell Armada SoC's, supporting the
25MHz fixed clock operation, like the Armada XP etc.

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- Use timer_conv_64() in timer_early_get_count()

 drivers/timer/Kconfig       |  5 ++++-
 drivers/timer/orion-timer.c | 42 ++++++++++++++++++++++++++++++++++---
 2 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 404929014810..b0814acca3fb 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -197,8 +197,11 @@ config OMAP_TIMER
 config ORION_TIMER
 	bool "Orion timer support"
 	depends on TIMER
+	default y if ARCH_KIRKWOOD || (ARCH_MVEBU && ARMADA_32BIT)
+	select TIMER_EARLY if ARCH_MVEBU
 	help
-	  Select this to enable an timer for Orion devices.
+	  Select this to enable an timer for Orion and Armada devices
+	  like Armada XP etc.
 
 config RISCV_TIMER
 	bool "RISC-V timer support"
diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
index d7d1a1b24462..14f318e57d4d 100644
--- a/drivers/timer/orion-timer.c
+++ b/drivers/timer/orion-timer.c
@@ -11,10 +11,34 @@
 #define TIMER0_RELOAD		0x10
 #define TIMER0_VAL		0x14
 
+enum input_clock_type {
+	INPUT_CLOCK_NON_FIXED,
+	INPUT_CLOCK_25MHZ,	/* input clock rate is fixed to 25MHz */
+};
+
 struct orion_timer_priv {
 	void *base;
 };
 
+#define MVEBU_TIMER_FIXED_RATE_25MHZ	25000000
+
+/**
+ * timer_early_get_rate() - Get the timer rate before driver model
+ */
+unsigned long notrace timer_early_get_rate(void)
+{
+	return MVEBU_TIMER_FIXED_RATE_25MHZ;
+}
+
+/**
+ * timer_early_get_count() - Get the timer count before driver model
+ *
+ */
+u64 notrace timer_early_get_count(void)
+{
+	return timer_conv_64(~readl(MVEBU_TIMER_BASE + TIMER0_VAL));
+}
+
 static uint64_t orion_timer_get_count(struct udevice *dev)
 {
 	struct orion_timer_priv *priv = dev_get_priv(dev);
@@ -25,6 +49,7 @@ static uint64_t orion_timer_get_count(struct udevice *dev)
 static int orion_timer_probe(struct udevice *dev)
 {
 	struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+	enum input_clock_type type = dev_get_driver_data(dev);
 	struct orion_timer_priv *priv = dev_get_priv(dev);
 
 	priv->base = devfdt_remap_addr_index(dev, 0);
@@ -33,11 +58,20 @@ static int orion_timer_probe(struct udevice *dev)
 		return -ENOMEM;
 	}
 
-	uc_priv->clock_rate = CONFIG_SYS_TCLK;
-
 	writel(~0, priv->base + TIMER0_VAL);
 	writel(~0, priv->base + TIMER0_RELOAD);
 
+	if (type == INPUT_CLOCK_25MHZ) {
+		/*
+		 * On Armada XP / 38x ..., the 25MHz clock source needs to
+		 * be enabled
+		 */
+		setbits_le32(priv->base + TIMER_CTRL, BIT(11));
+		uc_priv->clock_rate = MVEBU_TIMER_FIXED_RATE_25MHZ;
+	} else {
+		uc_priv->clock_rate = CONFIG_SYS_TCLK;
+	}
+
 	/* enable timer */
 	setbits_le32(priv->base + TIMER_CTRL, TIMER0_EN | TIMER0_RELOAD_EN);
 
@@ -49,7 +83,9 @@ static const struct timer_ops orion_timer_ops = {
 };
 
 static const struct udevice_id orion_timer_ids[] = {
-	{ .compatible = "marvell,orion-timer" },
+	{ .compatible = "marvell,orion-timer", .data = INPUT_CLOCK_NON_FIXED },
+	{ .compatible = "marvell,armada-370-timer", .data = INPUT_CLOCK_25MHZ },
+	{ .compatible = "marvell,armada-xp-timer", .data = INPUT_CLOCK_25MHZ },
 	{}
 };
 
-- 
2.37.3

[PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Stefan Roese]

Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
enabled, like pogo_v4.

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- Change timer_get_boot_us() to use the timer_early functions
- Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)

Simon, I'm currently looking into this timer_get_boot_us() to using
timer_early_get_count() etc consolidation.

 drivers/timer/orion-timer.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
index 14f318e57d4d..6c0b8550412d 100644
--- a/drivers/timer/orion-timer.c
+++ b/drivers/timer/orion-timer.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 #include <asm/io.h>
 #include <common.h>
+#include <div64.h>
 #include <dm/device.h>
 #include <dm/fdtaddr.h>
 #include <timer.h>
@@ -39,6 +40,14 @@ u64 notrace timer_early_get_count(void)
 	return timer_conv_64(~readl(MVEBU_TIMER_BASE + TIMER0_VAL));
 }
 
+ulong timer_get_boot_us(void)
+{
+	u64 ticks;
+
+	ticks = timer_early_get_count();
+	return lldiv(ticks * 1000, timer_early_get_rate());
+}
+
 static uint64_t orion_timer_get_count(struct udevice *dev)
 {
 	struct orion_timer_priv *priv = dev_get_priv(dev);
-- 
2.37.3

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Stefan,

On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
>
> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> enabled, like pogo_v4.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> v2:
> - Change timer_get_boot_us() to use the timer_early functions
> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
>
> Simon, I'm currently looking into this timer_get_boot_us() to using
> timer_early_get_count() etc consolidation.

Indeed, as you've mentioned above, I think timer_early_get_count() and
timer_early_get_rate() do need to take into consideration  what the
input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
the Pogo V4.

I'm seeing on the Pogo V4 test, the timer command reports time about 6
times slower than it should. It does seem to jive with the fact that
the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.

All the best,
Tony


>
>  drivers/timer/orion-timer.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
> index 14f318e57d4d..6c0b8550412d 100644
> --- a/drivers/timer/orion-timer.c
> +++ b/drivers/timer/orion-timer.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  #include <asm/io.h>
>  #include <common.h>
> +#include <div64.h>
>  #include <dm/device.h>
>  #include <dm/fdtaddr.h>
>  #include <timer.h>
> @@ -39,6 +40,14 @@ u64 notrace timer_early_get_count(void)
>         return timer_conv_64(~readl(MVEBU_TIMER_BASE + TIMER0_VAL));
>  }
>
> +ulong timer_get_boot_us(void)
> +{
> +       u64 ticks;
> +
> +       ticks = timer_early_get_count();
> +       return lldiv(ticks * 1000, timer_early_get_rate());
> +}
> +
>  static uint64_t orion_timer_get_count(struct udevice *dev)
>  {
>         struct orion_timer_priv *priv = dev_get_priv(dev);
> --
> 2.37.3
>

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Stefan Roese]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Hi Tony,

On 03.09.22 11:44, Tony Dinh wrote:
> Hi Stefan,
> 
> On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
>>
>> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
>> enabled, like pogo_v4.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> ---
>> v2:
>> - Change timer_get_boot_us() to use the timer_early functions
>> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
>>
>> Simon, I'm currently looking into this timer_get_boot_us() to using
>> timer_early_get_count() etc consolidation.
> 
> Indeed, as you've mentioned above, I think timer_early_get_count() and
> timer_early_get_rate() do need to take into consideration  what the
> input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> the Pogo V4.
> 
> I'm seeing on the Pogo V4 test, the timer command reports time about 6
> times slower than it should. It does seem to jive with the fact that
> the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.

Ah, I've missing updating the early functions to also differentiate
between fixed clocks and TCLK timer.

Please give the attached patch a try - should be applied on top of this
latest patchset.

Thanks,
Stefan

[-- Attachment #2: orion-timer-fix-early-init.patch --]
[-- Type: text/x-patch, Size: 3230 bytes --]

diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
index 6c0b8550412d..cd63ea916237 100644
--- a/drivers/timer/orion-timer.c
+++ b/drivers/timer/orion-timer.c
@@ -23,12 +23,56 @@ struct orion_timer_priv {
 
 #define MVEBU_TIMER_FIXED_RATE_25MHZ	25000000
 
+static bool early_init_done __section(".data") = false;
+
+/* Common functions for early (boot) and DM based timer */
+static void orion_timer_init(void *base, enum input_clock_type type)
+{
+	writel(~0, base + TIMER0_VAL);
+	writel(~0, base + TIMER0_RELOAD);
+
+	if (type == INPUT_CLOCK_25MHZ) {
+		/*
+		 * On Armada XP / 38x ..., the 25MHz clock source needs to
+		 * be enabled
+		 */
+		setbits_le32(base + TIMER_CTRL, BIT(11));
+	}
+
+	/* enable timer */
+	setbits_le32(base + TIMER_CTRL, TIMER0_EN | TIMER0_RELOAD_EN);
+}
+
+static uint64_t orion_timer_get_count(void *base)
+{
+	return timer_conv_64(~readl(base + TIMER0_VAL));
+}
+
+/* Early (e.g. bootstage etc) timer functions */
+static void notrace timer_early_init(void)
+{
+	/* Only init the timer once */
+	if (early_init_done)
+		return;
+	early_init_done = true;
+
+	if (IS_ENABLED(CONFIG_ARCH_MVEBU))
+		orion_timer_init((void *)MVEBU_TIMER_BASE, INPUT_CLOCK_25MHZ);
+	else
+		orion_timer_init((void *)MVEBU_TIMER_BASE, INPUT_CLOCK_NON_FIXED);
+}
+
 /**
  * timer_early_get_rate() - Get the timer rate before driver model
  */
 unsigned long notrace timer_early_get_rate(void)
 {
-	return MVEBU_TIMER_FIXED_RATE_25MHZ;
+	timer_early_init();
+
+	if (IS_ENABLED(CONFIG_ARCH_MVEBU))
+		return MVEBU_TIMER_FIXED_RATE_25MHZ;
+	else
+		return CONFIG_SYS_TCLK;
 }
 
 /**
@@ -37,7 +81,9 @@ unsigned long notrace timer_early_get_rate(void)
  */
 u64 notrace timer_early_get_count(void)
 {
-	return timer_conv_64(~readl(MVEBU_TIMER_BASE + TIMER0_VAL));
+	timer_early_init();
+
+	return orion_timer_get_count((void *)MVEBU_TIMER_BASE);
 }
 
 ulong timer_get_boot_us(void)
@@ -48,11 +94,12 @@ ulong timer_get_boot_us(void)
 	return lldiv(ticks * 1000, timer_early_get_rate());
 }
 
-static uint64_t orion_timer_get_count(struct udevice *dev)
+/* DM timer functions */
+static uint64_t dm_orion_timer_get_count(struct udevice *dev)
 {
 	struct orion_timer_priv *priv = dev_get_priv(dev);
 
-	return timer_conv_64(~readl(priv->base + TIMER0_VAL));
+	return orion_timer_get_count(priv->base);
 }
 
 static int orion_timer_probe(struct udevice *dev)
@@ -67,28 +114,17 @@ static int orion_timer_probe(struct udevice *dev)
 		return -ENOMEM;
 	}
 
-	writel(~0, priv->base + TIMER0_VAL);
-	writel(~0, priv->base + TIMER0_RELOAD);
-
-	if (type == INPUT_CLOCK_25MHZ) {
-		/*
-		 * On Armada XP / 38x ..., the 25MHz clock source needs to
-		 * be enabled
-		 */
-		setbits_le32(priv->base + TIMER_CTRL, BIT(11));
+	if (type == INPUT_CLOCK_25MHZ)
 		uc_priv->clock_rate = MVEBU_TIMER_FIXED_RATE_25MHZ;
-	} else {
+	else
 		uc_priv->clock_rate = CONFIG_SYS_TCLK;
-	}
-
-	/* enable timer */
-	setbits_le32(priv->base + TIMER_CTRL, TIMER0_EN | TIMER0_RELOAD_EN);
+	orion_timer_init(priv->base, type);
 
 	return 0;
 }
 
 static const struct timer_ops orion_timer_ops = {
-	.get_count = orion_timer_get_count,
+	.get_count = dm_orion_timer_get_count,
 };
 
 static const struct udevice_id orion_timer_ids[] = {

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Stefan,

On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr@denx.de> wrote:
>
> Hi Tony,
>
> On 03.09.22 11:44, Tony Dinh wrote:
> > Hi Stefan,
> >
> > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
> >>
> >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> >> enabled, like pogo_v4.
> >>
> >> Signed-off-by: Stefan Roese <sr@denx.de>
> >> ---
> >> v2:
> >> - Change timer_get_boot_us() to use the timer_early functions
> >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
> >>
> >> Simon, I'm currently looking into this timer_get_boot_us() to using
> >> timer_early_get_count() etc consolidation.
> >
> > Indeed, as you've mentioned above, I think timer_early_get_count() and
> > timer_early_get_rate() do need to take into consideration  what the
> > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> > the Pogo V4.
> >
> > I'm seeing on the Pogo V4 test, the timer command reports time about 6
> > times slower than it should. It does seem to jive with the fact that
> > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
>
> Ah, I've missing updating the early functions to also differentiate
> between fixed clocks and TCLK timer.
>
> Please give the attached patch a try - should be applied on top of this
> latest patchset.

That looks promising, but I think we are still missing something.
After applying the attached patch, I ran the test again and it behaved
the same way (clock rate 6 times slower). So I did another test.



> Thanks,
> Stefan

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Stefan,

Sorry, that message was prematurely sent (fat finger). Please see the
continuation below.

On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Stefan,
>
> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr@denx.de> wrote:
> >
> > Hi Tony,
> >
> > On 03.09.22 11:44, Tony Dinh wrote:
> > > Hi Stefan,
> > >
> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
> > >>
> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> > >> enabled, like pogo_v4.
> > >>
> > >> Signed-off-by: Stefan Roese <sr@denx.de>
> > >> ---
> > >> v2:
> > >> - Change timer_get_boot_us() to use the timer_early functions
> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
> > >>
> > >> Simon, I'm currently looking into this timer_get_boot_us() to using
> > >> timer_early_get_count() etc consolidation.
> > >
> > > Indeed, as you've mentioned above, I think timer_early_get_count() and
> > > timer_early_get_rate() do need to take into consideration  what the
> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> > > the Pogo V4.
> > >
> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6
> > > times slower than it should. It does seem to jive with the fact that
> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
> >
> > Ah, I've missing updating the early functions to also differentiate
> > between fixed clocks and TCLK timer.
> >
> > Please give the attached patch a try - should be applied on top of this
> > latest patchset.
>

That looks promising, but I think we are still missing something.
After applying the attached patch, I ran the test again and it behaved
the same way (clock rate 6 times slower). So I did another test.

--- Test 1
Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get
60.000
90.000

So apparently the sleep cmd has reset the correct clock rate.

--- Test 2

Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get
30.000
60.000

And then wait for 30 seconds, do another "timer get" (I expected to
see about 90 to 95 seconds).

Pogo_V4> timer get
66.237

The different call tree with the timer vs the sleep command made a
difference. But I could not see where.

--- Test 3

Then I recalled about CONFIG_TIMER_EARLY. It is not selected by
default in Kconfig currently. So I enabled that to see the behavior.
But running this build hangs right off the bat. No u-boot version
banner is printed out.

Thanks,
Tony

>
>
>
> > Thanks,
> > Stefan

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Pali,

On Sat, Sep 3, 2022 at 5:02 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Stefan,
>
> Sorry, that message was prematurely sent (fat finger). Please see the
> continuation below.
>
> On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >
> > Hi Stefan,
> >
> > On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr@denx.de> wrote:
> > >
> > > Hi Tony,
> > >
> > > On 03.09.22 11:44, Tony Dinh wrote:
> > > > Hi Stefan,
> > > >
> > > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
> > > >>
> > > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> > > >> enabled, like pogo_v4.
> > > >>
> > > >> Signed-off-by: Stefan Roese <sr@denx.de>
> > > >> ---
> > > >> v2:
> > > >> - Change timer_get_boot_us() to use the timer_early functions
> > > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
> > > >>
> > > >> Simon, I'm currently looking into this timer_get_boot_us() to using
> > > >> timer_early_get_count() etc consolidation.
> > > >
> > > > Indeed, as you've mentioned above, I think timer_early_get_count() and
> > > > timer_early_get_rate() do need to take into consideration  what the
> > > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> > > > the Pogo V4.
> > > >
> > > > I'm seeing on the Pogo V4 test, the timer command reports time about 6
> > > > times slower than it should. It does seem to jive with the fact that
> > > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
> > >
> > > Ah, I've missing updating the early functions to also differentiate
> > > between fixed clocks and TCLK timer.
> > >
> > > Please give the attached patch a try - should be applied on top of this
> > > latest patchset.
> >
>
> That looks promising, but I think we are still missing something.
> After applying the attached patch, I ran the test again and it behaved
> the same way (clock rate 6 times slower). So I did another test.
>
> --- Test 1
> Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get
> 60.000
> 90.000
>
> So apparently the sleep cmd has reset the correct clock rate.
>
> --- Test 2
>
> Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get
> 30.000
> 60.000
>
> And then wait for 30 seconds, do another "timer get" (I expected to
> see about 90 to 95 seconds).
>
> Pogo_V4> timer get
> 66.237
>
> The different call tree with the timer vs the sleep command made a
> difference. But I could not see where.
>
> --- Test 3
>
> Then I recalled about CONFIG_TIMER_EARLY. It is not selected by
> default in Kconfig currently. So I enabled that to see the behavior.
> But running this build hangs right off the bat. No u-boot version
> banner is printed out.
>

Is there a way to get the CPU frequency from the board upon start up?

Thanks,
Tony

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Pali Rohár]

On Saturday 03 September 2022 17:38:01 Tony Dinh wrote:
> Hi Pali,
> 
> Is there a way to get the CPU frequency from the board upon start up?
> 
> Thanks,
> Tony

Hello! Each SoC has either fixed CPU frequency or has some bits in SAR
register which say on which frequency is CPU running. SAR bits are SoC
specific and are documented either in Functional Specifications or in
Hardware Specifications (both documents are available for free all
32-bit Marvell SoCs except 375 and 39x).

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Pali,

On Sat, Sep 3, 2022 at 6:08 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 03 September 2022 17:38:01 Tony Dinh wrote:
> > Hi Pali,
> >
> > Is there a way to get the CPU frequency from the board upon start up?
> >
> > Thanks,
> > Tony
>
> Hello! Each SoC has either fixed CPU frequency or has some bits in SAR
> register which say on which frequency is CPU running. SAR bits are SoC
> specific and are documented either in Functional Specifications or in
> Hardware Specifications (both documents are available for free all
> 32-bit Marvell SoCs except 375 and 39x).

Thanks for the recap. I do remember you posted a patch for that detection.
https://lists.denx.de/pipermail/u-boot/2022-August/492034.html

Just want to make sure that the SAR register is the only way we can
detect it in u-boot. The Kirkwood 6192 SoC on this Pogo V4 board can
run at 200 Mhz and 800 Mhz with frequency scaling in Linux.

Thanks,
Tony

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Pali Rohár]

On Saturday 03 September 2022 19:36:03 Tony Dinh wrote:
> Hi Pali,
> 
> On Sat, Sep 3, 2022 at 6:08 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Saturday 03 September 2022 17:38:01 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > Is there a way to get the CPU frequency from the board upon start up?
> > >
> > > Thanks,
> > > Tony
> >
> > Hello! Each SoC has either fixed CPU frequency or has some bits in SAR
> > register which say on which frequency is CPU running. SAR bits are SoC
> > specific and are documented either in Functional Specifications or in
> > Hardware Specifications (both documents are available for free all
> > 32-bit Marvell SoCs except 375 and 39x).
> 
> Thanks for the recap. I do remember you posted a patch for that detection.
> https://lists.denx.de/pipermail/u-boot/2022-August/492034.html
> 
> Just want to make sure that the SAR register is the only way we can
> detect it in u-boot. The Kirkwood 6192 SoC on this Pogo V4 board can
> run at 200 Mhz and 800 Mhz with frequency scaling in Linux.
> 
> Thanks,
> Tony

Well, All those SoCs have more clocks which are used for different
peripherals. TCLK is something like base block and CPU is connected to
different clock. Settings for it CPU clock is also in SAR register
(different bits). And then there can be something like CPU scaling and
cpufreq driver with configuration via different registers which can
modify divisor of the main CPU clock. Which effectively can lower CPU
speed. This cpufreq part is not implemented in U-Boot and IIRC CPU clock
divisor should be at 1 = full CPU speed.

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Michael Walle]

Am 2022-09-04 02:02, schrieb Tony Dinh:
> Hi Stefan,
> 
> Sorry, that message was prematurely sent (fat finger). Please see the
> continuation below.
> 
> On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh <mibodhi@gmail.com> wrote:
>> 
>> Hi Stefan,
>> 
>> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr@denx.de> wrote:
>> >
>> > Hi Tony,
>> >
>> > On 03.09.22 11:44, Tony Dinh wrote:
>> > > Hi Stefan,
>> > >
>> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
>> > >>
>> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
>> > >> enabled, like pogo_v4.
>> > >>
>> > >> Signed-off-by: Stefan Roese <sr@denx.de>
>> > >> ---
>> > >> v2:
>> > >> - Change timer_get_boot_us() to use the timer_early functions
>> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
>> > >>
>> > >> Simon, I'm currently looking into this timer_get_boot_us() to using
>> > >> timer_early_get_count() etc consolidation.
>> > >
>> > > Indeed, as you've mentioned above, I think timer_early_get_count() and
>> > > timer_early_get_rate() do need to take into consideration  what the
>> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
>> > > the Pogo V4.
>> > >
>> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6
>> > > times slower than it should. It does seem to jive with the fact that
>> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
>> >
>> > Ah, I've missing updating the early functions to also differentiate
>> > between fixed clocks and TCLK timer.
>> >
>> > Please give the attached patch a try - should be applied on top of this
>> > latest patchset.
>> 
> 
> That looks promising, but I think we are still missing something.
> After applying the attached patch, I ran the test again and it behaved
> the same way (clock rate 6 times slower). So I did another test.
> 
> --- Test 1
> Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get
> 60.000
> 90.000
> 
> So apparently the sleep cmd has reset the correct clock rate.
> 
> --- Test 2
> 
> Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get
> 30.000
> 60.000
> 
> And then wait for 30 seconds, do another "timer get" (I expected to
> see about 90 to 95 seconds).
> 
> Pogo_V4> timer get
> 66.237

I've did the same test and can confirm it. But I think that is
a drawback from the timer command. With a 32bit timer and a
TCLK of 166MHz (on my board), the timer will wrap around about
every 26s. So if you don't do a get_timer() call for that whole
period, the overflow won't be counted in timer_conv_64().

For the sleep command it works correctly, because it will
poll get_timer() every 100us.

In summary, you cannot expect a "timer get" on the console
to work if you cannot make sure, the you call it at least
every "2^32 / TCLK" seconds.

-michael

Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support

[Tony Dinh]

Hi Michael,

On Sun, Sep 4, 2022 at 1:54 AM Michael Walle <michael@walle.cc> wrote:
>
> Am 2022-09-04 02:02, schrieb Tony Dinh:
> > Hi Stefan,
> >
> > Sorry, that message was prematurely sent (fat finger). Please see the
> > continuation below.
> >
> > On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >>
> >> Hi Stefan,
> >>
> >> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <sr@denx.de> wrote:
> >> >
> >> > Hi Tony,
> >> >
> >> > On 03.09.22 11:44, Tony Dinh wrote:
> >> > > Hi Stefan,
> >> > >
> >> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
> >> > >>
> >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> >> > >> enabled, like pogo_v4.
> >> > >>
> >> > >> Signed-off-by: Stefan Roese <sr@denx.de>
> >> > >> ---
> >> > >> v2:
> >> > >> - Change timer_get_boot_us() to use the timer_early functions
> >> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
> >> > >>
> >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using
> >> > >> timer_early_get_count() etc consolidation.
> >> > >
> >> > > Indeed, as you've mentioned above, I think timer_early_get_count() and
> >> > > timer_early_get_rate() do need to take into consideration  what the
> >> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
> >> > > the Pogo V4.
> >> > >
> >> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6
> >> > > times slower than it should. It does seem to jive with the fact that
> >> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
> >> >
> >> > Ah, I've missing updating the early functions to also differentiate
> >> > between fixed clocks and TCLK timer.
> >> >
> >> > Please give the attached patch a try - should be applied on top of this
> >> > latest patchset.
> >>
> >
> > That looks promising, but I think we are still missing something.
> > After applying the attached patch, I ran the test again and it behaved
> > the same way (clock rate 6 times slower). So I did another test.
> >
> > --- Test 1
> > Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get
> > 60.000
> > 90.000
> >
> > So apparently the sleep cmd has reset the correct clock rate.
> >
> > --- Test 2
> >
> > Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get
> > 30.000
> > 60.000
> >
> > And then wait for 30 seconds, do another "timer get" (I expected to
> > see about 90 to 95 seconds).
> >
> > Pogo_V4> timer get
> > 66.237
>
> I've did the same test and can confirm it. But I think that is
> a drawback from the timer command. With a 32bit timer and a
> TCLK of 166MHz (on my board), the timer will wrap around about
> every 26s. So if you don't do a get_timer() call for that whole
> period, the overflow won't be counted in timer_conv_64().
>
> For the sleep command it works correctly, because it will
> poll get_timer() every 100us.
>
> In summary, you cannot expect a "timer get" on the console
> to work if you cannot make sure, the you call it at least
> every "2^32 / TCLK" seconds.
>
> -michael

Thanks for confirming that and the explanation. It makes perfect
sense! I think I got side tracked and never noticed that it is a
32-bit timer wrap- around :)

All the best,
Tony

[PATCH v2 4/8] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms

[Stefan Roese]

Now that the new timer support is available for these platforms, let's
select this IF for all these platforms. This way it's not necessary
that each board changes it's config header.

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- No change

 arch/arm/Kconfig                          | 4 ++++
 arch/arm/mach-mvebu/include/mach/config.h | 5 -----
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0b72e4f6503e..60f524a2d118 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -618,6 +618,7 @@ config ARCH_KIRKWOOD
 	select BOARD_EARLY_INIT_F
 	select CPU_ARM926EJS
 	select GPIO_EXTRA_HEADER
+	select TIMER
 
 config ARCH_MVEBU
 	bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)"
@@ -629,6 +630,8 @@ config ARCH_MVEBU
 	select GPIO_EXTRA_HEADER
 	select SPL_DM_SPI if SPL
 	select SPL_DM_SPI_FLASH if SPL
+	select SPL_TIMER if SPL
+	select TIMER
 	select OF_CONTROL
 	select OF_SEPARATE
 	select SPI
@@ -639,6 +642,7 @@ config ARCH_ORION5X
 	select CPU_ARM926EJS
 	select GPIO_EXTRA_HEADER
 	select SPL_SEPARATE_BSS if SPL
+	select TIMER
 
 config TARGET_STV0991
 	bool "Support stv0991"
diff --git a/arch/arm/mach-mvebu/include/mach/config.h b/arch/arm/mach-mvebu/include/mach/config.h
index 4add0d9e1030..9b5036c31dd3 100644
--- a/arch/arm/mach-mvebu/include/mach/config.h
+++ b/arch/arm/mach-mvebu/include/mach/config.h
@@ -41,9 +41,4 @@
 #endif
 #endif
 
-/* Use common timer */
-#define CONFIG_SYS_TIMER_COUNTS_DOWN
-#define CONFIG_SYS_TIMER_COUNTER	(MVEBU_TIMER_BASE + 0x14)
-#define CONFIG_SYS_TIMER_RATE		25000000
-
 #endif /* __MVEBU_CONFIG_H */
-- 
2.37.3

[PATCH v2 5/8] arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step

[Stefan Roese]

This patch changes the compilation, so that the Armada 375 board(s) are
compiled in a separate step. This is necessary for the timer dts
conversion, as A375 has a different / timer description in the dts.

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- No change

 arch/arm/dts/Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7330121dbaba..03e79e14681f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -233,8 +233,11 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 	tegra210-p3450-0000.dtb
 
 ifdef CONFIG_ARMADA_32BIT
+ifdef CONFIG_ARMADA_375
+dtb-$(CONFIG_ARCH_MVEBU) +=			\
+	armada-375-db.dtb
+else
 dtb-$(CONFIG_ARCH_MVEBU) +=			\
-	armada-375-db.dtb			\
 	armada-385-atl-x530.dtb			\
 	armada-385-atl-x530DP.dtb		\
 	armada-385-db-88f6820-amc.dtb		\
@@ -254,6 +257,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=			\
 	armada-xp-maxbcm.dtb			\
 	armada-xp-synology-ds414.dtb		\
 	armada-xp-theadorable.dtb
+endif
 else
 dtb-$(CONFIG_ARCH_MVEBU) +=			\
 	armada-3720-db.dtb			\
-- 
2.37.3

[PATCH v2 6/8] arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1

[Stefan Roese]

Add the DT bindings / descriptions for timer0 & timer1, exactly as done
in mainline Linux.

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- No change

 arch/arm/dts/armada-375.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/armada-375.dtsi b/arch/arm/dts/armada-375.dtsi
index 20a8c352b2f1..a044b3fc994f 100644
--- a/arch/arm/dts/armada-375.dtsi
+++ b/arch/arm/dts/armada-375.dtsi
@@ -187,7 +187,7 @@
 				reg = <0xc000 0x58>;
 			};
 
-			timer@c600 {
+			timer0: timer@c600 {
 				compatible = "arm,cortex-a9-twd-timer";
 				reg = <0xc600 0x20>;
 				interrupts = <GIC_PPI 13 (IRQ_TYPE_EDGE_RISING | GIC_CPU_MASK_SIMPLE(2))>;
@@ -416,7 +416,7 @@
 				interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>;
 			};
 
-			timer@20300 {
+			timer1: timer@20300 {
 				compatible = "marvell,armada-375-timer", "marvell,armada-370-timer";
 				reg = <0x20300 0x30>, <0x21040 0x30>;
 				interrupts-extended = <&gic  GIC_SPI  8 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.37.3

[PATCH v2 7/8] arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot, dm-pre-reloc" to timer DT node

[Stefan Roese]

Adding the "u-boot,dm-pre-reloc" DT property to the timer node is
necesssary to support the timer in the early boot phases (e.g.
SPL & pre-reloc).

Signed-off-by: Stefan Roese <sr@denx.de>
---
v2:
- No change

 arch/arm/dts/mvebu-u-boot.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/mvebu-u-boot.dtsi b/arch/arm/dts/mvebu-u-boot.dtsi
index 5538f95148de..db4bf39920b1 100644
--- a/arch/arm/dts/mvebu-u-boot.dtsi
+++ b/arch/arm/dts/mvebu-u-boot.dtsi
@@ -15,6 +15,17 @@
 	u-boot,dm-pre-reloc;
 };
 
+#ifdef CONFIG_ARMADA_375
+/* Armada 375 has multiple timers, use timer1 here */
+&timer1 {
+	u-boot,dm-pre-reloc;
+};
+#else
+&timer {
+	u-boot,dm-pre-reloc;
+};
+#endif
+
 #ifdef CONFIG_SPL_SPI
 &spi0 {
 	u-boot,dm-pre-reloc;
-- 
2.37.3

[PATCH v2 8/8] kirkwood: lsxl: Sync defconfigs

[Stefan Roese]

With the recent changes in the Orion timer driver Kconfig setup, the
board specific enabling is not needed any more. This patch sync's these
2 boards with their current defconfig version.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Michael Walle <michael@walle.cc>
---
v2:
- New patch

 configs/lschlv2_defconfig | 3 ---
 configs/lsxhl_defconfig   | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/configs/lschlv2_defconfig b/configs/lschlv2_defconfig
index e9cc632696de..441cd8ef24ff 100644
--- a/configs/lschlv2_defconfig
+++ b/configs/lschlv2_defconfig
@@ -60,7 +60,6 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=25000000
 CONFIG_SPI_FLASH_STMICRO=y
-CONFIG_DM_ETH=y
 CONFIG_DM_MDIO=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
@@ -71,7 +70,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_KIRKWOOD_SPI=y
-CONFIG_TIMER=y
-CONFIG_ORION_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/lsxhl_defconfig b/configs/lsxhl_defconfig
index b83a072b04dd..f350f8ff427a 100644
--- a/configs/lsxhl_defconfig
+++ b/configs/lsxhl_defconfig
@@ -61,7 +61,6 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SF_DEFAULT_SPEED=25000000
 CONFIG_SPI_FLASH_STMICRO=y
-CONFIG_DM_ETH=y
 CONFIG_DM_MDIO=y
 CONFIG_MVGBE=y
 CONFIG_MII=y
@@ -72,7 +71,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_KIRKWOOD_SPI=y
-CONFIG_TIMER=y
-CONFIG_ORION_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.37.3

Re: [PATCH v2 0/8] Enable CONFIG_TIMER for all Kirkwood / MVEBU boards

[Tony Dinh]

Hi Stefan,

On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese <sr@denx.de> wrote:
>
> This patchset enhaces the recently added Orion Timer driver to support
> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
> timer support is then enabled per default for those platforms, so that
> the board config files don't need to be changed. Also necessary is
> some dts hacking, so that the timer DT node is available in early
> U-Boot stages.
>
> I've successfully tested this patchset on an Armada XP board. Additional
> test on other boards and platforms are very welcome and necessary.

I've also discovered that the timer command (CONFIG_CMD_TIMER) was
broken at some time in the past. It does not keep time correctly
(lagging realtime badly), with or without this patch set . I think we
would want to investigate that issue later.

The sleep command works perfectly. Therefore,

Tested-by: Tony Dinh <mibodhi@gmail.com>

Thanks,
Tony

> Thanks,
> Stefan
>
> Stefan Roese (8):
>   timer: orion-timer: Use timer_conv_64() to fix timer wrap around
>   timer: orion-timer: Add support for other Armada SoC's
>   timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
>   arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
>   arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step
>   arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1
>   arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot,dm-pre-reloc" to timer
>     DT node
>   kirkwood: lsxl: Sync defconfigs
>
>  arch/arm/Kconfig                          |  4 ++
>  arch/arm/dts/Makefile                     |  6 ++-
>  arch/arm/dts/armada-375.dtsi              |  4 +-
>  arch/arm/dts/mvebu-u-boot.dtsi            | 11 +++++
>  arch/arm/mach-mvebu/include/mach/config.h |  5 ---
>  configs/lschlv2_defconfig                 |  3 --
>  configs/lsxhl_defconfig                   |  3 --
>  drivers/timer/Kconfig                     |  5 ++-
>  drivers/timer/orion-timer.c               | 53 +++++++++++++++++++++--
>  9 files changed, 75 insertions(+), 19 deletions(-)
>
> --
> 2.37.3
>