lkml.org 
[lkml]   [2013]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [RESEND PATCH V1 8/9] hwmon: lm75: expose to thermal fw via DT nodes
    On 07/18/2013 09:12 PM, Eduardo Valentin wrote:
    > * PGP Signed: 07/18/2013 at 06:12:01 AM
    >
    > Hi Wei,
    >
    >
    > On 18-07-2013 01:33, Wei Ni wrote:
    >> On 07/17/2013 11:17 PM, Eduardo Valentin wrote:
    >>> This patch adds to lm75 temperature sensor the possibility
    >>> to expose itself as thermal zone device, registered on the
    >>> thermal framework.
    >>>
    >>> The thermal zone is built only if a device tree node
    >>> describing a thermal zone for this sensor is present
    >>> inside the lm75 DT node. Otherwise, the driver behavior
    >>> will be the same.
    >>>
    >>> Cc: Jean Delvare <khali@linux-fr.org>
    >>> Cc: Guenter Roeck <linux@roeck-us.net>
    >>> Cc: lm-sensors@lm-sensors.org
    >>> Cc: linux-kernel@vger.kernel.org
    >>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
    >>> ---
    >>> drivers/hwmon/lm75.c | 29 +++++++++++++++++++++++++++++
    >>> 1 file changed, 29 insertions(+)
    >>>
    >>> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
    >>> index c03b490..0aa5e28 100644
    >>> --- a/drivers/hwmon/lm75.c
    >>> +++ b/drivers/hwmon/lm75.c
    >>> @@ -27,6 +27,8 @@
    >>> #include <linux/hwmon-sysfs.h>
    >>> #include <linux/err.h>
    >>> #include <linux/mutex.h>
    >>> +#include <linux/thermal.h>
    >>> +#include <linux/of.h>
    >>> #include "lm75.h"
    >>>
    >>>
    >>> @@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
    >>> /* Each client has this additional data */
    >>> struct lm75_data {
    >>> struct device *hwmon_dev;
    >>> + struct thermal_zone_device *tz;
    >>> struct mutex update_lock;
    >>> u8 orig_conf;
    >>> u8 resolution; /* In bits, between 9 and 12 */
    >>> @@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device *dev);
    >>>
    >>> /* sysfs attributes for hwmon */
    >>>
    >>> +static int lm75_read_temp(void *dev, unsigned long *temp)
    >>> +{
    >>> + struct lm75_data *data = lm75_update_device(dev);
    >>> +
    >>> + if (IS_ERR(data))
    >>> + return PTR_ERR(data);
    >>> +
    >>> + *temp = ((data->temp[0] >> (16 - data->resolution)) * 1000) >>
    >>> + (data->resolution - 8);
    >>> +
    >>> + return 0;
    >>> +}
    >>> +
    >>> static ssize_t show_temp(struct device *dev, struct device_attribute *da,
    >>> char *buf)
    >>> {
    >>> @@ -271,11 +287,23 @@ lm75_probe(struct i2c_client *client, const struct i2c_device_id *id)
    >>> goto exit_remove;
    >>> }
    >>>
    >>> + if (of_find_node_by_name(client->dev.of_node, "thermal_zone")) {
    >>> + data->tz = thermal_zone_of_device_register(&client->dev,
    >>> + &client->dev,
    >>> + lm75_read_temp);
    >>
    >> Hi, Eduardo
    >> I have two questions:
    >> 1. As we know, after register to the thermal framework, it will have
    >> duplicate hwmon devices. I think lm-sensor maintainer would not like this.
    >
    > Yes I noticed. You have always the option to disable the
    > CONFIG_THERMAL_HWMON in your build.

    Yes, we can disable this config, but it will disable all hwmon interface
    which registered by the thermal fw, it may affect other driver.

    >
    >> How about to add a flag to indicate it, which I talk about with
    >> Durgadoss in your [RFC 1/4]patch.
    >
    > This would be very much appreciated, but I don't think this is a blocker
    > for this series. We can of course include this patch on it. Having a
    > flag to control this thermal fw to hwmon interface is actually a good idea.

    Ok, I think I can post it as a separate patches.

    >
    >>
    >> 2. I'm also trying to use your codes on lm90. The LM90 serial has more
    >> then one sensors in one chip, local sensor, remote sensor and may have
    >> remote2 sensor, so it mean there may have more than one thermal_zone
    >> under the lm90 device node, will you consider it?
    >>
    >
    > I haven't looked lm90 source code. How do you map it? Do you probe each
    > sensor or do you probe 1 device and expose 3 sensors?

    lm90.c is the driver for all LM90 register compatible chips, it probe 1
    device, and normally it can expose local and remote sensor, and for
    max669x chip, it also expose remote2 sensor.

    >
    > In first case, you can still reuse what is in this series.
    >
    > Later case, we need to change it slightly.
    >
    > That is the case which is pretty similar on OMAP5 for instance, where
    > the device has three sensors. This patch series does not cover for this
    > case. But it can be simply modified to get around it.
    >
    > We would need to allow more than one 'thermal_zone' nodes inside a
    > single device. But then we would need to have a way to determine which
    > sensor goes to which zone too.

    Yes, agreed, we need a way to determine it.
    I have tentative suggestions, how about following:
    lm90 {
    ...
    thermal_zone@0 {
    type = "local_sensor";
    ...
    }
    thermal_zone@1 {
    type = "remote_sensor";
    }
    }
    And in the driver's probe routine, we can parse the thermal_zone node,
    and pass it to thermal_zone_of_device_register() with the right .get_temp().

    Wei.

    >
    >
    >> Thanks.
    >> Wei.
    >>
    >>> + if (IS_ERR(data->tz)) {
    >>> + status = PTR_ERR(data->tz);
    >>> + goto exit_hwmon;
    >>> + }
    >>> + }
    >>> +
    >>> dev_info(&client->dev, "%s: sensor '%s'\n",
    >>> dev_name(data->hwmon_dev), client->name);
    >>>
    >>> return 0;
    >>>
    >>> +exit_hwmon:
    >>> + hwmon_device_unregister(data->hwmon_dev);
    >>> exit_remove:
    >>> sysfs_remove_group(&client->dev.kobj, &lm75_group);
    >>> return status;
    >>> @@ -285,6 +313,7 @@ static int lm75_remove(struct i2c_client *client)
    >>> {
    >>> struct lm75_data *data = i2c_get_clientdata(client);
    >>>
    >>> + thermal_zone_device_unregister(data->tz);
    >>> hwmon_device_unregister(data->hwmon_dev);
    >>> sysfs_remove_group(&client->dev.kobj, &lm75_group);
    >>> lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
    >>>
    >>
    >>
    >>
    >
    >



    \
     
     \ /
      Last update: 2013-07-19 10:21    [W:4.123 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site