[REGRESSION] OpenPandora (OMAP3) fails to boot since v7.2-rc1, bisected to b8eeeca5545659

[REGRESSION] OpenPandora (OMAP3) fails to boot since v7.2-rc1, bisected to b8eeeca5545659

[H. Nikolaus Schaller]

Hi,
I am seeing a boot regression on OpenPandora (OMAP3) since v7.2-rc1.

A git bisect identified:

b8eeeca5545659 ("clocksource/drivers/timer-ti-dm: Add clocksource support")

as the first bad commit.

Reverting this commit restores normal boot operation.

The regression is fully reproducible:
* v7.1: boots normally
* v7.2-rc1 and later: hangs during early boot after about 3 seconds
  after reporting
[    3.631072] sched_clock: 32 bits at 33kHz, resolution 30517ns, wraps every 65535999984741ns
[    3.643341] clocksource: omap_dm_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    3.660430] clocksource: Switched to clocksource omap_dm_timer
* v7.2-rc1 + revert of b8eeeca5545659: boots normally again

What caught my attention is that OMAP already has an existing DMTimer
clocksource implementation in timer-ti-dm-systimer.c, introduced by:

52762fbd1c4778 ("Add support for using the TI Dual-Mode Timer as a clocksource")

while b8eeeca5545659 adds another clocksource implementation to
timer-ti-dm.c.

The commit message and patch series state that the driver automatically
selects the first timer marked with the "ti,timer-alwon" DT property and
registers it as a clocksource/sched_clock.

I have not determined the failure mechanism, but the bisect result and
successful revert strongly suggest that the new DMTimer clocksource path
conflicts with the existing OMAP3 timer setup.

Therefore, I would like to ask:
* Is the new timer-ti-dm clocksource intended to coexist with the
  existing timer-ti-dm-systimer clocksource implementation on OMAP3?
* Is b8eeeca5545659 expected to be active on OMAP3 systems?
* Has this combination been tested on OMAP3 hardware?
* What is the solution?

If helpful, I can provide more details or test reports.

Thanks,
Nikolaus Schaller

Re: [REGRESSION] OpenPandora (OMAP3) fails to boot since v7.2-rc1, bisected to b8eeeca5545659

[Andreas Kemnade]

On Fri, 28 Aug 2026 14:49:54 +0200
"H. Nikolaus Schaller" <hns@goldelico.com> wrote:

> Hi,
> I am seeing a boot regression on OpenPandora (OMAP3) since v7.2-rc1.
> 
> A git bisect identified:
> 
> b8eeeca5545659 ("clocksource/drivers/timer-ti-dm: Add clocksource support")
> 
> as the first bad commit.
> 
> Reverting this commit restores normal boot operation.
> 
> The regression is fully reproducible:
> * v7.1: boots normally
> * v7.2-rc1 and later: hangs during early boot after about 3 seconds
>   after reporting
> [    3.631072] sched_clock: 32 bits at 33kHz, resolution 30517ns, wraps every 65535999984741ns
> [    3.643341] clocksource: omap_dm_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
> [    3.660430] clocksource: Switched to clocksource omap_dm_timer
> * v7.2-rc1 + revert of b8eeeca5545659: boots normally again
> 
Same on GTA04, also OMAP3. I have seen some OMAP4 fully booting with v7.2.

> What caught my attention is that OMAP already has an existing DMTimer
> clocksource implementation in timer-ti-dm-systimer.c, introduced by:
> 
> 52762fbd1c4778 ("Add support for using the TI Dual-Mode Timer as a clocksource")
> 
> while b8eeeca5545659 adds another clocksource implementation to
> timer-ti-dm.c.
> 
> The commit message and patch series state that the driver automatically
> selects the first timer marked with the "ti,timer-alwon" DT property and
> registers it as a clocksource/sched_clock.
> 
> I have not determined the failure mechanism, but the bisect result and
> successful revert strongly suggest that the new DMTimer clocksource path
> conflicts with the existing OMAP3 timer setup.
> 
> Therefore, I would like to ask:
> * Is the new timer-ti-dm clocksource intended to coexist with the
>   existing timer-ti-dm-systimer clocksource implementation on OMAP3?

Why a new second ti-dm-clocksource is introduced at all?

> * Is b8eeeca5545659 expected to be active on OMAP3 systems?
> * Has this combination been tested on OMAP3 hardware?
> * What is the solution?
> 
I would suggest, reverting that offending commit together with adding
missing pieces to timer-ti-dm-systimer.c

Regards,
Andreas

Re: [REGRESSION] OpenPandora (OMAP3) fails to boot since v7.2-rc1, bisected to b8eeeca5545659

[Markus Schneider-Pargmann]

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

Hi Nikolaus,

On Fri Aug 28, 2026 at 2:49 PM CEST, H. Nikolaus Schaller wrote:
> Hi,
> I am seeing a boot regression on OpenPandora (OMAP3) since v7.2-rc1.
>
> A git bisect identified:
>
> b8eeeca5545659 ("clocksource/drivers/timer-ti-dm: Add clocksource support")
>
> as the first bad commit.

Thanks for reporting, I am sorry for the regression.

>
> Reverting this commit restores normal boot operation.
>
> The regression is fully reproducible:
> * v7.1: boots normally
> * v7.2-rc1 and later: hangs during early boot after about 3 seconds
>   after reporting
> [    3.631072] sched_clock: 32 bits at 33kHz, resolution 30517ns, wraps every 65535999984741ns
> [    3.643341] clocksource: omap_dm_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
> [    3.660430] clocksource: Switched to clocksource omap_dm_timer
> * v7.2-rc1 + revert of b8eeeca5545659: boots normally again
>
> What caught my attention is that OMAP already has an existing DMTimer
> clocksource implementation in timer-ti-dm-systimer.c, introduced by:
>
> 52762fbd1c4778 ("Add support for using the TI Dual-Mode Timer as a clocksource")

Yes, this is the implementation for the old platforms omap, am33 etc. It
runs in early boot.

>
> while b8eeeca5545659 adds another clocksource implementation to
> timer-ti-dm.c.

Yes K3 am6* is much more complex and has more dependencies, that's why I
added it to the platform driver.

>
> The commit message and patch series state that the driver automatically
> selects the first timer marked with the "ti,timer-alwon" DT property and
> registers it as a clocksource/sched_clock.
>
> I have not determined the failure mechanism, but the bisect result and
> successful revert strongly suggest that the new DMTimer clocksource path
> conflicts with the existing OMAP3 timer setup.
>
> Therefore, I would like to ask:
> * Is the new timer-ti-dm clocksource intended to coexist with the
>   existing timer-ti-dm-systimer clocksource implementation on OMAP3?

The implementation is intended to coexist but they shouldn't both setup
the clocksource/clockevent for the same device.

> * Is b8eeeca5545659 expected to be active on OMAP3 systems?

No, it should not work on that.

> * Has this combination been tested on OMAP3 hardware?

No, my testhardware was am62. Sorry for missing this bug.

> * What is the solution?

I can create a patch probably early next week that gates the clocksource
clockevent registration to only run for am654-timer.

Best
Markus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]