Re: [PATCH 0/5] Clocklib: generic clocks framework

[David Brownell <david-b@pacbell.net>]

On Saturday 26 April 2008, Dmitry wrote:
> > > Also once we get to multiple chips providers/users, we'll see,
> > > that the clock simply can't have just one record in the clocks tree.
> >
> >  I don't follow.  Why not?  If a clock has multiple records, I'd
> >  expect its refcounts would easily get borked.  I think I don't
> >  like your notion of a "wrapper clock".
> 
> It seems, I failed to describe it correctly.
> Let's suppose this situation:
> We have CLK, that is connected to the pin CK1 of the device dev_A and to the pin
> CK36M of the device dev_B.
> 
> The we'll have these clocks:
> .CLK count=0
> \- CK1 count=0 for dev_A
> \- CK36M count=0 for dev_B

But that's incorrect.  What we have is

  CLK users=0
    aliased as CK1 for dev_A
    aliased as CK36M for dev_b

The difference being that you are showing that CK1 and CK36M have
independent clock gates ... which are not actually present.

The difference between this and the at91_clk_associate() example
is that with clk_associate(), there is only one alias per clock.
There are cases where multiple aliases would be better ... TCB
modules, the "system" clock, and so on.


> When device dev_A enables it's clock,
> we'll have this:
> .CLK count=1
> \- CK1 count=1 for dev_A
> \- CK36M count=0 for dev_B

No, we have

  CLK users=1
    ... same aliases


> After that dev_B enables it's clock:
> .CLK count=2
> \- CK1 count=1 for dev_A
> \- CK36M count=1 for dev_B

Should be

  CLK users=2
    ... same aliases


> So refcounting is correct.

No.  When someone's looking at the clock tree to see what clocks
are active, and thus deduce which silicon is incurring switching
costs, these "wrapper clocks" are not telling the correct story.

- Dave