[PATCH v2 0/8] Enable CONFIG_TIMER for all Kirkwood / MVEBU boards
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(-)
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)
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
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
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 }, {} };
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);
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
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
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
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
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
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).
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
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.
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
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
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 */
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 \
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>,
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;
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
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
participants (4)
-
Michael Walle -
Pali Rohár -
Stefan Roese -
Tony Dinh