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

[Andreas Kemnade <andreas@kemnade.info>]

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