lkml.org 
[lkml]   [2010]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] Ambient Light Sensors subsystem
From
On Wed, Mar 3, 2010 at 11:45 PM, Jonathan Cameron
<kernel@jic23.retrosnub.co.uk> wrote:
> Hi Manu,
>
> ...
>> Maybe it make sense to put all Generic sensors into one whole lot,
>> where an application can
>>
>> - read the value from the driver (eg: 0 - 65535)
>>
>> - read from device static information (to identify how the application
>> should treat the values read back.)
>>
>>    - report what type of device it is (Light, Voltage, Acceleration
>> and what not, simple enumeration will help, mayeb you can even have
>> bitwise OR the types, so that you can have a driver with multiple
>> capabilities)
>>    - the max value it can go
>>    - the min value it can go
>>    - the number of steps (gradient) that the driver can do.
>>
>>
>> Maybe such a simplistic interface does help ?
>>
>> The application can simply read the static information from the driver
>> and decide whether it should really handle that driver class.
>
> The more generic sensors are covered by IIO (in staging)
> There is a lot more there as well as an equivalent of what you describe.
>
> The simplest equivalent to this is the hwmon subsystem (from which IIO
> has borrowed a lot of interfaces, as has ALS).
>
> You have a sysfs file per channel, so taking als api as an example:
>
> illuminance0 - Value of illuminance in lux.
>
> If you want your other elements (though no driver provides them at the moment).
>
> illuminance0_max
> illuminance0_min
> illuminance0_values


Just as i thought:

A Class with values to define floor and ceiling and the gradient in
which the driver can provide such an information in a generic way,
rather than limiting to Ambient Light Sensor.

to make it a bit more stylistic, you could provide static information,
such as driver name also alongwith. But in any case, i guess you
wouldn't need more than these

device_name
max_val
min_val
gradient/steps


as static information and a simple value that could be read back.


In (some remote thought) addition, some devices could "possibly" have
levels that you could set the levels at which the device could set of
a trigger, in which case, you might want to write to the driver to set
the value at which you want to trigger of some event. (Don't really
know whether this is applicable, but I have seen it in some
temperature sensors, such a feature)


> For slow devices this is all you need.
> If you are interested in fast devices, take a look at the recently posted IIO ABI spec.
> That uses sysfs files to describe the data that can be read from a character device
> that is fed from a buffer (either hardware or software). It also supports fairly
> advanced event handling (similar to input, but without cross device aggregation)
> and triggering of data capture from various 'interrupt' sources.
>
> It is still somewhat unclear how exactly to marry the high speed data acquisition
> requirements with other 'client' subsystems such as input. All suggestions on that
> are welcome!

I don't know how fast is "fast".

"I think", (based on quick thought) all you might need is a trigger,
whether the userspace application needs to be triggered to read the
value from the driver, or do something exotic.

ie the trigger is a binary only event, as I understand, right ? But in
any case, you define the trigger mechanism in any way, similar to an
interrupt

The data to be read back could be just as generic, in any case, rather
than defining a subsystem per device category..

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

\
 
 \ /
  Last update: 2010-03-03 21:11    [W:0.061 / U:1.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site