Message-ID: <527264.20535.qm@web180316.mail.gq1.yahoo.com>
Date:	Thu, 10 Jun 2010 21:21:39 -0700 (PDT)
From:	David Brownell <david-b@...bell.net>
To:	Brian Swetland <swetland@...gle.com>, Pavel Machek <pavel@....cz>
Cc:	tytso@....edu, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Florian Mickler <florian@...kler.org>,
	Neil Brown <neilb@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	James Bottomley <James.Bottomley@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Felipe Balbi <felipe.balbi@...ia.com>
Subject: Re: [linux-pm] suspend blockers & Android integration

This is a bit off the topic of Android
flamage, but I thought it would be worth
highlighting an example where the current
frameworks may still have a deficiency...
one that likewise relates to needing to
block entry ot a system suspend state, but
in this case user-space isn't very involved
(just drivers coping with hardware).

The example I wanted to re-post (I've done so
in the past) is one where drivers ouldn't really
do the right thing, since driver.suspend() wasn't
quite powerful enough as a programming interface.

The example works with USB on many ARM SoCs,
and similar non-USB examples aren't rare.

 - Want to enter a system suspend state, with
   some USB wakeup sources.  USB peripheral
   waken up by the host, or vice versa.

   NOTE ASSUMPTION:  there are multiple suspend
   states supported by the hardware, significantly
   different in hardware configuration Linux should
   be able to use more than one such state... (if
   only because their power savings differ.)  This
can mean driver-specific knowledge about those
various states.

 - The wakeup requires a particular clock to be active, so the USB controller can detect that the
wakeup should trigger,  then issue the right signals
triggering the non-USB parts of the system.

Problem:  how does the device driver suspend()
          method block entry to a suspend state
          when it can't ensure that clock is
          going to be active.  Magic return code?

 There are other issues here too.  (Is the target
 system suspend state one of the ones which doesn't
allow that clock to be active?  SoC-specific calls
might suffice for this issue.

 

A number of years ago, this problem was insoluble
with the then-current Linux PM and clock frameworks.
I've been away from this issue for quite a while
now, but don't recall seeing its sub-problems get
solved ... If they're now solved, I'll be glad.
(I know Kevin's recent OMAP stuff addresses similar
issues, but It's OMAP-specific...) 

After all these thousands and thousands of emails...
I'm not sure how much forward motion has happened.

Do we at least have a clean way that a driver can
reject a system suspend?  I've lost track of many
issues, but maybe this could be phrased as a QOS
constraint:  the current config of driver X needs
clock Y active to enter the  target system suspend
state, driver's suspend() method reports as much.  Then the entry to that system state gets blocked
if the clock isn't enabled.

(That QOS constraint should be removed when that
driver no longer needs to issue wakeups; that's
not quite the same as "removed by driver.resume().




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