Re: [RFC PATCH 1/1] Input: gpio-keys: export gpio key information through sysfs

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

 



Hi Artem,

On Mon, Nov 09, 2009 at 05:09:04PM +0200, Artem Bityutskiy wrote:
> On Thu, 2009-11-05 at 23:52 -0800, Dmitry Torokhov wrote:
> > On Wed, Nov 04, 2009 at 11:25:59AM +0200, Artem Bityutskiy wrote:
> > > > > > I think registering a full-blown device for every key is way too much,
> > > > > > given that most consumers of gpio-keys driver are embedded... Besides, I
> > > > > > don't think this should be driven from userspace. Board (platform) code
> > > > > > should know what GPIO make sense as wake up sources for the particular
> > > > > > device and should set up platform data accordingly.
> > > 
> > > For example, on N900 we want to disable the lens cover / proximity / etc
> > > gpios when the phones' screen is locked. Simply because we do not want
> > > the lines to generate interrupts, wakes up the CPU and waste our battery
> > > energy. But we do not want to disable the screen lock gpio, and some
> > > incoming call related gpios.
> > > 
> > > So we really do want this to be userspace-driven.
> > > 
> > 
> > OK, then maybe we should use 2 attributes, one showing gpios that can
> > be used for wakeup and one showing gpios that are currently set up as
> > wakeup sources. These can be built on using bitmap_scnlistprintf() and
> > bitmap_parselist() and can work with either GPIO numbers or keycodes.
> 
> Hi Dmitry,
> 
> could you please elaborate some more?
> 
> * are you talking about per-input device sysfs files?

I am not sure at what level these attributes must be created. While the
easiest way is indeed per-input device attribute (for that particular
driver) the functionality does not really have anything to do with
input... I'd probably prefer having this attribute elsewhere, maybe
we should extend /sys/class/gpio/gpioN for these purposes?

> * could you please give an example of how would I switch off, say, the
>   SW_CAMERA_LENS_COVER gpio by the keycode.

If the code lies in your driver then it is easy (the driver knows the
mapping); otherwsie you'll have to go with GPIO number.

> * why this should be sysfs and not a new ioctl?

Because it makes sense onfy for 1 or 2 devices.

> * should this be something specific to gpio-keys or common for all
>   devices?

I don't see how you can make it common for all input devices... But
maybe there other subsystems (PM?) that would make better sense for such
facility (control of wakeup sources). In fact, there is already power/wakeup
attribute, can you plug in there?

Thanks.

-- 
Dmitry
--
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