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: Dima Zavin on 3 Mar 2010 01:20 Sorry if I'm jumping in a little late, but I'm concerned that adding ALS as a separate "framework" is going to set the wrong precedent. ALS is just one example of a class of sensors that are present on modern mobile devices (e.g. ALS, proximity, compass/magnetometer, accelerometer, etc.). Also, how does this deal with hybrid devices? Many ALS devices have a proximity sensor on the same package. You'll need to deal with enabling/disabling them separately, but likely share a power function at the board file level (at least for arch/arm systems). I definitely see the need for what you guys are trying to accomplish. For example, currently, we use an input device for reporting events, and a separate misc device node for control (enable/disable/configure). It's definitely suboptimal, but there currently isn't anything there would let us do things cleanly. What I would love to see is a more generic sensors framework that handles different kinds of sensor devices, and different data acquisition schemes (sampled vs. change notifications). I would love to work with you to design something more generic. Thanks. --Dima On Mon, Mar 1, 2010 at 11:41 AM, Jonathan Cameron <jic23(a)cam.ac.uk> wrote: > Dear Linus, > > Please pull from > > � � � �git://git.kernel.org/pub/scm/linux/kernel/git/jic23/als.git for-linus > > to get the Ambient Light Sensors subsystem. > A large part of the following consists of moving two drivers from > elsewhere in the kernel to als now it is available. > > acpi-als will merge later through the acpi tree as it sits entirely > within their directories. Both moves have been confirmed with the > respective maintainers and all known users of the drivers. > > All changes as per linux-next branch where they have been for some weeks. > > Thanks, > > Jonathan > > Amit Kucheria (1): > � � �als: add unique device-ids to the als device class > > Jonathan Cameron (5): > � � �ALS: Add jic23 and als git tree to MAINTAINERS > � � �tsl2550: Move form i2c/chips to als and update interfaces. Remove i2c/chips in this commit to avoid build failure that results from separating that step out. > � � �als: tsl2550: Remove spurious check against a maximum lux value. > � � �Merge remote branch 'linus/master' into for-next > � � �isl29003: Move from misc to als now it is available with minimal changes > > Zhang Rui (1): > � � �introduce ALS sysfs class > > > �Documentation/ABI/testing/sysfs-class-als | � 18 +++++ > �MAINTAINERS � � � � � � � � � � � � � � � | � �8 ++ > �drivers/Kconfig � � � � � � � � � � � � � | � �2 + > �drivers/Makefile � � � � � � � � � � � � �| � �1 + > �drivers/als/Kconfig � � � � � � � � � � � | � 34 +++++++++ > �drivers/als/Makefile � � � � � � � � � � �| � �9 ++ > �drivers/als/als_sys.c � � � � � � � � � � | �116 +++++++++++++++++++++++++++++ > �drivers/{misc => als}/isl29003.c � � � � �| � 46 ++++++++---- > �drivers/{i2c/chips => als}/tsl2550.c � � �| � 96 +++++++++++++++--------- > �drivers/i2c/Kconfig � � � � � � � � � � � | � �1 - > �drivers/i2c/Makefile � � � � � � � � � � �| � �2 +- > �drivers/i2c/chips/Kconfig � � � � � � � � | � 19 ----- > �drivers/i2c/chips/Makefile � � � � � � � �| � 18 ----- > �drivers/misc/Kconfig � � � � � � � � � � �| � 10 --- > �drivers/misc/Makefile � � � � � � � � � � | � �1 - > �include/linux/als_sys.h � � � � � � � � � | � 35 +++++++++ > �16 files changed, 314 insertions(+), 102 deletions(-) > �create mode 100644 Documentation/ABI/testing/sysfs-class-als > �create mode 100644 drivers/als/Kconfig > �create mode 100644 drivers/als/Makefile > �create mode 100644 drivers/als/als_sys.c > �rename drivers/{misc => als}/isl29003.c (90%) > �rename drivers/{i2c/chips => als}/tsl2550.c (82%) > �delete mode 100644 drivers/i2c/chips/Kconfig > �delete mode 100644 drivers/i2c/chips/Makefile > �create mode 100644 include/linux/als_sys.h > -- > 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/ > -- 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 3 Mar 2010 04:40 On Tue, 2 Mar 2010 22:13:21 -0800, Dima Zavin wrote: > Sorry if I'm jumping in a little late, but I'm concerned that adding > ALS as a separate "framework" is going to set the wrong precedent. ALS > is just one example of a class of sensors that are present on modern > mobile devices (e.g. ALS, proximity, compass/magnetometer, > accelerometer, etc.). Also, how does this deal with hybrid devices? Hybrid devices are common and how they can be handled is completely unrelated to the ALS subsystem. They are usually handled by the mfd subsystem, and then each separate function can go to the relevant subsystem. > Many ALS devices have a proximity sensor on the same package. You'll > need to deal with enabling/disabling them separately, but likely share > a power function at the board file level (at least for arch/arm > systems). > > I definitely see the need for what you guys are trying to accomplish. > For example, currently, we use an input device for reporting events, > and a separate misc device node for control > (enable/disable/configure). It's definitely suboptimal, but there > currently isn't anything there would let us do things cleanly. > > What I would love to see is a more generic sensors framework that > handles different kinds of sensor devices, and different data > acquisition schemes (sampled vs. change notifications). > > I would love to work with you to design something more generic. This can happen later, I see no reason to block the creation of the ALS subsystem. Having a common framework for all ambient light sensor drivers will already be a step forward compared to the current situation. If improvements are needed on top of this, this can happen later. -- 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: Dima Zavin on 3 Mar 2010 05:30 Jean, Thanks for the prompt reply. >> I definitely see the need for what you guys are trying to accomplish. >> For example, currently, we use an input device for reporting events, >> and a separate misc device node for control >> (enable/disable/configure). It's definitely suboptimal, but there >> currently isn't anything there would let us do things cleanly. >> >> What I would love to see is a more generic sensors framework that >> handles different kinds of sensor devices, and different data >> acquisition schemes (sampled vs. change notifications). >> >> I would love to work with you to design something more generic. > > This can happen later, I see no reason to block the creation of the ALS > subsystem. Having a common framework for all ambient light sensor > drivers will already be a step forward compared to the current Following the logic of putting the ALS subsystem under drivers/als, we would then put the proximity subsystem under drivers/proximity, and then an accelerometer subsystem under drivers/accelerometer, etc. Each with their own implementation of very similar set of interfaces. Is that what you envision? I just figured that instead of creating one-off interfaces for some subset of environmental sensors such as als, we can add a sensors subsystem of which als is just an instance. > situation. If improvements are needed on top of this, this can happen > later. I'm just concerned that instead of solving the actual problem, you are adding what is essentially a temporary solution. This will only make it harder to solve the real issue by introducing new interfaces which will need to be obsoleted unless they are designed with care. What you are proposing already needs improvements since there are plenty of drivers floating out there from many OEMs/vendors that are not ALSs, but essentially need a similar interface (e.g. proximity sensor). Furthermore, are there more patches coming for this subsystem? Based on the above tree, it just seems to be a class device (without any standard attributes) and a register/unregister function. It doesn't seem to actually be doing anything. Registering with the als subsystem at the moment buys the driver nothing. So, in its current state, I'm not sure I see what this new common framework actually provides us, and thus I'm not sure that it's actually a step forward. The drivers are still responsible to provide all their own non-standard, incompatible sysfs interfaces for exporting the sensor values. If there are other patches for the als subsys that are then used by the two drivers that got moved into drivers/als, I'd love to take a look at them. Thanks again. --Dima -- 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: Linus Walleij on 3 Mar 2010 05:40 2010/3/3 Dima Zavin <dmitriyz(a)google.com>: > how does this deal with hybrid devices? As any hybrid device, a drivers/mfd spawns multiple sensors, als, accelerometer, voltage level, you name it. > I definitely see the need for what you guys are trying to accomplish. > For example, currently, we use an input device for reporting events, > and a separate misc device node for control > (enable/disable/configure). It's definitely suboptimal, but there > currently isn't anything there would let us do things cleanly. Are you registering your misc node from an mfd device then? > I would love to work with you to design something more generic. You can design forever, people need this now. (But we'd love to see the patches!) It's better to refactor the day something better is in place IMHO. Also I see no real clash. The userspace interface will likely be the same (input subsystem) so what's the problem? In the drivers/staging/iio in the -next tree you can find something more generic for industrial I/O including ADCs, triggers and some sensors. I pointed out sometime last month that this has the problem of exposing only userland interfaces and no kernel-internal interfaces for the actual devices (just sysfs entries), so the current ALS subsystem cannot fit into it, for example. Linus Walleij -- 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 3 Mar 2010 06:10
Hi All, > Jean, > > Thanks for the prompt reply. > >>> I definitely see the need for what you guys are trying to accomplish. >>> For example, currently, we use an input device for reporting events, >>> and a separate misc device node for control >>> (enable/disable/configure). It's definitely suboptimal, but there >>> currently isn't anything there would let us do things cleanly. >>> >>> What I would love to see is a more generic sensors framework that >>> handles different kinds of sensor devices, and different data >>> acquisition schemes (sampled vs. change notifications). >>> >>> I would love to work with you to design something more generic. >> >> This can happen later, I see no reason to block the creation of the ALS >> subsystem. Having a common framework for all ambient light sensor >> drivers will already be a step forward compared to the current > > Following the logic of putting the ALS subsystem under drivers/als, we > would then put the proximity subsystem under drivers/proximity, and > then an accelerometer subsystem under drivers/accelerometer, etc. > Each > with their own implementation of very similar set of interfaces. Is > that what you envision? I just figured that instead of creating > one-off interfaces for some subset of environmental sensors such as > als, we can add a sensors subsystem of which als is just an instance. > >> situation. If improvements are needed on top of this, this can happen >> later. > > I'm just concerned that instead of solving the actual problem, you are > adding what is essentially a temporary solution. This will only make > it harder to solve the real issue by introducing new interfaces which > will need to be obsoleted unless they are designed with care. What you > are proposing already needs improvements since there are plenty of > drivers floating out there from many OEMs/vendors that are not ALSs, > but essentially need a similar interface (e.g. proximity sensor). Actually, the reason we hived off ambient light sensors into their own subsystem was mainly that they typically have extremely simple interfaces and run at rather low rates. I'm personally extremely interested in how to support other forms of sensor. That is what my primary work at the moment on the IIO subsystem in staging is directed towards. Initially we did have light sensors within there (and there is one left at the moment). However, having said that, we concluded that IIO was massive overkill for this particular form of sensor. The typical read rate for these is a couple of Hz. IIO is intended to handle the much more sophisticated devices and right now its still a fair way from being ready for an attempt at merging with the mainline kernel. It is getting plenty of new drivers, but the core still needs some work. Basically the usual argument of do things the simple way if you can came to the fore here. There was little if any overlap with functionality or interface with other sensor types in IIO so it didn't really make sense to have them there. Note there are many other complexities in how to handle the other sensors you mention. If you have a chance to take a look at the current form of IIO (and perhaps follow the discussions on linux-iio(a)vger.kernel.org) we would appreciate any comments on how we are going about it. > > Furthermore, are there more patches coming for this subsystem? Based > on the above tree, it just seems to be a class device (without any > standard attributes) and a register/unregister function. It doesn't > seem to actually be doing anything. Registering with the als subsystem > at the moment buys the driver nothing. So, in its current state, I'm > not sure I see what this new common framework actually provides us, > and thus I'm not sure that it's actually a step forward. The drivers > are still responsible to provide all their own non-standard, > incompatible sysfs interfaces for exporting the sensor values. No the aren't. The sysfs interface specification is exactly the reason this subsystem exists. We could have taken the heavy weight route and done everything via callbacks etc to try and enforce naming, but instead went with the one that has been very successful for hwmon, that of a formal specification and driver review to ensure that all devices are compatible. In a sense, this subsystem is merely providing an alternative to hwmon for these devices seeing as they do not fall within the scope of hardware monitoring. > If > there are other patches for the als subsys that are then used by the > two drivers that got moved into drivers/als, I'd love to take a look > at them. The subsystem is deliberately kept simple, but there are patches for ACPI that add a further driver and a plan to move the tls2563 driver from IIO to als. Note that some of these may involve extending the sysfs specification as appropriate to provide new functionality. 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/ |