On 06/12, Linus Walleij wrote:

On Thu, Jun 8, 2017 at 2:18 PM, Linus Walleij [off-list ref] wrote:

quoted

I think the timer may be more of an issue...

It is using CLOCKSOURCE_OF_DECLARE(), at least last time
I checked there was no such thing as clocksources retrying their
calls, and that cannot be regular probes because of, yeah device
core is using the timer, I think.

Yeah I looked in:
drivers/clocksource/clksrc-probe.c

It will just fail if it can't initialize the clocksource.

I don't understand what platforms can actually get their timers
up at all without the clock framework? Those hardcoding the
clock frequency in the device tree, or things like the ARM
TWD which has it encoded in hardware perhaps?

I just confirmed this to be the problem using a scratch patch for
a platform device init and some earlydebug prints:

Uncompressing Linux... done, booting the kernel.
 Booting Linux on physical CPU 0x0
start_kernel
(...)
 NR_IRQS:16 nr_irqs:16 16
 could not get PCLK
Failed to initialize '/soc/timer at 43000000': -517
 clocksource_probe: no matching clocksources found
 sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every
21474836475000000ns
 Console: colour dummy device 80x30
 Calibrating delay loop...

So the deferred clock makes the whole platform hang because the timer
needs it. Without a clocksource, the delay loop cannot be calibrated, so
it hangs there.

Ok. So can the certain clks that are required to get the timer
going be put into CLK_OF_DECLARE_DRIVER() and then have a regular
platform driver for the rest of the clks that aren't required for
early boot? We've been doing this sort of hybrid design lately,
so hopefully that works here too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project