On Thu, Jul 15, 2010 at 11:32:19AM +0530, Viresh KUMAR wrote:

These cases particularly in our architecture where functional and
interface clock are tied together (through same gating option) would
produce difficult scenarios (as already mentioned by you) and which
would be difficult and not so clean to handle.

I don't see the problem.

What I'm proposing means:

1. when the driver probe function is called, pclk is guaranteed to be
   enabled, and therefore device registers are guaranteed to be accessible.
   This clock will then stay enabled all the time the device is bound to
   the driver unless the driver wants to request that it is disabled.

2. if the driver wants to do something with its functional clock, it
   clk_get() that, and does the standard enable/disable on it at the
   appropriate time.

So, if pclk and the functional clock are bound together, then at probe
time the 'pclk' is obtained and enabled, which sets your enable bit and
increases the clk use count to 1.

When the driver gets its functional clock, which happens to be the same
as clk structure as 'pclk', calling clk_enable() increases the use count
to 2, but doesn't touch the register because the clock is already enabled.

If the driver subsequently calls clk_disable(), this decreases the use
count to 1, and because there's still one user, the clock isn't disabled.

Only if the driver wants both its pclk and functional clock disabled will
your enable bit be reset.

So, provided a driver participating in pclk control (by disabling it in
its probe function) always re-enables pclk before it accesses the device
then the pclk control is completely transparent - whether or not it's
tied to the functional clock.

If a driver isn't participating in pclk control, it continues to work as
is with no alterations - because we guarantee that pclk will be enabled
to the device whenever the driver is bound to the device.

This allows us to incrementally add pclk control to each primecell driver.

For example just looking at driver src which disables bus clock (without
enabling it) in different scenarios would not be very readable.
Further that would vary from architecture to architecture (even for
standard drivers).

How so?

quoted

You can't have the core code doing that.  If you unconditionally turn
the bus clock off after probe, what happens when a driver receives an
interrupt and tries to access its registers?

Hint: the core code can't know that the driver has registered an IRQ
handler.

We haven't seen this kind of issues in our devices, SPEAr as well as
U300 (as we have both clocks controlled by same bit). Normally, when
device is not in use then interrupts are disabled. When device is
used then interrupts and clock are enabled and clocks are not disabled
till the time work is finished. So, this condition might not occur that
you have landed in interrupt handler with clocks off.

So what happens with the PL011 driver which accesses the device with
the primecell UARTCLK disabled?  Eg, when reading the procfs file in
/proc/tty/driver/ ?

What about the SPI primecell, which only enables its functional clock
when its really required?  It accesses device registers without the
functional clock enabled?

Basically, we do not guarantee that drivers will have their functional
clock enabled prior to accessing their registers.