Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/