Re: [PATCH] sched: Support current clocksource handling in fallback sched_clock().

[Daniel Walker <dwalker@fifo99.com>]

On Fri, 2009-05-29 at 03:27 +0900, Paul Mundt wrote:

> Ah, ok, I suppose I could have explained that better. There are a couple
> of different considerations really. The timer blocks are often in
> different clock and power domains, meaning that only certain ones can be
> used for wakeups. These tend not to be ideal for general use, and so we
> only switch to them when we have to.
> 
> To make matters more convoluted, the availability of different timer
> channels on different CPUs will depend on current pin state, and more
> importantly, what sort of states we are able to achieve. It is not
> uncommon to have some of the pins required by these channels locked down
> by other drivers during regular operation, which we in turn need to
> unload before the pin state can be reconfigured and the timer can
> succeed, all which needs to happen before certain power state transitions
> can take place. We implement dynamic pinmux for most of the SH CPUs
> precisely to deal with these sorts of problems. In the case of some of
> the microcontrollers that are timer heavy and low on pincount, it is not
> uncommon to have upwards of 16 different functions per pin.

I'm still a little confused how kernel modules fit in here.. Are you
saying a user would unload some certain driver which has a pin locked
down and prevents the clocksource from working. Then the user would load
the clocksource module which would now function, and that all would have
to happen in order to enter a certain power state?

Daniel