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

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

[Len Brown]

We will hold a Linux Power Management Mini-Summit in Montreal
on Monday, July 13, 2009 -- concurrent with day-1 of the
tutorials at the at the Linux Symposium.

http://www.linuxsymposium.org/2009/schedule.php

This is an opportunity for members of the Linux Power Management
development community to meet face-to-face to discuss the future.

Suggestions for agenda topics should be sent to: 
linux-pm@lists.linux-foundation.org

The final agenda will be formed by consensus of the attendees.

As in previous years, attendance is open to those
registered as Linux Symposium attendees.

However, we will try to cap attendance at 20 to support the single 
discussion.  So requests to attend should be sent to: lenb@kernel.org
cc: linux-pm@lists.linux-foundation.org -- please summarize
what you bring to the meeting, and what you'd like to discuss.

Presentations are allowed to guide discussion, but not required.
There will be no recording or audio bridge, however written minutes will 
be published on lwn.net.

2007: http://lwn.net/Articles/249019
2008: http://lwn.net/Articles/292447

If you have feedback on last year's meeting that
we can use to improve this year's, please speak up.

thanks,
Len Brown, Intel Open Source Technology Center

ps. If you are interested in sponsoring food or
    other forum needs, please let me know.

Re: Montreal Linux Power Management Mini-Summit -- July 13, 2009

[Rafael J. Wysocki]

Hi,

On Thursday 21 May 2009, Len Brown wrote:
> We will hold a Linux Power Management Mini-Summit in Montreal
> on Monday, July 13, 2009 -- concurrent with day-1 of the
> tutorials at the at the Linux Symposium.
> 
> http://www.linuxsymposium.org/2009/schedule.php
> 
> This is an opportunity for members of the Linux Power Management
> development community to meet face-to-face to discuss the future.
> 
> Suggestions for agenda topics should be sent to: 
> linux-pm@lists.linux-foundation.org
> 
> The final agenda will be formed by consensus of the attendees.
> 
> As in previous years, attendance is open to those
> registered as Linux Symposium attendees.
> 
> However, we will try to cap attendance at 20 to support the single 
> discussion.  So requests to attend should be sent to: lenb@kernel.org
> cc: linux-pm@lists.linux-foundation.org -- please summarize
> what you bring to the meeting, and what you'd like to discuss.

I'd like to addend and I'd like to discuss the following topics:

* PM-related changes in the Linux kernel since the last PM Mini-Summit
* Future plans for the PM development, kernel side
* Run-time PM of I/O devices, from the PCI POV mostly

Thanks,
Rafael

Re: Montreal Linux Power Management Mini-Summit -- July 13, 2009

[Magnus Damm]

Hi Len,

On Fri, May 22, 2009 at 4:12 AM, Len Brown <lenb@kernel.org> wrote:
> We will hold a Linux Power Management Mini-Summit in Montreal
> on Monday, July 13, 2009 -- concurrent with day-1 of the
> tutorials at the at the Linux Symposium.
>
> http://www.linuxsymposium.org/2009/schedule.php
>
> This is an opportunity for members of the Linux Power Management
> development community to meet face-to-face to discuss the future.
>
> Suggestions for agenda topics should be sent to:
> linux-pm@lists.linux-foundation.org

I'd like to attend and discuss the following:
 - Runtime PM for Platform Devices.
 - User space interface for clock configuration.

/ magnus

Re: [linux-pm] Montreal Linux Power Management Mini-Summit -- July 13, 2009

[Paul Mundt]

On Thu, May 21, 2009 at 03:12:53PM -0400, Len Brown wrote:
> We will hold a Linux Power Management Mini-Summit in Montreal
> on Monday, July 13, 2009 -- concurrent with day-1 of the
> tutorials at the at the Linux Symposium.
> 
> http://www.linuxsymposium.org/2009/schedule.php
> 
> This is an opportunity for members of the Linux Power Management
> development community to meet face-to-face to discuss the future.
> 
> Suggestions for agenda topics should be sent to: 
> linux-pm@lists.linux-foundation.org
> 
> The final agenda will be formed by consensus of the attendees.
> 
> As in previous years, attendance is open to those
> registered as Linux Symposium attendees.
> 
> However, we will try to cap attendance at 20 to support the single 
> discussion.  So requests to attend should be sent to: lenb@kernel.org
> cc: linux-pm@lists.linux-foundation.org -- please summarize
> what you bring to the meeting, and what you'd like to discuss.
> 
I'd also like to attend. Areas of interest this year are run-time PM,
moving to clock framework notifiers, and tying in pm qos for transition
latencies.

Re: Montreal Linux Power Management Mini-Summit -- July 13, 2009

[Len Brown]

Here is a list of who responded, and their suggestions for topics.
I don't know what size room Andrew will have for us, but it appears
that we shall have plenty of space if others would like to drop in
to chat about power management.

See you Monday morning in Montreal!

thanks,
Len Brown, Intel Open Source Technology Center
---
Rafael J. Wysocki <rjw@sisk.pl>

* PM-related changes in the Linux kernel since the last PM Mini-Summit
* Future plans for the PM development, kernel side
* Run-time PM of I/O devices, from the PCI POV mostly
---
Magnus Damm <magnus.damm@gmail.com>

 - Runtime PM for Platform Devices.
 - User space interface for clock configuration.
---
Paul Mundt <lethal@linux-sh.org>

run-time PM,
moving to clock framework notifiers, and tying in pm qos for transition
latencies.
---
Rickard Andersson <rickard.andersson@stericsson.com>
Per-Inge Tallberg

for example "partial RAM self refresh"

---
Richard Wooodruff <r-woodruff2@ti.com>

---
Aurelien Degremont <aurelien.degremont@cea.fr>

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

[Len Brown]

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

The Linux Symposium generously provided the facilities.

We repeated the process used in 2008: http://lwn.net/Articles/292447/

This year the meeting room was more accessible to the general attendees
of the Linux Symposium, so we had a fair number of "drop-ins".
25 signed in (listed below) plus a few more that came and went.
While this exceeded our cap of 20, the extra people did not hinder
our goal of focusing on a single discussion.

Attendees
---------
Len Brown - Intel - ACPI, SFI, Suspend co-Maintainer
Howard Alyne - Wind River
Pierre Phaneuf
Rafael J. Wysocki - SUSE Labs/Novell, U. Warsaw;  Hibernate and Suspend Maintainer
Per-Inge Tallberg - Ericsson
Rickard Andersson - Ericsson
Paul Mundt - Renesas - SH Maintainer
Magnus Damm - Renesas
Richard Wooodruff - Texas Instruments, OMAP
Stephen Hui - Zarlink
John Linville - Red Hat - Wireless LAN maintainer
Mark Brown - Marvell
Samuel Thibault - labri.fr
Lucas Nussbaun - inria.fr
Srinivas Sripathi - Motorola
Jason Baron - Red Hat
Aristu Rozanaski - Red Hat - RHEL6 kernel maintainer
Christopher Curtis - RipTide Software
Klaus Pedersen - Nokia
H. Peter Anvin - Intel - x86 maintainer
Ernest Szedeman - Nortel
Rick Leir - Leirtech
David Ahern - Cisco
Wending Wen - Rheinmetall
Jason Chagas - Marvell

Some of the attendees are in photos here:
http://picasaweb.google.com/lenb417/2009LinuxSymposium#

Agenda
------
	1. Review changes over the last year
	2. Survey tools, techniques, workloads
	3. Discuss upcoming work

Summary of Power Management kernel changes since last year
----------------------------------------------------------
ACPI Platform BIOS compatibility fixes
	ACPI ACPI_SCI_EN work-around
	resume memory corruption workarounds

hibernation:
	NVS memory handling
	handle overlapping memory zones

suspend/resume framework re-work (Rafael Wysocki)
	shipped suspend/resume RTC test feature
	ordering update/workaround
	simplified driver interface now available
		r8169 etc. drivers now using it
	PCI PM framework re-worked to simplify drivers
	graphics drivers better support suspend/resume
		i915 video restore, though has bugs
		ATI making progress, especially older cards
		NVIDIA - continues to trail
			no open source support for devices after 7200
power aware scheduling
	sched_mc_power_savings
	per-CPU timers fixed
clock_events_broadcast()
	bugs fixed
	(no longer needed on Westmere, which has always running LAPIC timer)
range timers shipped upstream
	eg. range timers used android to group around wireless

Intel shipped Nehalem (Core i7), which has always-running-TSC

Run Time power management is receiving some attention now.

OMAP (Richard Woodruff)
	2008 had TI releasing aggressive full-off reference code on public portals
		Customers snapshotted this code at different points
		Heavy support burden ramping variants into production
	Linux-OMAP community have been creating a cleaner version of aggressive PM
	code suitable for mainline kernel in Linux-OMAP PM branch.
		Hope of reduced burden for future kernels with mainlined code

ACPI sub-system (Len Brown)
	quality has been the focus for the last year.
	We continue to process about 300 bugs/year
	with 50-60 unresolved at any given time.

Wireless: (John Linville)
	mac-80211 is now suspend/resume aware
	IEEE-80211 has run-time power saving features
		eg. negotiate w/ access point
		starting to deploy in drivers
	beacon filtering (reduces CPU wake-ups)
	TX power upcoming in cfg-80211 API
		Nokia tablets pushing power savings

SH: (Paul Mundt)
	cpuidle integration
	using clocksources & clockevents from upstream
	can switch between timers depending on sleep states
	Hibernate & STR enabled, can test w/ RTC & kexec-jump-and-return

s390:
	added suspend/resume support

5-second boot on Atom netbook for Moblin
	async API is upstream
	Fedora Core-11 boots in 20 seconds on a notebook
		Down from 60 seconds in Fedora Core-10

PM-QOS shipped
	Documentation/power/pm_qos_interface.txt

Survey of Tools, Techniques, workloads for optimizing power management
----------------------------------------------------------------------
powertop
bootchart
bootgraph
CONFIG_POWER_TRACER=y
	LTT-lite
performance counters for energy coming
OMAP uses on-board instrumentation
suspend/resume debug I/F
Power meters:
O(100) Watts Up Pro; O(600) Extech; O(1000) Yokogawa
O(600) HP/Agilent 34401A
OMAP: measure per-power-plane w/ lab instruments
500mA vs uA range difficult to measure w/ precision
	multi-channel DAC - each channel calibrated to range

Workloads for measuring power:

handheld: no standard workloads
	however device vendors have internal benchmarks
	#1 idle
	#2 specific workloads
	#3 combination use-case

SpecPower benchmark for servers (only)

Energy Star for client computers
	idle only
	requires STR to be enabled by default
	Energy Star Server spec coming
	Future Energy Star wants to use energy benchmark
BAPCO
	MobileMark 2007 for Windows
	Apple joined, so expect something new to work also on Apple
	No Linux Distro representation
EEMBC
	released something or other...
BLTK (Battery Life Toolkit) for Linux
	http://www.lesswatts.org/projects/bltk/
	could use refresh
	could use handheld new workloads

Future plans for the PM development, kernel side
-------------------------------------------------
cpuidle C-states generalized to be platform idle states...
	platform driver can hide platform hooks into CPU power states

Runtime PM for Platform Devices.
	2.6.32 framework plan simmering
	SH running on top of prototype now
		context save/restore for power off power domain

	platform devices
		SH specific - Magnus
	IO devices
		eg PCI, USB - Alan Stern

	clock framework (started in ARM, now common on embedded)
		includes ref-counts/clock
		architecture specific implementation
		x86/ACPI system doesn't expose clock dependencies
			so unclear benefit to that arch

Run-time PM of I/O devices, from the PCI POV mostly
	ability to put device into D1/D2 (~200us) /D3 (10ms)

	wakeup: PCIe #PME plug-event via root port
	(PCI #PME is less well specified)

ACPI 4.0 adds D3hot
	Q: has an effect on _SD3?

Hibernate/suspend:

Axiom: we need more people fixing suspend/resume bugs

Suspend2 aka "Tux on Ice"
	Spring 2009 patch set to replace hibernate w/ TOI was
	deemed impractical by upstream community, which prefers
	an incremental approach.

	Since, Nigel has sent specific patches to Rafael along
	the lines of gradual cherry-picking that upstream needs.

	First example is patch to compress hibernation image
	which Rafael thinks can be integrated.

	TOI is able to save larger hibernate images due to
	how it manages memory.  This is a nice benefit and
	we'd like to see if we can do it upstream.

	patch review bandwidth limited
	
	1. image compression
	2. image saving performance
		currently very slow
	3. ability to use multiple devices to save images
		including multiple swaps, and regular files
	4. break the half-of-memory image limitation
	5. Image encryption (solution for keys is an issue)

	It would be great to have Nigel supporting upstream hibernate.

	TOI supports snapshot boot via "kiosk mode"

Hibernate & kexec
	kexec-jump is upstream (i386, SH, no x86_64)
		simplifies memory management of the "jumped to" code
		unclear if any other advantages.

kexec-crash-dump is useful
	can make an oops "look less scary" and be automatic

STR performance
	eliminate console switch
	async device resume

android submitted "auto-suspend" patches
	compromise between low-level and high-level suspend invocation policy.

cpuidle vs auto-suspend
	suspend is more "draconian", it stops timers etc for you.
	platform drivers in cpuidle can get to same place.

Android
	OHA -Open Handset Alliance
		controls android license(s)
		Android = access to app-store
Moblin
	shall support Android applications

OMAP & SH specifics

	UIO - user space codec etc. have no concept of PM
		could use clock framework extension
		(clock framework is accessible via debugfs if necessary)
	interrupt coalescing
	deferred I/O to LCD
		delay until regular (infrequent) update interval
		use x-damage API to track change to visible screen

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

lightweight CPU hotplug
	IBM proposed "idle throttling" approach using scheduler
	Intel is proposing simple "forced idle" RT thread
	PeterZ likes neither implementation, but
	favors the IBM approach in the long term.

	SH SMP wants to run Itron on some cores...
	low latency transition is important

Memory Power Management
	Nokia project w/ U. in Brazil
		more pain than gain in memory offline prototype
	"partial RAM self refresh"

	page tables for kernel memory would allow
		moving kernel physical memory

	memory off-line incompatible with high-performance interleaving

	using NUMA node to segment memory allows tracking
		unused memory
	anti-fragmentation went upstream last year

	consensus: online/offline
		node granularity only

ACPI 4.0 was published
	Error Reporting extensions
	processor aggregator device (forced idle to save power)
	D3hot
	generalized fan support
	thermal extensions
	IPMI op-region

	Len will do a Linux ACPI 4.0 presentation this Fall

virtualization power management
	PM is still an after-though in the VMM space
		they have bigger problems

	KVM gets everything in Linux for free
		but could benefit from more info from the guests

	Xen gets to re-invent/port/re-implement everything in Linux

	VMMS have an easier time moving physical pages
		and thus doing memory power management

Re: 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

Re: 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@billgatliff.com

Re: 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@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
>
>    

Re: [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

Re: [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?

Re: [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?
>
>    

Re: 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)

Re: [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

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

[Woodruff, Richard]

> From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-
> bounces@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.

Re: 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

Re: [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

Re: [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
>
>