Re: [RFC PATCH] clocksource: ti-32k: convert to platform device

[Tony Lindgren]

* Grygorii Strashko <grygorii.strashko@xxxxxx> [151201 07:09]:
> On 11/30/2015 06:28 PM, Tony Lindgren wrote:
> > 
> > We should be able to make this into an early_platform_device and just
> > have it depend on the source clock muxes. See the omap initcall changes
> > patches I just posted.
> > 
> 
> Sry, may be I've missed smth, but how early_platform_device will help us
> to get rid of platform code - We'd still need to power on manually 
> early_platform_device's from platform code :( through hwmod.

Having minimal platform code early is not a problem. The problem is that
our early code is not minimal.

For the system timers, we should only initialize the mux clocks needed
early to select between 32k and hf oscillator source. This needs to be done
using the clock framework, but we don't need the other clocks initialized
early.

The system timers we're using should be in the alwon power domain, if they
are not, then we should change the timers around so we're using only timers
in the alwon domain for system timers. Typically at least gpt1 and 12 are
always powered. That allows us to leave out the hwmod dependency for system
timers.

Or am I forgetting some other dependency with our system timers?

> The main reason why I've tried this is because clocksource will be really selected
> only at fs_initcall time - and at that time we have no restriction for using platform
> devices, Pm runtime APIs, etc. (exception/blocker is sched_clock :().

Right. But it seems we can leave out quite a bit of the dependencies
for system timers. We already have gptimer probe not touching the system
timers later on and can use shared gptimer functions after the clock
muxing is done.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/