Re: [RFC Disable suspend on a specific device] This is a little change in linux power scheme

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Wednesday 08 April 2009, Michael Trimarchi wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday 08 April 2009, Michael Trimarchi wrote:
> >   
> >> Hi,
> >>
> >> Nigel Cunningham wrote:
> >>     
> >>> Hi.
> >>>
> >>> On Tue, 2009-04-07 at 23:38 +0200, Pavel Machek wrote:
> >>>       
> >>>> Well.... userspace should not have to decide this. If userspace tells
> >>>> kernel not to suspend video card (on PC/ACPI), then we either honour
> >>>> the request, or violate ACPI spec (and probably break suspend).
> >>>>         
> >>> What about the cases where the ACPI spec is irrelevant? (As I understand
> >>> it, not all embedded boards use ACPI). Would this be a good approach in
> >>> those cases? If so, perhaps the trick would be to make the functionality
> >>> depend on !CONFIG_ACPI?
> >>>       
> >> It can be an option, or just add only in embedded configuration where is 
> >> not ACPI configured.
> >> The dependences is allready provided by the kernel. The default is to 
> >> have suspend enabled.
> >> The user level access it's needed because the kernel does't exacly know 
> >> when the device must remain on/off during suspend.
> >>     
> >
> > So, who exactly is going to have that information?  Does it depend on a user
> > decision on something else?  If something else, then what?
> >   
> An example:
> 
> - a user has a blootooth handset and make a call so the application 
> framework
> know that that device are reserverd or blocked and are usefull for maintains
> the call on. but linux can suspend without problem. So the user level
> echo "disabled" for exaple to the 
> /sys/devices/platform/soc-audio/power/disabled
> and avoid suspending of audio devices and subdevice like aplifier, 
> switch , etc. This
> increase life battery of system, because permits a partial suspend.
> >   
> >> This api change can't cover any possible scenario but
> >> introduce a flexbility scheame in suspend process. Avoid suspend in some 
> >> device can be obtain
> >> looking at dependece too? I don't know exacly if the acpi capapiblity 
> >> can be seen throw the
> >> link to a bus or a specific class, but we can limit it to the platform 
> >> device instead all device.
> >>     
> >
> > If I understand it correctly, the behavior you'd like to obtain is quite
> > similar to the one of wake-up devices that usually also need to remain
> > powered (at least to some extent) during suspend.  This, however, is handled
> > by the drivers of that devices, in their suspend callbacks.
> >
> > How is your device different from the other wake-up devices?
> >   
> The difference from the wakeup device it's if I remember that they are 
> suspendend
> but ready to wakeup on external input. I want that device remain on, so 
> I think that is
> a little different beahvior. It's like to have a PM_DEVICE configuration 
> dynamic instead of static.

OK, thanks.

I think this is a rather fundamental issue and it requires some more thought.

What platform is your device based on, BTW?

Rafael