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

[Markus Schneider-Pargmann]

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: signature.asc
Description: PGP signature