On 12/01/2015 06:07 PM, Tony Lindgren wrote:
* 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?
both counter32 and GP timer have to be enabled through sysc registers.
They are in "Force idle" state after reset.
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,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
