Re: [linux-pm] [PATCH v2 1/2] Input: gpio-keys - allow platform to specify exact irq flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2009-12-07 at 20:22 -0800, Dmitry Torokhov wrote:
> On Sun, Dec 06, 2009 at 09:47:04AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > 
> > > But runtime-pm.txt says for example:
> > > 
> > >     Generally, remote wake-up should be enabled for all input devices
> > >     put into a low power state at run time.
> > > 
> > > But in this case the requirement is to suppress input events from a
> > > given device, effectively muting and putting it into low power state,
> > > even though it's still open by some other parties.  Runtime PM, on the
> > > other hand tries not to interfere with the normal usage of the device.
> > > 
> > > Later:
> > > 
> > > (3) ->runtime_idle() and ->runtime_suspend() can only be executed for a
> > >     device the usage counter of which is equal to zero _and_ [...]
> > > 
> > > which underlines the difference again: the usage counter (defined by
> > > common sense) won't be zero in our case, because the device is
> > > constantly kept open, while we want to mute it, putting it into a low
> > > power state. 
> > ...
> > > Actually, this could be implemented by the various users cooperating in
> > > closing the device, letting it go to sleep automatically.  But this
> > > requires strictly cooperating parties and is more complicated that
> > > flipping some master switch of the device.  We're looking for this
> > > master switch, before needlessly building our own.
> > 
> > Please just close the device properly. I do not think we want 100
> > different 'please mute keys A and G', 'please mute middle mouse button',
> > ... interfaces anywhere near mainline.
> > 
> 
> I do not think it is practical to simply close the device, given that
> there may be several applications that have it open. I constantly see
> embedded guys adding custom knobs to the devices allowing them to shut
> off the device when not in use. Kind of runtame PM but user-initiated.
> 
> I would really love to have it implemented in the driver core so the
> interface is the same for all drivers (that support this future).
> 
> > Or just do it as local patch.
> 
> I also see that gpio-keys is quite different in the sence that it can
> shut off buttons selectively. I fact, at the moment every button can be
> considered a separate device... But that would be too much overhead.
> 
> They could probably split the keys into 2 groups (critical that should
> be always active) and not critical, that could be shut off, but I think
> they want teh flexibility of controlling this at runtime instead of
> doing it in board data.

I suggested including this into the "abstract input device" model, but
you refuse this. But I still think it is a good idea.

Indeed, if we look at an input device as at something abstract which has
many keys, why we cannot assume that separate keys can be
enabled/disabled? Just imagine you have a very advanced keybord :-) And
we simply implement an ioctl which enables/disables a specific key. The
generic layers just pass this ioctl down to the lower lever drivers. If
the specific input device or driver support it - fine, if not - it
returns -EINVAL or something like that.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux