Message-ID: <4B94D04A.7060308@cam.ac.uk>
Date:	Mon, 08 Mar 2010 10:24:10 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Dima Zavin <dmitriyz@...gle.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Amit Kucheria <amit.kucheria@...durent.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

Hi Dima,
>> Anyhow, the way this conversation is going there appear to be several options
>> and we need to make a decision before anyone wastes much more time.
>>
>> 1) ALS as is. It's extremely light weight and can always be merged with a better
>>  option at a later date. If people prefer we can always stick it in a subdirectory
>>  called sensors or similar.  Perhaps move hwmon in there as well.
> 
> If your plan is to integrate with iio when it's ready, then there will
> be a drivers/iio, so creating top-level als or even drivers/sensors at
> this point wouldn't really make sense. Perhaps putting them into
> drivers/misc/als is more appropriate?
That would work for me though it kind of breaks what I think misc is for.
It's Andrew Morton's domain though... (cc'd)
> 
>> 2) Input.  I agree with Dmitry here.  These devices are not within the scope as it
>>  currently exists.  It can be done and there have been numerous discussions about
>>  doing so in the past (with various sensor types) and each time it has been decided
>>  that it isn't the right option.  Perhaps opinion on this has changed?
> 
> As Dmitry correctly distilled from my ramblings, what we really need
> is support for poll() on sensor devices. If you guys add a poll
> interface to als, then we can probably get by until iio gets merged.
> Otherwise, we will still need to hack up an input device exporting
> ABS_MISC. If we had ABS_AMBIENT_LIGHT_LEVEL, then it'd be slightly
> less hacky.
Adding polling (here anyway) isn't actually a part of the subsystem.
Just write a driver which has some internal caching fed by relevant interrupt.
Then call sysfs_notify with parameters relevant to the attribute in question.
So for an illuminance0 reading say:

sysfs_notify(&device->dev.kobj, NULL, "illuminance0");

This covers any cases of the device notifying of new values.  You can always
add 'alarm' type attributes and poll on them. The only kicker here, is that
userspace that polls on a device not supporting polling will never get a
response. If you need 'alarm' type parameters feel free to add them as long
as they are suitable documented.

> 
>> Please can anyone who feels like suggesting another general sensors subsystem
>> at least taking a look at IIO (and keeping in mind we are in the middle of a big
>> API cleanup).  If you disagree with how we have done things, then contribute
>> to the discussions and they may change.
> 
> I looked into IIO (sorry for the delay), and it does look promising.
> I'll try to participate in future discussions, and will provide some
> more feedback in a more appropriate forum as it is likely out of scope
> here. When I get a chance, I'll try moving one of our drivers to iio
> and see how it goes.
Excellent, I'd suggest waiting till the current round of API changes are in
there.  Right now you'd just end up getting it working and I'd go break the
interface.  Hopefully, once that's in place those elements of the userspace
side of things will be more or less stable.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists