On Sep 2 2010, Manuel Stahl wrote:
Am 02.09.2010 00:52, schrieb Rhyland Klein:
I am looking into submitting a sensor driver for the isl29018 ambient
light sensor (als). I noticed there is an old isl als driver for a
different part (isl29003) in drivers/misc but I also see the light
sensor driver for tsl2653 in the drivers/staging/iio/light directory
which seems much more like the correct place for this type of sensor
driver to reside.
Is this subsystem designed for ALS drivers or a different type of
light sensor?
It's designed for all kind of sensors. Of course not all are supported
properly yet.
If it should support ALS drivers, I don't know how the
IIO_DEV* attributes should map for this. I suppose it would just use
the IIO_DEV_ATTR_LIGHT_VISIBLE for the lux, which could work, except
that the isl29018 also functions as a proximity sensor, and the
driver will support both modes. What is the proper way to fit a
driver like this into the iio subsystem?
> One thing to note is that there are additional properties other than
> just reporting the lux that will need to be supported including
> changing the mode and setting the range, and I am not sure how these
> should fit into the device attribute framework exposed via light.h.
When you have attributes that fit into the current scheme, use these.
When you have additional attributes that might be useful for other
sensors, make a name proposal.
When you have attributes, like mode, that are device specific, use
IIO_DEVICE_ATTR(_name, _mode, _show, _store, _addr) and put in a proper
name.
Best bet is propose as an RFC the attributes you want to provide with a
clear description of the format etc. Do this before submitting the code as
that'll save everyone time ;)
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html