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