Re: [linux-pm] [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Sat, Aug 20, 2011 at 06:51:42PM +0200, Rafael J. Wysocki wrote:
> On Saturday, August 20, 2011, Mark Brown wrote:

> > Coming at this from the embedded perspective modifying the kernel just
> > isn't an issue.  It's quite depressing in other cases too but some of
> > the circumstances you mentioned in previous messages are sensible do
> > make sense to me.  It does seem like this is a system specific problem
> > which we should be able to enable as part of the support for those
> > systems.

> I don't think that's platform-specific in general.  For example, there are
> devices that don't really belong to any media-streaming-alike framework
> and we may (and probably will) want to use PM QoS with them, because they
> may be included in PM domains and influence power management of other
> devices.  Think of a serial console.

Using PM QoS doesn't seem platform specific of course.  Having userspace
need to go in and do per-device overrides in order to get things working
does.

> > > without modifying the kernel.  Also, it will help to test and debug new drivers
> > > and subsystems.

> > If it were a debugfs facility I'd not be concerned.

> If that's going to be per-device, it really is much easier to put it into
> sysfs (we already have per-device PM debug interfaces in there).  It may
> depend on CONFIG_PM_ADVANCED_DEBUG or something like this, though, at least
> to start with.

Yeah, the debugfs device attachment stuff is slightly annoying but it's
fairly straightforward to create an appropriate heirachy - there's
several subsystems doing that sort of stuff by using dev_name().

> > That's not really a problem - if people are adding their own crazy
> > interfaces it's clear that they've done that.  It'll show up as a red
> > flag to anyone looking at their stuff and this will create pressure on
> > them to fix their code or at least do a better job for the next thing.

> > The goal isn't to tie people's hands to stop them doing silly things,
> > it's to make it clear that that is what they're doing.

> The same applies to using kernel interfaces.  If someone uses a sane
> interface for doing crazy stuff, that's their problem and should show
> up as a red flag just as well.

The big problem I'm seeing here is that there's nothing about having
userspace do all the knob twiddling that looks crazy just from looking
at the system.  The controls are there and in the standard kernel
interface, it's not like there's any ABIs or large piles of in kernel
code that need to be added (if anything the in kernel code should look
simpler as there's less going on).