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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
