linux-kernel - Re: [linux-pm] suspend blockers & Android integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Jun 2010 16:04:35 -0500
From:	James Bottomley <James.Bottomley@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	David Brownell <david-b@...bell.net>, tytso@....edu,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Neil Brown <neilb@...e.de>,
	Brian Swetland <swetland@...gle.com>,
	Felipe Balbi <felipe.balbi@...ia.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] suspend blockers & Android integration

On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote:
> On Fri, 11 Jun 2010, Mark Brown wrote:
> 
> > On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
> > > On Fri, 11 Jun 2010, James Bottomley wrote:
> > 
> > > > The one thing that does look difficult is that these power constraints
> > > > are device (and sometimes SoC) specific.  Expressing them in a generic
> > > > way for the cpu govenors to make sense of might be hard.
> > 
> > > Doesn't the clock framework already handle this sort of thing?
> > 
> > The clock framework is implemented independantly for each CPU.
> 
> That's not an impediment, since drivers' requirements regarding which 
> clocks remain running in which power states are necessarily 
> platform-dependent also.
> 
> 
> On Fri, 11 Jun 2010, James Bottomley wrote:
> 
> > Well, there are two elements to "this sort of thing":
> > 
> >      1. Allow a driver to request that a given clock not be turned off.
> >      2. Make the cpuidle governors aware of a pending "don't turn off X
> >         clock source" so they can keep the system in a state where the
> >         clock doesn't get powered down.
> > 
> > As far as I can tell from the code, neither currently exists at the
> > moment.
> 
> Well then, can (or should) the clock framework interact with the
> pm-qos subsystem so that drivers don't have to worry about it?

So the implementation of this seems to be a bit complex:  We could have
clockevents_register() do a per clock pm_qos variable but then the
cpuidle governors need to know which to listen for so they don't
transition to a state too low for them to be active if pm_qos says keep
them running.  Even if that gets sorted out, how would USB know which
platform specific clock source is driving the wakeup events on its bus?

How complex can SoC clocksources be?  If it's just a simple binary
do/don't potentially stop all clocks, I think it's easy.  If SoC's have
a hierarchical shutdown sequence, and they really need this to save
power, then expressing that generically becomes rather problematic.

James




--
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/