Message-ID: <aec7e5c30907121842p57a6fe3cud3d601a15c67df4f@mail.gmail.com>
Date:	Mon, 13 Jul 2009 10:42:31 +0900
From:	Magnus Damm <magnus.damm@...il.com>
To:	"Mahalingam, Nithish" <nithish.mahalingam@...el.com>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [linux-pm] [RFC][PATCH] PM: Introduce core framework for run-time 
	PM of I/O devices (rev. 8)

On Fri, Jul 10, 2009 at 6:56 AM, Mahalingam,
Nithish<nithish.mahalingam@...el.com> wrote:
> On Thu, Jul 9, 2009 at 10:48 PM, Alan Stern<stern@...land.harvard.edu> wrote:
>>> On Thu, 9 Jul 2009, Magnus Damm wrote:
>>>
>>>> Clocks should be stopped as soon as possible without any delay. The
>>>> clock stopping is very cheap performance wise. Also, the clock
>>> stopping is done on bus level without invoking any driver callbacks.
>>>> Delaying the clock stopping does not make any sense to me.
>>>
>>> In that case the device driver or bus subsystem should manage the
>>> device's clock directly.  There's no need to tie it in with the runtime
>>> PM framework.  Simply start the clock before each I/O operation and
>>> stop it afterward.
>
>> It's not that easy. The clock needs to be enabled to let the hardware
>> device perform device specific stuff. For instance, the clock for the
>> LCD controller needs to be on to redraw the screen. When the driver
>> knows that it's done with the clock it can notify the bus using
>> Runtime PM.
>
> Is there any plan to look into the "Clock Framework" that was developed as part of OMAP and extending this to make it generic for all platforms?

Do you mean vendor specific extensions to the clock framework? I'm
quite sure a bunch of architectures already support the clock
framework. Some architectures probably have extensions that would be
nice if they could be made more generic. Do you have any special
extensions in mind? =)

As for Runtime PM, clock stopping is only one part of the problem. On
SuperH we manage clock stopping through the clock framework and I'm
pretty sure other embedded architectures do that as well. That problem
is more or less already solved in my opinion.

For efficient power management on embedded systems we need more than
just clock stopping. We also want to save and restore device context
so we can turn off power to power domains during runtime. This is
somewhat tied together with clock stopping because we want to disable
clocks as soon as possible when the device gets idle but in the case
of domain power off we also need to start the clock before we can call
the ->runtime_suspend() callback provided by the driver. All this can
of course be handled by the device driver, but that would just be
duplicating too much code - I'd rather let the Runtime PM bus code
manage that.

Many runtime power management aware device drivers use clk_enable()
and clk_disable() stop and start clocks. But the clk_disable()
function is actually often used to signal that the device is idle.
Allowing device drivers to replace clk_enable()/clk_disable() with
Runtime PM callbacks to add support for context save and restore is a
logical next step from my point of view.

For SuperH we will most likely allow clock stopping through the clock
framework _or_ using Runtime PM in parallel, at least until all
drivers are converted to make use of Runtime PM.

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists