Re: klists and struct device semaphores

• Previous message: Emmanuel Papirakis: "off topic: GPL and binary modules"
• In reply to: David Brownell: "Re: klists and struct device semaphores"
• Next in thread: David Brownell: "Re: klists and struct device semaphores"
• Reply: David Brownell: "Re: klists and struct device semaphores"
• Reply: Dmitry Torokhov: "Re: klists and struct device semaphores"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date:	Thu, 31 Mar 2005 10:26:36 -0800 (PST)
To: David Brownell <david-b@pacbell.net>

On Thu, 31 Mar 2005, David Brownell wrote:

> On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> > On Thu, 31 Mar 2005, Alan Stern wrote:
> > > On Wed, 30 Mar 2005, Patrick Mochel wrote:
> >
> > > > In fact, we probably want to add a counter to every device for all "open
> > > > connections" so the device doesn't try to automatically sleep while a
> > > > device node is open. Once it reaches 0, we can have it enter a
> > > > pre-configured state, which should save us a bit of power for very little
> > > > pain.
> > >
> > > By "open connections", do you mean something more than unsuspended
> > > children?
> >
> > Yes, I mean anything that requires the device be awake and functional.
>
> So for example a device that's suspended and enabled for wakeup could be
> "open" ... which fights against your "doesn't try to sleep" policy.

I don't understand what you mean. Even if a device is suspended, be it
automatically after some amount of inactivity or as directed explicitly by
a user, we want to be able to open the device and have it work.

Conversely, we only want to automatically suspend the device, or allow the
device to be explicitly put to sleep, if the device is not being used.

For the majority of devices, that seems like a basic, simple, intuitive
rule. I'm sure there will be exceptions (there always are), but I expect
those to be rare and subsystem (if not platform) specific.

> > This would include open device nodes for many devices, open network
> > connections for network devices, active children for bridges and
> > controllers, etc.
>
> Same thing applies. Many devices can be suspended but wake up on demand.
> And even pass the wakeup events up the hardware connectivity tree. In
> fact, being able to do that is a requirement to support that "USB mouse
> on Centrino laptop" example: USB mouse suspended, ditto the USB host
> controller, then the CPU can enter C3 state and save a few more Watts.
> Move mouse, wakeup the USB controller, CPU leaves C3.
>
> In general, good power management will _want_ to leverage such modes.
>
> Worth noting: it's very similar to what modern CPUs do internally,
> powering parts off until they're needed. The same model can apply
> to other chips; and to boards that integrate those chips...

I agree.

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

• Previous message: Emmanuel Papirakis: "off topic: GPL and binary modules"
• In reply to: David Brownell: "Re: klists and struct device semaphores"
• Next in thread: David Brownell: "Re: klists and struct device semaphores"
• Reply: David Brownell: "Re: klists and struct device semaphores"
• Reply: Dmitry Torokhov: "Re: klists and struct device semaphores"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]