lkml.org 
[lkml]   [2011]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values.
    On 11/17/2011 08:22 AM, MyungJoo Ham wrote:
    > On Tue, Nov 15, 2011 at 1:39 AM, Jonathan Cameron <jic23@cam.ac.uk> wrote:
    >> On 11/14/2011 01:31 AM, MyungJoo Ham wrote:
    >>> On Sat, Nov 12, 2011 at 5:46 AM, Ben Hutchings
    >>> <bhutchings@solarflare.com> wrote:
    >>>> On Fri, 2011-11-04 at 15:50 +0900, MyungJoo Ham wrote:
    >>>>> We have been reading hwmon values (TMU, the SoC-core temperature sensor,
    >>>>> and NTC, the ambient or battery surface temperature sensor) for
    >>>>> Charger-Manager. However, because hwmon does not have in-kernel interface,
    >>>>> we have been using undesired method, including "../../../fs/*.h".
    >>>>>
    >>>>> This patch is to provide in-kernel interface for hwmon:
    >>>>> hwmon_get_value and hwmon_set_value. In order to use these two functions,
    >>>>> the hwmon driver should provide its sysfs attributes to hwmon framework
    >>>>> as well. If the hwmon driver does not provide (by providing NULL), the users
    >>>>> of the hwmon won't be able to use hwmon_get/set_value();
    >>>>> The sysfs attribute (struct attribuyte_group *) is provided with
    >>>>> hwmon_device_register; adding the second parameter to hwmon_device_register().
    >>>>> The 2/2 patch shows the changes in device drivers due to this.
    >>>> [...]
    >>>>
    >>>> This is an improvement, but I don't think it is quite enough. As I
    >>>> understand the hwmon sysfs interface, all sensor values should be
    >>>> integers. So the in-kernel interface should also work with integers,
    >>>> not strings.
    >>>>
    >>>> As a first implementation you could perhaps parse the strings back to
    >>>> integers. However in the longer term the driver API should be changed
    >>>> so that hwmon drivers fully describe their sensors to the core and the
    >>>> core takes care of exposing them through sysfs and the in-kernel API.
    >>>
    >>> I agree.
    >>>
    >>> I'll let it the in-kernel interfaces provide integer value although it will
    >>> simply parse strings as you've addressed until we have some other
    >>> interfaces for sysfs entries in hwmon device drivers.
    >>>
    >>>
    >> To throw another option into the mix, you could make it an IIO driver
    >> and sit hwmon on top of that (there is already a simple driver for
    >> doing this) - IIO has in kernel interfaces of the type
    >> you want. Not everything is there yet though.
    >>
    >> Jonathan
    >
    > Yes, we may alter the HWMON drivers to be IIO drivers as well.
    >
    > However, to me, at least for the HWMON devices I've been looking, IIO
    > seems to be an overkill and more complex than needed for the target
    > devices.
    It should (at least in theory) be very simple for anything like a simple
    hwmon device on which one wants to do polled reads.

    All you do is allocate an iio_dev, set up the channel descriptions,
    register it with the core. Then a map is used to match supplied
    channels to their consumers in kernel.

    There is a simple hwmon driver that then takes one of these maps if
    you want conventional hwmon interfaces. Other interested drivers can
    have their own maps.

    Anyhow, IIO is complex for some devices, but pretty simple for simple
    things (at least it should be!)

    Jonathan


    \
     
     \ /
      Last update: 2011-11-17 21:43    [W:2.383 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site