[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