[linux-sunxi] Re: [lm-sensors] [PATCH 2/5] input: sun4i-ts: Add support for temperature sensor
Hans de Goede
hdegoede at redhat.com
Wed Dec 25 05:54:27 EST 2013
On 12/25/2013 11:37 AM, Guenter Roeck wrote:
> On Tue, Dec 24, 2013 at 11:24:04PM +0100, Hans de Goede wrote:
>> The sun4i resisitive touchscreen controller also comes with a built-in
>> temperature sensor. This commit adds support for it.
>>
>> This commit also introduces a new "ts-attached" device-tree attribute,
>> when this is not set, the input part of the driver won't register. This way
>> the internal temperature sensor can be used to measure the SoC temperature
>> independent of there actually being a touchscreen attached to the controller.
>>
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>
> Hi Hans,
Hi,
Merry Christmas and thanks for the review.
>
> can you use the new hwmon_device_register_with_groups API instead,
> or even devm_hwmon_device_register_with_groups ?
Its been a while since I last did a hwmon driver, so I did not know about
those, I'm a great fan of devm* so I'll use that one in my next revision.
>
> This way you don't have to create and remove the sysfs group, you don't have to
> create the name attribute, and if you use the devm_ API you don't have to remove
> anything. Also, the hwmon attributes will be attached to the hwmon device,
> meaning the platform device won't be cluttered with hwmon attributes and
> vice versa.
>
> Couple of related comments inline below.
>
> Thanks,
> Guenter
>
>> ---
>> drivers/input/touchscreen/sun4i-ts.c | 106 +++++++++++++++++++++++++++++++++--
>> 1 file changed, 102 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c
>> index b3f01c0..15a486d 100644
>> --- a/drivers/input/touchscreen/sun4i-ts.c
>> +++ b/drivers/input/touchscreen/sun4i-ts.c
>> @@ -3,6 +3,9 @@
>> *
>> * Copyright (C) 2013 - 2014 Hans de Goede <hdegoede at redhat.com>
>> *
>> + * The hwmon parts are based on work by Corentin LABBE which is:
>> + * Copyright (C) 2013 Corentin LABBE <clabbe.montjoie at gmail.com>
>> + *
>> * This program is free software; you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License as published by
>> * the Free Software Foundation; either version 2 of the License, or
>> @@ -31,6 +34,7 @@
>>
>> #include <linux/delay.h>
>> #include <linux/err.h>
>> +#include <linux/hwmon.h>
>> #include <linux/init.h>
>> #include <linux/input.h>
>> #include <linux/interrupt.h>
>> @@ -97,10 +101,16 @@
>> #define TP_UP_PENDING (1 << 1)
>> #define TP_DOWN_PENDING (1 << 0)
>>
>> +/* TP_TPR bits */
>> +#define TEMP_ENABLE(x) ((x) << 16)
>> +#define TEMP_PERIOD(x) ((x) << 0) /* t = x * 256 * 16 / clkin */
>> +
>> struct sun4i_ts_data {
>> struct device *dev;
>> void __iomem *base;
>> struct input_dev *input;
>> + struct device *hwmon;
>> + atomic_t temp_data;
>
> Unless I am missing something, this variable does not have to be an atomic.
> Either it was written or it wasn't, but the order should not matter.
That is true, but it does assume that 32 bit int accesses are atomic, in the
sense that we can never have a case where one core has only written ie the
lower 8 bits when the other reads the variable. I believe that is the
case on ARM (the only architecture relevant here), but rather safe then
sorry. So I plan to keep this as is until someone, who knows more about
these things then me, tells me it is safe to turn it into a regular int.
>
>> int ignore_fifo_data;
>> };
>>
>> @@ -111,6 +121,12 @@ static irqreturn_t sun4i_ts_irq(int irq, void *dev_id)
>>
>> reg_val = readl(ts->base + TP_INT_FIFOS);
>>
>> + if (reg_val & TEMP_DATA_PENDING)
>> + atomic_set(&ts->temp_data, readl(ts->base + TEMP_DATA));
>> +
>> + if (!ts->input)
>> + goto leave;
>> +
>> if (reg_val & FIFO_DATA_PENDING) {
>> x = readl(ts->base + TP_DATA);
>> y = readl(ts->base + TP_DATA);
>> @@ -135,6 +151,7 @@ static irqreturn_t sun4i_ts_irq(int irq, void *dev_id)
>> input_sync(ts->input);
>> }
>>
>> +leave:
>> writel(reg_val, ts->base + TP_INT_FIFOS);
>>
>> return IRQ_HANDLED;
>> @@ -170,6 +187,66 @@ static int sun4i_ts_register_input(struct sun4i_ts_data *ts,
>> return 0;
>> }
>>
>> +static ssize_t show_name(struct device *dev, struct device_attribute *devattr,
>> + char *buf)
>> +{
>> + return sprintf(buf, "sun4i_ts\n");
>> +}
>> +
>> +static ssize_t show_temp(struct device *dev, struct device_attribute *devattr,
>> + char *buf)
>> +{
>> + struct sun4i_ts_data *ts = dev_get_drvdata(dev);
>> + int temp_data;
>> +
>> + temp_data = atomic_read(&ts->temp_data);
>> + /* No temp_data until the first irq */
>> + if (temp_data == -1)
>> + return -EAGAIN;
>> +
>> + return sprintf(buf, "%d\n", (temp_data - 1447) * 100);
>> +}
>> +
>> +static ssize_t show_temp_label(struct device *dev,
>> + struct device_attribute *devattr, char *buf)
>> +{
>> + return sprintf(buf, "SoC temperature\n");
>> +}
>> +
>> +static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
>> +static DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL);
>> +static DEVICE_ATTR(temp1_label, S_IRUGO, show_temp_label, NULL);
>> +
>> +static struct attribute *sun4i_ts_attributes[] = {
>> + &dev_attr_name.attr,
>> + &dev_attr_temp1_input.attr,
>> + &dev_attr_temp1_label.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group sun4i_ts_attr_group = {
>> + .attrs = sun4i_ts_attributes,
>> +};
>
> If you rename the attributes to sun4i_ts_attrs, you should be able to use
> ATTRIBUTE_GROUPS() here (this gives you a list of groups which you'll need
> if you use the new API).
Ok, sounds good.
>
>> +
>> +static int sun4i_ts_register_hwmon(struct sun4i_ts_data *ts)
>> +{
>> + int ret;
>> +
>> + atomic_set(&ts->temp_data, -1);
>> +
>> + ret = sysfs_create_group(&ts->dev->kobj, &sun4i_ts_attr_group);
>> + if (ret)
>> + return ret;
>> +
>> + ts->hwmon = hwmon_device_register(ts->dev);
>> + if (IS_ERR(ts->hwmon)) {
>> + ret = PTR_ERR(ts->hwmon);
>> + ts->hwmon = NULL;
>> + }
>> +
>> + return ret;
>
> With the new API, this would be something like
>
> hwmon_dev = devm_hwmon_device_register_with_groups(ts->dev, "sun4i_ts",
> ts, sun4i_ts_attrs);
> return PTR_ERR_OR_ZERO(hwmon_dev);
>
> With the devm_ API, you don't have to store the hwmon device as you don't need
> to access it anymore from within the driver. Note that you can only use it if
> you also use devm_kzalloc to allocate ts; otherwise you would have a race condition
> during cleanup.
Sounds good again, I'll do a v2 with these changes one of the coming days.
>> +}
>> +
>> static int sun4i_ts_remove(struct platform_device *pdev)
>> {
>> struct sun4i_ts_data *ts = platform_get_drvdata(pdev);
>> @@ -178,9 +255,13 @@ static int sun4i_ts_remove(struct platform_device *pdev)
>> writel(0, ts->base + TP_INT_FIFOC);
>> msleep(20);
>>
>> + if (ts->hwmon)
>> + hwmon_device_unregister(ts->hwmon);
>> +
>> if (ts->input)
>> input_unregister_device(ts->input);
>>
>> + sysfs_remove_group(&ts->dev->kobj, &sun4i_ts_attr_group);
>> kfree(ts);
>>
>> return 0;
>> @@ -189,7 +270,11 @@ static int sun4i_ts_remove(struct platform_device *pdev)
>> static int sun4i_ts_probe(struct platform_device *pdev)
>> {
>> struct sun4i_ts_data *ts;
>> + struct device_node *np = pdev->dev.of_node;
>> int ret = -ENOMEM;
>> + u32 ts_attached = 0;
>> +
>> + of_property_read_u32(np, "ts-attached", &ts_attached);
>>
>> ts = kzalloc(sizeof(struct sun4i_ts_data), GFP_KERNEL);
>
> Different patch, but why not just use devm_kzalloc() ? Since you are using devm_
> functions elsewhere, that would seem natural. I'll also comment on that in the
> other patch.
I did not use devm_kzalloc simply because I did not knew about it until now :)
Using it sounds like an excellent idea so I'll do that.
<snip>
Regards,
Hans
More information about the linux-arm-kernel
mailing list