[lkml]   [2006]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Generic battery interface

    > >Here's one approach: use a syscall (e.g., ioctl) saying "block until
    > >there's new data on this fd, or N milliseconds have passed, whichever
    > >is *later*". This way each client declares the update rate it wants
    > >and can change it on the fly. The driver sees all the requests and can
    > >perform the minimum hardware quering -- for example, it won't query
    > >the hardware at all if no client has submitted a request with
    > >parameter N more than N milliseconds go. And there's no excessive work
    > >or interrupts. Some (simple) kernel code infrastructure is needed to
    > >help drivers manage the pending requests.
    > Here's a rough sketch for the userspace side of a continuous function
    > sampling interface. It handles the blocking a bit better than the
    > above proposal, in that it lets you easily handle multiple readouts.
    > It's agnostic about /dev vs. /sys.

    Looks good to me.

    > I'm not getting into the kernel side for now; it's doable, and with
    > proper infrastructure (e.g., at the sysfs level) can be elegant and
    > efficient.

    I guess that hwmon people would like this, anyway...

    Are there any plans at merging tp_smapi, BTW? After fixing few minor
    details (like removing " mV" from files)... it looks like it would fit
    into hwmon infrastructure rather nicely.
    (cesky, pictures)
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-07-30 12:09    [W:0.022 / U:96.304 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site