lkml.org 
[lkml]   [2009]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: Light sensors, unifying current options?
    Pavel Machek wrote:
    > Hi!
    >
    >>> Perhaps we might do it via sysfs naming instead.
    >>>
    >>> illuminance[n] - defined to be visible (which is what term means anyway)
    >>>
    >>> infrared[n] - hmm.. will be in different units to illuminance - perhaps we leave
    >>> these raw with suitable documentation?
    >>>
    >>> illuminance_and_infrared[n]
    >>>
    >> what's the unit of this?
    >> what does the value of this file mean?
    >> I think we should make sure that there are more sensors need this and
    >> the same "visible + infrared" reading on different sensors stands for
    >> the same ambient light environment.
    >
    > Are you sure that makes sense? And is that even possible? I'd be
    > afraid that the sensors are not nearly accurate enough to give precise
    > values, and each sensor is going to take different parts of spectrum,
    > etc.
    >
    > Yes, we should aim at having similar interface with similar values on
    > all the sensors, but lets not overdo it.
    Agreed, if we match on the illuminance, pretty much everything else can
    initially be chip dependent as long as they are sufficiently documented.
    If certain things keep repeating then they can be standardized as and when
    this occurs.

    >> But maybe there are some other sensors that don't have this asynchronous
    >> notification so that the cached values don't have a chance to get
    >> updated.
    >> then we need to read the sensor every time the sysfs I/F is poked.
    >
    > I bet most sensors are like that. And no, we don't have to reread from
    > hw every time, we can just read and cache it once per second or
    > something.
    The ones I've seen in embedded devices tend to have some sort of interrupt
    system, but it's reasonably complicated to configure as you have to read the
    sensor then write threshold values back to get the same sort of notifications
    as acpi is doing. Also, it's far from unusual for people not to bother connecting
    the interrupt pin up in the first place so we can't have those drivers relying on its
    presence.

    I think we are getting to the point where the easiest way to work out further
    issues is going to be in code as drivers get converted to the new subsystem.
    I'm happy to do the two tsl drivers once the core as discussed in this thread
    is in place.

    Jonathan


    \
     
     \ /
      Last update: 2009-09-10 12:13    [W:2.275 / U:0.316 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site