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

[Michael Trimarchi <trimarchi@gandalf.sssup.it>]

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.
> Rafael
>
>   
Michael