From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 02/04] Driver Core: Add idle and wakeup functions
Date: Tue, 09 Jun 2009 23:41:37 +0000 [thread overview]
Message-ID: <200906100141.38833.rjw@sisk.pl> (raw)
In-Reply-To: <20090527100642.29671.52231.sendpatchset@rx1.opensource.se>
On Tuesday 09 June 2009, Magnus Damm wrote:
> On Sat, Jun 6, 2009 at 5:42 AM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > On Friday 05 June 2009, Magnus Damm wrote:
> >> On Wed, Jun 3, 2009 at 6:05 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> >> > On Friday 29 May 2009, Magnus Damm wrote:
> >> >> 2009/5/29 Rafael J. Wysocki <rjw@sisk.pl>:
> >> >> > On Wednesday 27 May 2009, Magnus Damm wrote:
> >> >> >> From: Magnus Damm <damm@igel.co.jp>
> >> >> >>
> >> >> >> Add platform_device_idle() and platform_device_wakeup()
> >> >> >> and allow architectures to implement their own versions
> >> >> >> of these if CONFIG_HAVE_PLATFORM_IDLE_WAKEUP is set.
> >> >> >>
> >> >> >> Signed-off-by: Magnus Damm <damm@igel.co.jp>
> >> >> >> ---
>
> >> The wakeup()/idle() code in this patch is one way to solve it on a
> >> platform device level. Another more generic way would be to add
> >> ->enable() and ->disable() callbacks to struct bus_type and introduce
> >> device_enable() and device_disable() that takes struct device and
> >> invokes the bus callbacks if set.
> >
> > So, you need a generic mechanism that drivers can use to notify the bus type
> > code that a device is idle and therefore it should schedule an autosuspend
> > request for the device. Also, you want a mechanism by which drivers can notify
> > the platform code that there is a need to wake-up an autosuspended device.
> > Is that correct?
>
> Yes, you are 100% correct that I want drivers to have some way to
> notify the bus type that a certain device is idle or needs to be woken
> up.
>
> Exactly what should happen when the device is marked as idle is a
> different question. I guess this is bus specific. Connecting the idle
> notification directly to autosuspend is not a very good idea IMO since
> the power management comes with latency restrictions.
>
> If we zoom out a bit then I think that we should have something
> similar to cpuidle but for devices. Maybe the driver should give a
> list of suspend modes, their latencies and power savings. This per
> driver (or per device) latency information is important, but even more
> important IMO is latency information for the bus itself.
>
> So for our on-chip SuperH SoC platform devices I'd like to keep track
> of which devices that are idle, and if all devices within one power
> domain are idle then i'd like to execute autosuspend() for those and
> after that power off the bus/domain. But only if this doesn't break
> any latency requirements.
OK, I think we can add ->idle() and ->wakeup() callbacks to struct bus_type
for this purpose.
BTW, I'm waiting for a new version of your patch adding the arch data to
struct platform_device with a better changelog.
Best,
Rafael
next prev parent reply other threads:[~2009-06-09 23:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 10:06 [PATCH 02/04] Driver Core: Add idle and wakeup functions Magnus Damm
2009-05-28 21:29 ` Rafael J. Wysocki
2009-05-29 5:10 ` Magnus Damm
2009-06-03 9:05 ` Rafael J. Wysocki
2009-06-05 3:26 ` Magnus Damm
2009-06-05 20:42 ` Rafael J. Wysocki
2009-06-09 4:22 ` Magnus Damm
2009-06-09 23:41 ` Rafael J. Wysocki [this message]
2009-06-10 6:03 ` Magnus Damm
2009-06-10 8:19 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906100141.38833.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox