Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Linus Walleij]

2009/7/31 Len Brown <lenb@kernel.org>:

> A Linux Power Management "mini-summit" was held on July 13th, 2009 -
> on the first day of the Montreal Linux Symposium.
> (...)

> SH running cpufreq on top of clock framework
> ? ? ? ?cpufreq has notifiers, clock framework does not

Hm! Paul can you elaborate on what that was about.

I've felt a need for clock notifiers and we've cheated by using
CPUfreq because it so happens that the clocking in system-wide
and whenever the CPU freq change so may the other clocks.

But if I put code into a PrimeCell MMC/SPI/I2C driver or whatever and
use CPUfreq that's very unelegant, and for other platforms where
the CPU freq don't change when this particular device clk freq
change plain misleading.

A clk pre/postchange notifier pair would really help and would
make for elegant drivers that can handle clock freq transitions.

Has anyone poked at this?

Linus Walleij

Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Bill Gatliff]

Linus Walleij wrote:
> I've felt a need for clock notifiers and we've cheated by using
> CPUfreq because it so happens that the clocking in system-wide
> and whenever the CPU freq change so may the other clocks.
>
> But if I put code into a PrimeCell MMC/SPI/I2C driver or whatever and
> use CPUfreq that's very unelegant, and for other platforms where
> the CPU freq don't change when this particular device clk freq
> change plain misleading.
>
> A clk pre/postchange notifier pair would really help and would
> make for elegant drivers that can handle clock freq transitions.
>   

A lot of ARM chips have peripherals that are driven by PLLs that run 
quasi-independently of the CPU clock.

If I guess correctly at what is being described above, a notifier chain 
for the users of a clock would be a clean way for peripherals to deal 
with clock speed *and* CPU speed changes, indeed.  A clock source that 
was affected by cpufreq would place itself on the cpufreq notifier 
chain, and also provide a notifier chain for peripherals that are driven 
by that clock.  When a cpufreq notification arrived, if the clock 
couldn't adjust for the cpufreq change it would use its notifier chain 
to tell all downstream peripherals about it.

A lot of peripherals could then focus just on the clock notifier chain, 
and would no longer care about cpufreq.  I like it.


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Francesco VIRLINZI]

Hi Linus
FYI:
I'm going to present a generic linux clock framework during the CELF-Europe
  @
http://www.embeddedlinuxconference.com/elc_europe09/sessions.html#Virlinzi

It's integrated in the LDM via platform_driver and platform_device.

It would be a proposal but it doesn't use the CPUFreq.

It uses struct clk to identify each phisical the clock in the system
  and it adds clock information to the platform_device to link each
  device to the clock it uses.

Regards
  Francesco

On 09/02/2009 12:22 AM, Linus Walleij wrote:
> 2009/7/31 Len Brown<lenb@kernel.org>:
>
>    
>> A Linux Power Management "mini-summit" was held on July 13th, 2009 -
>> on the first day of the Montreal Linux Symposium.
>> (...)
>>      
>    
>> SH running cpufreq on top of clock framework
>>         cpufreq has notifiers, clock framework does not
>>      
> Hm! Paul can you elaborate on what that was about.
>
> I've felt a need for clock notifiers and we've cheated by using
> CPUfreq because it so happens that the clocking in system-wide
> and whenever the CPU freq change so may the other clocks.
>
> But if I put code into a PrimeCell MMC/SPI/I2C driver or whatever and
> use CPUfreq that's very unelegant, and for other platforms where
> the CPU freq don't change when this particular device clk freq
> change plain misleading.
>
> A clk pre/postchange notifier pair would really help and would
> make for elegant drivers that can handle clock freq transitions.
>
> Has anyone poked at this?
>
> Linus Walleij
> _______________________________________________
> linux-pm mailing list
> linux-pm at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
>    

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Linus Walleij]

2009/9/2 Francesco VIRLINZI <francesco.virlinzi@st.com>:

> I'm going to present a generic linux clock framework during the CELF-Europe
> ?@
> http://www.embeddedlinuxconference.com/elc_europe09/sessions.html#Virlinzi

Great stuff, are the patches already available or will you hold them
until after your seminar?

Yours,
Linus Walleij

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Russell King - ARM Linux]

On Wed, Sep 02, 2009 at 10:36:55AM +0200, Francesco VIRLINZI wrote:
> Hi Linus
> FYI:
> I'm going to present a generic linux clock framework during the CELF-Europe
>  @
> http://www.embeddedlinuxconference.com/elc_europe09/sessions.html#Virlinzi

How does this differ from the clk API with clkdev that we already have?

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Francesco VIRLINZI]

Hi Russel
Sorry I don't know the clkdev API.
In any case the CF, I will present, tracks the relationship between
  device and clock.
During any clock changing the CF checks if all the device agree the new rate
  before the clock is changed.

How does the clkdev work?

Regards
  Francesco

On 09/02/2009 11:58 PM, Russell King - ARM Linux wrote:
> On Wed, Sep 02, 2009 at 10:36:55AM +0200, Francesco VIRLINZI wrote:
>    
>> Hi Linus
>> FYI:
>> I'm going to present a generic linux clock framework during the CELF-Europe
>>   @
>> http://www.embeddedlinuxconference.com/elc_europe09/sessions.html#Virlinzi
>>      
> How does this differ from the clk API with clkdev that we already have?
>
>    

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Russell King - ARM Linux]

On Thu, Sep 03, 2009 at 04:50:47PM +0200, Francesco VIRLINZI wrote:
> Hi Russel
> Sorry I don't know the clkdev API.
> In any case the CF, I will present, tracks the relationship between
>  device and clock.
> During any clock changing the CF checks if all the device agree the new rate
>  before the clock is changed.
>
> How does the clkdev work?

Looking at your abstract:

   The main goals are to manage:
   1. each clock and the operations that the clock support
   2. the clocks tree and the hierarchical relationships
   3. the clock-device relationships
   4. the clock rate change propagation
   5. in an architecture independent way.

   While several clock frameworks are able to address the first two points,
   most of the clock frameworks aren't architecture independent and are not
   able to involve the device driver in the propagation flow.

Point 3 is covered by the clk API, provided the clk API is implemented
correctly, particularly the clk_get() implementation.  clkdev helps to
ensure that people find it easy to implement this function.

Basically, clk_get(dev, id) is used to obtain the clock for device 'dev'.
If the device only has one clock, id _may_ be NULL, but otherwise is the
_input_ clock name for the device.  Eg, on OMAP, the watchdog has a
functional clock and an interface clock.  We give these "fck" and "ick"
names for the ID field.

Other devices in OMAP also have functional and interface clocks, which
aren't the same as the watchdog functional and interface clocks.  We
also pass "fck" and "ick" as the ID to clk_get().

So, the ID field is _not_ a unique clock name in the system; the API was
never designed for that to be the case.  It was always the intention that
clk_get() would return the clock for a particular input on the specified
device.

However, most people found that they could uniquely name their clocks and
ignore the 'dev' passed to clk_get... and then end up passing around clock
names.  That's precisely the wrong usage, and is not how the API is meant
to be used.  Such users need fixing rather than the API redesigned.

Point 2 is implementation specific.  Eg, OMAP has a complex tree of
clocks with PLLs, muxes and switches represented in its clock tree.
Such complexity is not necessary in the vast majority of implementations -
for instance, on Marvel PXA, there is no heirarchial arrangement of
clocks.  The same is true for development platforms such as Realview,
Versatile and Integrator.

Point 1 is also implementation specific.  We have platforms where there
is only one clock, and this is a fixed frequency clock.  Such platforms
should not be burdened by a complex heirarchial clock implementation.

Point 4 is something that OMAP might be able to use, though OMAP already
does this within its clk API implementation without notification of
drivers - the clock rates are driven by drivers requesting rates for
their own clocks rather than one driver influencing the clock rate for
another.

That said, PXA could do with some notification of core state changes,
which influences which clocks are available and the rate which they
run at.  It's something that is going to have some progress over the
next year or so, and it could result in the clk API being extended
with an optional API to support this.

Overall, I really don't buy the "it must be architecture independent"
argument - when I designed the clk API, I _intentionally_ left it up to
the platform to decide how the clk API was to be implemented because I
wanted the API to scale from the simplest single clock right up to
complex stuff like OMAP has.  The API does scale between these two
extremes fairly well at the expense of allowing non-SoC devices to use
it... and that's the biggest down side to allowing that range of scaling.

My biggest mistake, however, when designing the API was not to provide
a standard (but optional) implementation for clk_get() and clk_put(),
which I have now done with clkdev.  (arch/arm/common/clkdev.c)

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Linus Walleij]

2009/9/3 Russell King - ARM Linux <linux@arm.linux.org.uk>:

> [Francesco's blurb]
> ? The main goals are to manage:
> ? 1. each clock and the operations that the clock support
> ? 2. the clocks tree and the hierarchical relationships
> ? 3. the clock-device relationships
> ? 4. the clock rate change propagation
> ? 5. in an architecture independent way.

> Point 4 is something that OMAP might be able to use, though OMAP already
> does this within its clk API implementation without notification of
> drivers - the clock rates are driven by drivers requesting rates for
> their own clocks rather than one driver influencing the clock rate for
> another.
>
> That said, PXA could do with some notification of core state changes,
> which influences which clocks are available and the rate which they
> run at. ?It's something that is going to have some progress over the
> next year or so, and it could result in the clk API being extended
> with an optional API to support this.

We need something like (4) for U300 as well, we have the same
issue with core state propagating changes to several clocks, which
is mainly why I asked about this thing from the SuperH people.

> My biggest mistake, however, when designing the API was not to provide
> a standard (but optional) implementation for clk_get() and clk_put(),
> which I have now done with clkdev. ?(arch/arm/common/clkdev.c)

If other SoCs like SuperH (obviously) and maybe PowerPC, etc need this
as well, could it be relocated to something like drivers/clk and include/linux?
That sounds like fulfilling (5) for (3).

Linus Walleij

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Woodruff, Richard]

> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Linus Walleij
> Sent: Thursday, September 03, 2009 3:15 PM
> To: Russell King - ARM Linux

> 2009/9/3 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> > [Francesco's blurb]
> >   The main goals are to manage:
> >   1. each clock and the operations that the clock support
> >   2. the clocks tree and the hierarchical relationships
> >   3. the clock-device relationships
> >   4. the clock rate change propagation
> >   5. in an architecture independent way.
>
> > Point 4 is something that OMAP might be able to use, though OMAP already
> > does this within its clk API implementation without notification of
> > drivers - the clock rates are driven by drivers requesting rates for
> > their own clocks rather than one driver influencing the clock rate for
> > another.
> >
> > That said, PXA could do with some notification of core state changes,
> > which influences which clocks are available and the rate which they
> > run at.  It's something that is going to have some progress over the
> > next year or so, and it could result in the clk API being extended
> > with an optional API to support this.
>
> We need something like (4) for U300 as well, we have the same
> issue with core state propagating changes to several clocks, which
> is mainly why I asked about this thing from the SuperH people.
>
> > My biggest mistake, however, when designing the API was not to provide
> > a standard (but optional) implementation for clk_get() and clk_put(),
> > which I have now done with clkdev.  (arch/arm/common/clkdev.c)

If you are not careful notifications can turn into a graph with cycles.  p_start: Driver A changes shared root speed. Then driver B gets notification of change.  Driver B then tries to adjust clock to get back into range for its device; Driver a gets notification of speed change: goto p_start.

Older OMAP clock code mainly called a simple recalc method as part of an internal propagate rate which happens as part of clk_set_rate. Only exporting 'safe' rates as returned by the clk_round_rate call can make a set_rate(valid_rate) calls work with out issue.

Both the good and the bad of the clock frame work is it hides clock node details from the driver. This allows the driver to talk in rates and not worry about upper structure. The inflexible is, sometimes you would like to add and remove nodes. If I plug in some hw-module which is deriving its clock from a processor clock, it would be nice to write that driver to add the node for its local clock and then just use the standard apis. To do this however requires you to understand the node structure at the driver (clk_install_node, clk_remove_node).

Paul Walmsley offered some patches with notifiers for OMAP recently which you might look at.  TI had also added a pre/post notifier which was used with clock changes in a different layer just above clock in a resource freamwork.  As it turns out for OMAP3, the notifiers are not needed very often as there are many independent DPLLs.  Back in OMAP2 however they were more important as most everything was derived from a single DPLL.

Some of the clock abuse which happened by allowing the specifying of physical I+F clocks for a devices instead of a single virtual clock can be useful.  In some cases it is important for the driver to sequence its internal clocks as part of init or shutdown.  Handling them as a single entity isn't always doable.  Sometimes you could factor that code out but not always.

Regards,
Richard W.

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Francesco VIRLINZI]

Hi Russel.
Thanks for your feedback.

I know several point are already covered by other cf implementation.
And I didn't create a new API... I use the same API linux already has.
> Point 4 is something that OMAP might be able to use, though OMAP already
> does this within its clk API implementation without notification of
> drivers - the clock rates are driven by drivers requesting rates for
> their own clocks rather than one driver influencing the clock rate for
> another.
>    
This is the major feature of cf ( without this point the cf is just an other
  cf...)... Moreover it's required when clocks are shared resource....
If each device has its own clock... than also this feature isn't really 
important
  because each driver can manage its own clock.

Basically the cf manages each clock operation (enable/disable/set_rate),
  as a transaction with several states.

During the transaction all the clock frequencies are evaluated (before
  the real change) and all the devices can check if they agree the new
  clock rate.
Moreover this is done also in hierarchical manner (i.e.: if you change
  a PLL which several clock child).
Basically the clock propagation involves both clocks and devices.

Regards
  Francesco

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Linus Walleij]

2009/9/2 Francesco VIRLINZI <francesco.virlinzi@st.com>:

> I'm going to present a generic linux clock framework during the CELF-Europe

I now see that here is the presentation:
http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=ELC_E_2009_Generic_Clock_Framework.pdf

Are the patches posted?

Linus Walleij

[linux-pm] Montreal Linux Power Management Mini-Summit, July 13, 2009 - Meeting Notes

[Francesco VIRLINZI]

Hi Linus
No they aren't.

But asap I will post the patches or bring up a public git as other boys
  required during the conference.

Regards
  Francesco
On 10/18/2009 07:28 PM, Linus Walleij wrote:
> 2009/9/2 Francesco VIRLINZI<francesco.virlinzi@st.com>:
>
>    
>> I'm going to present a generic linux clock framework during the CELF-Europe
>>      
> I now see that here is the presentation:
> http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=ELC_E_2009_Generic_Clock_Framework.pdf
>
> Are the patches posted?
>
> Linus Walleij
>
>