Ambient Light Sensors subsystem
in [Kernel]
|
Prev: linux-next: build failure after merge of the driver-core tree
Next: linux 2.6.32 and 2.6.26 nat with pppoe throughput is very different.
From: Jean Delvare on 4 Mar 2010 04:30 On Wed, 3 Mar 2010 15:08:29 -0800, Dima Zavin wrote: > > Honestly, I don't care. The light sensor drivers can live wherever you > > want and use whatever interface you want, I don't give a damn. What I > > really want is that: > > 1* All light sensor drivers live at the same place in the kernel tree, > > so that people looking for them know where to look. > > 2* drivers/i2c/chips dies. Meaning that, if the tsl2550 driver has not > > moved away from drivers/i2c/chips by rc1, I'll move it myself, manu > > militari, to drivers/misc. > > Please do kill i2c/chips. I've tried to follow suite with your > campaign and have been pushing vendors on my end to not dump their > drivers in there. However, wanting to clean up the directory structure > is not a good reason to create a new interface to userspace. And > furthermore, the proposed directory structure changes are not really > that scalable imho (e.g. drivers/sensors/als would make a lot more > sense to me than to pollute the top level drivers/...). I don't disagree. > As it came up earlier in the thread, adding an ABS_AMBIENT_LIGHT_LEVEL > or equivalent is much simpler and provides a clean, concise, and > useful interface to userspace. > > Note that for many applications, you actually get configurable > threshold levels, and the hardware triggers an interrupt when the > light level crosses those thresholds. This makes using an input device > very useful, and that is in fact how we use ALS devices today. I have > several pieces of hardware that do this, and I don't see how this new > als subsystem helps me handle that problem. With the suggested API, > I'll have to poll the sysfs files manually to see if they've changed > (which is suboptimal), or still add a non-standard input device to do > what I want. The light sensor I have (TSL2550) is stupid and doesn't offer anything other than slow polling. Not thresholds, no interrupts, nothing. This is where the sysfs interface originates from. The very point of grouping light sensor drivers together is to get a better view of what the devices offer, and from there, of what interfaces make sense. > > I am a little sad to see two discussions about the ALS subsystem right > > in the middle of the merge window, one about what the interface should > > be and one about what the subsystem should include, while discussions > > about these two points have been ongoing publicly for 5 months now. I > > really want things (whatever they are) happen now and not in another 5 > > months. > > I'm sorry I missed the previous discussion, so please accept my > apologies. I was very busy with work at that time, I'm sure you know > how that goes. Sure I know. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 4 Mar 2010 06:20 Hi Linus, > On Wed, 3 Mar 2010, Dima Zavin wrote: >> >> Actually, accelerometers fit into that model fine. They have some >> variable number of absolute axes (3, 6, etc.). > > In fact, they obviouslya also do end up being used exactly like joysticks > in real life, and joysticks are commonly starting to have accelerometers > in them (ie any modern game console controller). > > So treating an accelerometer like a joystick - regardless of whether it > happens to be internal to the device or happens to be external in a > separate controller - is not all that far-fetched anyway. True enough if you want relatively low rate data either polled or from an internally clocked accelerometer. So yes, if your application is input and you are using an accelerometer for such a job, then it makes sense to be in input. That is exactly why Dmitry has taken some accelerometers in there. It isn't true if you are dealing with higher spec devices. There are devices out there that will throw data at many KHz with lot of different channels, these are totally different from what input was designed for. The deepest discussions of these points that I know of are those that IIO grew out of: http://lkml.org/lkml/2008/5/20/135 onwards. These in conjunction with ADC's etc were why we got into writing IIO in the first place + the entirely reasonable point that they fell out of the scope of input and hwmon. 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. 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? 3) Leave as is. Perhaps move all such drivers to misc and introduce some documentation in an attempt to standardize the interface they export. To all intents and purposes this is the core of als anyway. What we loose is a consistent location and device naming for userspace usage. 4) Move them into IIO. They are within the scope we are covering. I agreed with the ALS subsystem when it was proposed as it was clean small and ready now not because I particularly wanted them out of IIO (there is still one there.) Two comments on option 4: a) If we do it now rather than taking one of the other options and moving them later, then we are moving two perfectly good drivers out of the main tree into staging. Doesn't matter to me, may to others. b) If anyone comes back later and says, 'IIO is a massively overweight subsystem for such simple drivers', then I reserve the right to get rather somewhat annoyed. We have always kept the core driver requirement (that needed for these drivers) as slim as possible. Of course suggestions on how to make it slimmer without breaking other functionality are welcome. 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. Thanks, Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Amit Kucheria on 5 Mar 2010 02:40 On 10 Mar 03, Jonathan Cameron wrote: > > > > I was hoping IIO would fill the niche of framework for generic data > > acquisition devices, regardless of how fast or slow they are. > We are working on it, but unfortunately the 'fast' end of the scale is > making it rather complex beast and there is still a fair bit of work > to be done before we suggest merging into the main tree. We allow > for 'simple' drivers that do have very similar functionality to ALS as > proposed. (i.e. they just handle some sysfs interfaces and device > registration). > > I certainly have no objection to taking light sensors back into IIO. > (one never moved out!) Obviously I'll want opinions from the individual I suspect you are pointing to the tsl2563 driver here. It's rework (iio->als) has been languishing in my tasklist for a couple of months now. I haven't had time for testing. I guess I'll wait some more to see where this discussion goes. -- ------------------------------------------------------------------------- Amit Kucheria, Kernel Developer, Verdurent ------------------------------------------------------------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 5 Mar 2010 06:00 On 03/05/10 07:38, Amit Kucheria wrote: > On 10 Mar 03, Jonathan Cameron wrote: >>> >>> I was hoping IIO would fill the niche of framework for generic data >>> acquisition devices, regardless of how fast or slow they are. >> We are working on it, but unfortunately the 'fast' end of the scale is >> making it rather complex beast and there is still a fair bit of work >> to be done before we suggest merging into the main tree. We allow >> for 'simple' drivers that do have very similar functionality to ALS as >> proposed. (i.e. they just handle some sysfs interfaces and device >> registration). >> >> I certainly have no objection to taking light sensors back into IIO. >> (one never moved out!) Obviously I'll want opinions from the individual > > I suspect you are pointing to the tsl2563 driver here. It's rework (iio->als) > has been languishing in my tasklist for a couple of months now. I haven't had > time for testing. > > I guess I'll wait some more to see where this discussion goes. > Very wise! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jean Delvare on 7 Mar 2010 07:40
Hi Jonathan, On Thu, 04 Mar 2010 11:19:03 +0000, Jonathan Cameron wrote: > 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. This would be fine with me. > Perhaps move hwmon in there as well. I doubt it, especially if the interface to other sensors changes to treat them as input devices. At any rate, the hwmon interface is standardized since kernel ~2.6.5 and widely used, we're not going to change it now. So the benefit of sitting with other sensor type drivers is thin, probably thinner than the cost of the move. > > 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? I can't comment on this. It would seem reasonable to let the users (user-space applications) describe their needs and build the interface on top of that rather than the other away around. For this purpose, LKML doesn't seem like the right place to discuss. And I won't be the one driving the discussion anyway, I'm just a tourist here. > 3) Leave as is. Perhaps move all such drivers to misc and introduce some documentation > in an attempt to standardize the interface they export. To all intents and purposes > this is the core of als anyway. What we loose is a consistent location and device > naming for userspace usage. No. I don't think it makes any sense. As you underline it yourself, it has all the issues ALS has, without the main benefit. > 4) Move them into IIO. They are within the scope we are covering. I agreed > with the ALS subsystem when it was proposed as it was clean small and ready now > not because I particularly wanted them out of IIO (there is still one there.) Fine with me as well. > Two comments on option 4: > a) If we do it now rather than taking one of the other options and moving them later, > then we are moving two perfectly good drivers out of the main tree into staging. > Doesn't matter to me, may to others. Doesn't matter to me either, FWIW. > b) If anyone comes back later and says, 'IIO is a massively overweight subsystem for > such simple drivers', then I reserve the right to get rather somewhat annoyed. > We have always kept the core driver requirement (that needed for these drivers) > as slim as possible. Of course suggestions on how to make it slimmer without > breaking other functionality are welcome. > > 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. 4 days left before I take care of driver tsl2550 myself. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |