Re: [PATCH 6/6 v2] arm: omap: usb: global Suspend and resume support of ehci and ohci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 5 Jul 2011, Felipe Balbi wrote:

> > >  Well, of
> > > course runtime PM will conserve power on runtime, but system suspend
> > > should be no different other than an "always deepest sleep state"
> > > decision.
> > 
> > No, it is significantly different for several reasons.  Some of the
> > most important differences are concerned with freezing userspace and
> > deciding what events should be allowed to wake up the system.  Also, 
> > there are systems which can achieve greater power savings by system 
> > sleep than they can by runtime PM + cpuidle.
> 
> I remember we've been through this discussion before and it's just
> nonsensical to make such statement. What does freezing userspace have to
> do with power consumption ? If you can't reach lower power consumption
> with runtime PM it only means userspace is waking the system too much.

_That's_ what freezing userspace has to do with power consumption.  You 
have answered your own question.

And don't forget the other points about wakeup events and greater power
savings.  If you want to discuss this further, you should start a new
thread on linux-pm.


> > Furthermore, from what I've gathered so far from this thread, the
> > _real_ problem is that nobody has written suspend and resume callbacks
> > for the parent device.  You're relying on runtime PM to do things with
> > the parent, but instead you should make use of the usual system sleep
> > mechanism: Parents are always suspended after their children and
> > awakened before.  Have the parent's suspend routine disable the clocks 
> > and have the resume routine enable them.  Problem solved, no changes 
> > needed in the child's driver code.
> 
> that's currently hidden on the omap rutime pm support. No driver is to
> talk to clk API directly anymore. Granted, now that I read what I just
> wrote it does sound like it's a limitation, although it's really nice
> not to have to remember all the numerous clocks needed for a particular
> device to work properly. So, if there would be a way, other than
> pm_runtime_resume(), to enable all clocks a particular device has
> without really having to clk_get(); clk_enable() each one of them, fine,
> this would be solved. But as of today, we only have pm_runtime_resume()
> to achieve that, unless I'm missing something.

(Actually, your problem isn't enabling clocks during resume; it is 
disabling them during suspend.)

The OMAP maintainer should be involved in this discussion.  Basically,
the new PM domain framework is now supposed to handle these issues.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux