[PATCH][RFC] Add standalone driver for the A20 Soc TP embedded temperature sensor

[LABBE Corentin]

Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
---
This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.

For the temperature value, I cannot found any document on how to transform the raw value in °C.
Since the A20 and AXP209 chips are both produced by allwinner and in both case the hardware sensor is a 12 bit ADC,
I have made the assumptions that the conversions rules are the same.
With this conversions the temperature gived seems realistic.
Under heavy loads, the temperature of both sensors rise linearly.

drivers/hwmon/Kconfig | 9 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/a20-tp.c | 271 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 281 insertions(+)
create mode 100644 drivers/hwmon/a20-tp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 97f82e1..c9ff596 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -48,6 +48,15 @@ config SENSORS_MMA7660
If you say yes here you get support for the Freescale 3-Axis
Orientation/Motion Detection Sensor.

+config SENSORS_A20_TP_HWMON
+ tristate "A20 SoC TP sensor controller"
+ depends on !TOUCHSCREEN_SUN4I_TS
+ help
+ If you say yes here you get support for the hardware monitoring
+ sensor present in the touch screen controler present on A20 SoC.
+ This driver handle only this, if you want the full usage of the TP
+ you need the other driver named sun4i-ts.
+
config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on X86 && DMI && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index a106b4c..68cef1b 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -132,3 +132,4 @@ obj-$(CONFIG_PMBUS) += pmbus/

ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG

+obj-$(CONFIG_SENSORS_A20_TP_HWMON) += a20-tp.o
diff --git a/drivers/hwmon/a20-tp.c b/drivers/hwmon/a20-tp.c
new file mode 100644
index 0000000..78c2f08
--- /dev/null
+++ b/drivers/hwmon/a20-tp.c
@@ -0,0 +1,271 @@
+/*
+ * a20-tp.c - A20 SoC Resistive Touch Panel (RTP) embedded sensor driver only
+ *
+ * Copyright (C) 2013 Corentin LABBE <clabbe....@gmail.com>
+ *
+ * Datasheet: http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
+ *
+ * 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 version 2 of the License
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/hwmon-sysfs.h>
+#include <linux/hwmon.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <asm/irq.h>
+#include <linux/io.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <mach/irqs.h>
+#include <mach/system.h>
+#include <mach/hardware.h>
+
+#define IRQ_TP 29
+#define TP_BASSADDRESS 0xf1c25000
+#define TP_CTRL0 0x00
+#define TP_CTRL1 0x04
+#define TP_CTRL2 0x08
+#define TP_CTRL3 0x0c
+#define TP_INT_FIFOC 0x10
+#define TP_INT_FIFOS 0x14
+#define TP_TPR 0x18
+#define TP_CDAT 0x1c
+#define TEMP_DATA 0x20
+#define TP_DATA 0x24
+
+#define ADC_CLK_DIVIDER (0x2<<20)
+#define CLK 7
+#define FS_DIV (CLK<<16)
+#define ACQ 0x3f
+#define T_ACQ ACQ
+
+#define TP_CTRL_MODE_EN (1<<4)
+
+#define TP_DATA_IRQ_EN (1<<16)
+#define TP_FIFO_FLUSH (1<<4)
+#define TP_TEMP_IRQ_EN (1<<18)
+#define TP_TEMP_IRQ_PENDING (1<<18)
+
+#define FIFO_DATA_PENDING (1<<16)
+#define TP_UP_PENDING (1<<1)
+#define TP_DOWN_PENDING (1<<0)
+
+#define TP_TPR_TEMP_ENABLE (1<<16)
+#define TP_TPR_TEMP_PERIOD 0x0fff
+
+#define TP_TEMP_NODATA -666
+
+struct tp_data {
+ struct resource *res;
+ void __iomem *base_addr;
+ int irq;
+ s16 temperature;
+ struct device *hwmon_dev;
+};
+
+/* Since we need to wait for an irq to have the temperature, we cannot give
+ * temperature for a short period of time.
+ * So until we have a temperature we return -EAGAIN */
+static ssize_t
+show_temp(struct device *dev, struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct tp_data *data = dev_get_drvdata(dev);
+ if (attr->index == 1)
+ return sprintf(buf, "264800\n");
+ if (attr->index == 2)
+ return sprintf(buf, "-144700\n");
+ if (attr->index == 3)
+ return sprintf(buf, "a20_tp\n");
+ if (data->temperature == TP_TEMP_NODATA)
+ return -EAGAIN;
+ return sprintf(buf, "%d\n", data->temperature * 100);
+}
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
+static SENSOR_DEVICE_ATTR(name, S_IRUGO, show_temp, NULL, 3);
+
+static struct attribute *tp_attributes[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ &sensor_dev_attr_temp1_min.dev_attr.attr,
+ &sensor_dev_attr_temp1_max.dev_attr.attr,
+ &sensor_dev_attr_name.dev_attr.attr,
+ NULL
+};
+
+static const struct attribute_group tp_group = {
+ .attrs = tp_attributes,
+};
+
+static irqreturn_t tp_handle_irq(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct tp_data *ts_data = (struct tp_data *)platform_get_drvdata(pdev);
+ unsigned int reg_val;
+
+ reg_val = readl(TP_BASSADDRESS + TP_INT_FIFOS);
+ if (!(reg_val & (TP_DOWN_PENDING | FIFO_DATA_PENDING | TP_UP_PENDING))) {
+ if (reg_val & TP_TEMP_IRQ_PENDING) {
+ writel(reg_val & TP_TEMP_IRQ_PENDING, TP_BASSADDRESS + TP_INT_FIFOS);
+
+ reg_val = readl(TP_BASSADDRESS + TEMP_DATA);
+ reg_val &= 0x00000FFF;/* 12 bit wide */
+ ts_data->temperature = reg_val - 1447;
+ return IRQ_HANDLED;
+ }
+ return IRQ_NONE;
+ }
+ writel(reg_val, TP_BASSADDRESS + TP_INT_FIFOS);
+ return IRQ_HANDLED;
+}
+
+static int __devinit a20_tp_hwmon_probe(struct platform_device *pdev)
+{
+ int err = 0;
+ int irq = platform_get_irq(pdev, 0);
+ struct tp_data *ts_data;
+
+ ts_data = kzalloc(sizeof(struct tp_data), GFP_KERNEL);
+ if (!ts_data) {
+ dev_err(&pdev->dev, "Cannot allocate driver structures\n");
+ err = -ENOMEM;
+ return err;
+ }
+
+ ts_data->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!ts_data->res) {
+ err = -ENOMEM;
+ dev_err(&pdev->dev, "Cannot get the MEMORY\n");
+ goto label_err1;
+ }
+
+ ts_data->base_addr = (void __iomem *)TP_BASSADDRESS;
+
+ ts_data->irq = irq;
+
+ err = request_irq(irq, tp_handle_irq,
+ IRQF_DISABLED, pdev->name, pdev);
+ if (err) {
+ dev_err(&pdev->dev, "Cannot request keypad IRQ\n");
+ goto label_err1;
+ }
+
+ platform_set_drvdata(pdev, ts_data);
+
+ ts_data->temperature = TP_TEMP_NODATA;
+
+ writel(ADC_CLK_DIVIDER | FS_DIV | T_ACQ, TP_BASSADDRESS + TP_CTRL0);
+
+ /* Enable the temperature IRQ */
+ writel(TP_TEMP_IRQ_EN, TP_BASSADDRESS + TP_INT_FIFOC);
+
+ /* Enable the temperature */
+ writel(TP_TPR_TEMP_ENABLE | TP_TPR_TEMP_PERIOD, TP_BASSADDRESS + TP_TPR);
+
+ /* Enable TP */
+ writel(TP_CTRL_MODE_EN, TP_BASSADDRESS + TP_CTRL1);
+
+ err = sysfs_create_group(&pdev->dev.kobj, &tp_group);
+ if (err) {
+ dev_err(&pdev->dev, "Cannot create sysfs group\n");
+ goto label_err2;
+ }
+
+ ts_data->hwmon_dev = hwmon_device_register(&pdev->dev);
+ if (IS_ERR(ts_data->hwmon_dev)) {
+ err = PTR_ERR(ts_data->hwmon_dev);
+ goto label_err3;
+ }
+ dev_info(&pdev->dev, "TP initialization success\n");
+ return 0;
+label_err3:
+ sysfs_remove_group(&pdev->dev.kobj, &tp_group);
+label_err2:
+ free_irq(ts_data->irq, pdev);
+label_err1:
+ kfree(ts_data);
+ return err;
+}
+
+static int __devexit a20_tp_hwmon_remove(struct platform_device *pdev)
+{
+ struct tp_data *ts_data = platform_get_drvdata(pdev);
+
+ /* desactivate all IRQ */
+ writel(0, ts_data->base_addr + TP_INT_FIFOC);
+
+ hwmon_device_unregister(ts_data->hwmon_dev);
+ sysfs_remove_group(&pdev->dev.kobj, &tp_group);
+
+ free_irq(ts_data->irq, pdev);
+ kfree(ts_data);
+ platform_set_drvdata(pdev, NULL);
+ return 0;
+}
+
+static struct platform_driver a20_tp_hwmon_driver = {
+ .probe = a20_tp_hwmon_probe,
+ .remove = __devexit_p(a20_tp_hwmon_remove),
+ .driver = {
+ .name = "a20-tp-hwmon",
+ },
+};
+
+static struct resource a20_tp_hwmon_resource[] = {
+ {
+ .flags = IORESOURCE_IRQ,
+ .start = SW_INT_IRQNO_TOUCH_PANEL ,
+ .end = SW_INT_IRQNO_TOUCH_PANEL ,
+ },
+ {
+ .flags = IORESOURCE_MEM,
+ .start = TP_BASSADDRESS,
+ .end = TP_BASSADDRESS + 0x100-1,
+ },
+};
+
+struct platform_device a20_tp_hwmon_device = {
+ .name = "a20-tp-hwmon",
+ .id = -1,
+ .resource = a20_tp_hwmon_resource,
+ .num_resources = ARRAY_SIZE(a20_tp_hwmon_resource),
+};
+
+static int __init a20_tp_hwmon_init(void)
+{
+ platform_device_register(&a20_tp_hwmon_device);
+ return platform_driver_register(&a20_tp_hwmon_driver);
+}
+
+static void __exit a20_tp_hwmon_exit(void)
+{
+ platform_driver_unregister(&a20_tp_hwmon_driver);
+ platform_device_unregister(&a20_tp_hwmon_device);
+}
+
+module_init(a20_tp_hwmon_init);
+module_exit(a20_tp_hwmon_exit);
+
+MODULE_AUTHOR("Corentin LABBE");
+MODULE_DESCRIPTION("A20 SoC embedded touchscreen hwmon driver");
+MODULE_LICENSE("GPL");
+
--
1.8.1.5

[Hans de Goede]

Hi,

On 10/07/2013 02:01 PM, LABBE Corentin wrote:
>
> Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
> ---
> This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
> Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.

Interesting idea to use the rtp temp sensor as a soc temp sensor and to write a hwmon sensor for
this, I like :)

Note that all of sun4i sun5i and sun7i have the same RTP controller, so you should drop the
a20 from the name and use sunxi instead.

Further comments inline.

This means that if any of these touch screen events are pending, you are skipping
temp processing, why? I would expect the irq handler to always read the temp
if the TP_TEMP_IRQ_PENDING bit is set.

> + if (reg_val & TP_TEMP_IRQ_PENDING) {
> + writel(reg_val & TP_TEMP_IRQ_PENDING, TP_BASSADDRESS + TP_INT_FIFOS);
> +
> + reg_val = readl(TP_BASSADDRESS + TEMP_DATA);
> + reg_val &= 0x00000FFF;/* 12 bit wide */
> + ts_data->temperature = reg_val - 1447;
> + return IRQ_HANDLED;
> + }
> + return IRQ_NONE;
> + }
> + writel(reg_val, TP_BASSADDRESS + TP_INT_FIFOS);
> + return IRQ_HANDLED;

And here you return IRQ_HANDLED, even though you've not handled anything.

It seems that this is mostly directly copied from sun4i-ts.c, but I don't believe
that this is the right way to handle this.

TP_INT_FIFOC will control which TP_INT_FIFOS bits will actually raise an
irq, so there are 2 cases of interest here:

1) Only this new a20-tp.c driver is loaded, in this case only
TP_TEMP_IRQ_PENDING will actually raise an interrupt, and your interrupt handler
only needs to check and clear that flag.

2) Both this new a20-tp.c driver is loaded as well as sun4i-ts in that case
other interrupt sources will be enabled in TP_INT_FIFOC, but sun4i-ts will
handle them, so your interrupt handler still only needs to check and clear
TP_TEMP_IRQ_PENDING.

You should probably add a comment in here that this needs to be in sync
with the code in sun4i-ts in case both of them are loaded at the same time.

> + writel(ADC_CLK_DIVIDER | FS_DIV | T_ACQ, TP_BASSADDRESS + TP_CTRL0);
> +
> + /* Enable the temperature IRQ */
> + writel(TP_TEMP_IRQ_EN, TP_BASSADDRESS + TP_INT_FIFOC);

This is wrong, what if the touchscreen driver itself is also loaded ? You
should read in the original value, then mask in TP_TEMP_IRQ_EN and write
it back.

Regards,

Hans

[Corentin LABBE]

Le 07/10/2013 15:38, Hans de Goede a �crit :

> Hi,
>
> On 10/07/2013 02:01 PM, LABBE Corentin wrote:
>>
>> Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
>> ---
>> This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
>> Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.
>
> Interesting idea to use the rtp temp sensor as a soc temp sensor and to write a hwmon sensor for
> this, I like :)
>
> Note that all of sun4i sun5i and sun7i have the same RTP controller, so you should drop the
> a20 from the name and use sunxi instead.

Ok I will do that.

I will correct that.

>
>> + if (reg_val & TP_TEMP_IRQ_PENDING) {
>> + writel(reg_val & TP_TEMP_IRQ_PENDING, TP_BASSADDRESS + TP_INT_FIFOS);
>> +
>> + reg_val = readl(TP_BASSADDRESS + TEMP_DATA);
>> + reg_val &= 0x00000FFF;/* 12 bit wide */
>> + ts_data->temperature = reg_val - 1447;
>> + return IRQ_HANDLED;
>> + }
>> + return IRQ_NONE;
>> + }
>> + writel(reg_val, TP_BASSADDRESS + TP_INT_FIFOS);
>> + return IRQ_HANDLED;
>
> And here you return IRQ_HANDLED, even though you've not handled anything.
>
> It seems that this is mostly directly copied from sun4i-ts.c, but I don't believe
> that this is the right way to handle this.
>
> TP_INT_FIFOC will control which TP_INT_FIFOS bits will actually raise an
> irq, so there are 2 cases of interest here:
>
> 1) Only this new a20-tp.c driver is loaded, in this case only
> TP_TEMP_IRQ_PENDING will actually raise an interrupt, and your interrupt handler
> only needs to check and clear that flag.
>
> 2) Both this new a20-tp.c driver is loaded as well as sun4i-ts in that case
> other interrupt sources will be enabled in TP_INT_FIFOC, but sun4i-ts will
> handle them, so your interrupt handler still only needs to check and clear
> TP_TEMP_IRQ_PENDING.
>

This driver was made with the intent of not being loaded at the same time of sun4i-ts. (depends on !TOUCHSCREEN_SUN4I_TS)
Moreover, I thinked it cannot be loaded at the same time because both driver claims the ownership of the IOMEM and IRQ.
But it seems that for the IRQ I was wrong since IRQ can be shared with the flag IRQF_SHARED. (But I cannot found anything on IOMEM sharing.)

So I will try to solves theses issues.

Thanks for your review.

[Hans de Goede]

Hi,

TBH I think that this driver should either be made parallel loadable, or be integrated into sun4i-ts .

> Moreover, I thinked it cannot be loaded at the same time because both driver claims the ownership of the IOMEM and IRQ.
> But it seems that for the IRQ I was wrong since IRQ can be shared with the flag IRQF_SHARED. (But I cannot found anything on IOMEM sharing.)

Ah, good point about the IOMEM part. So there are 2 options here:
1) integrate this driver into sun4i-ts (this is probably the route to go for upstream at least)
2) have 2 seperate drivers, and simply do not declare the iomem range in the hwmon-temp driver,
you can still access it just fine if you don't declerate it.

2) is not really pretty I must admit, still I think it is possible best since the current sun4i-ts
driver is quite ugly, and would probably need a lot if cleaning up before we can integrate hwmon
functionality into it (without making readers of the code cry).

Regards,

Hans

[Corentin LABBE]

Le 07/10/2013 17:31, Hans de Goede a �crit :

I agree that the integration in the sun4i-ts is a goal, but I do not have any touchscreen for cleaning and checking this driver.
So I have added some #ifdef RTP_SHARED for people who would want to test having both at the same time.

But without mutex, writing to IOMEM is a very bad idea. (a Suse kernel developper confirmed that to me).
So I do not believe that 2 separate drivers owning the same device is realistic without patching both.

I will send the modified patch soon.

Regards

[Hans de Goede]

Hi,

On 10/08/2013 06:33 PM, Corentin LABBE wrote:
> Le 07/10/2013 17:31, Hans de Goede a �crit :

<snip>

> I agree that the integration in the sun4i-ts is a goal, but I do not have any touchscreen for cleaning and checking this driver.
> So I have added some #ifdef RTP_SHARED for people who would want to test having both at the same time.
>
> But without mutex, writing to IOMEM is a very bad idea. (a Suse kernel developper confirmed that to me).

Ah right, without a mutex things will go wrong when doing read/modify/write cycles on a register,
I should have thought about that.

> So I do not believe that 2 separate drivers owning the same device is realistic without patching both.

You're right.

Regards,

Hans

[vinic...@gmail.com]

Em terça-feira, 8 de outubro de 2013 13h33min43s UTC-3, clabbe.montjoie escreveu:
> Le 07/10/2013 17:31, Hans de Goede a �crit :

>
> > Hi,
>
> >
>
> > On 10/07/2013 05:09 PM, Corentin LABBE wrote:
>

> >> Le 07/10/2013 15:38, Hans de Goede a �crit :

>
> >>> Hi,
>
> >>>
>
> >>> On 10/07/2013 02:01 PM, LABBE Corentin wrote:
>
> >>>>
>
> >>>> Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
>
> >>>> ---
>
> >>>> This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
>
> >>>> Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.
>
> >>>
>
> >>> Interesting idea to use the rtp temp sensor as a soc temp sensor and to write a hwmon sensor for
>
> >>> this, I like :)
>
> >>>
>
> >>> Note that all of sun4i sun5i and sun7i have the same RTP controller, so you should drop the
>
> >>> a20 from the name and use sunxi instead.
>
> >>
>
> >> Ok I will do that.
>
> >>
>
> >>>
>
> >>> Further comments inline.
>
> >>>
>

> >>>> For the temperature value, I cannot found any document on how to transform the raw value in �C.

Hi clabbe,

I'm writing TP driver for mainline, and I intend to add support for iio ADC and input touchscreen. If you agree I can add your code to my.

Thus we can have an integrated driver with ADC, Touchscreen and Temp sensor.

But I do not know how the user can choose the desired function. What would be the best way?

[Hans de Goede]

Hi,

On 10/10/2013 02:11 PM, vinic...@gmail.com wrote:
> Em ter�a-feira, 8 de outubro de 2013 13h33min43s UTC-3, clabbe.montjoie escreveu:
>> Le 07/10/2013 17:31, Hans de Goede a �crit :

>>
>>> Hi,
>>
>>>
>>
>>> On 10/07/2013 05:09 PM, Corentin LABBE wrote:
>>

>>>> Le 07/10/2013 15:38, Hans de Goede a �crit :

>>
>>>>> Hi,
>>
>>>>>
>>
>>>>> On 10/07/2013 02:01 PM, LABBE Corentin wrote:
>>
>>>>>>
>>
>>>>>> Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
>>
>>>>>> ---
>>
>>>>>> This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
>>
>>>>>> Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.
>>
>>>>>
>>
>>>>> Interesting idea to use the rtp temp sensor as a soc temp sensor and to write a hwmon sensor for
>>
>>>>> this, I like :)
>>
>>>>>
>>
>>>>> Note that all of sun4i sun5i and sun7i have the same RTP controller, so you should drop the
>>
>>>>> a20 from the name and use sunxi instead.
>>
>>>>
>>
>>>> Ok I will do that.
>>
>>>>
>>
>>>>>
>>
>>>>> Further comments inline.
>>
>>>>>
>>

>>>>>> For the temperature value, I cannot found any document on how to transform the raw value in �C.

I don't know about the ADC, but the temp sensor and RTP functionality can be used at the
same time. They both will probably get enabled through device-tree configuration, but the
driver should be prepared to register either only the hwmon device, or both the hwmon
and the touchscreen controller devices.

Talking about mainlining the rtp stuff, how will this work in userspace ? Will it
still need tslib ( https://github.com/kergoth/tslib ) ?

Regards,

Hans

[Hans de Goede]

Hi,

On 10/10/2013 03:04 PM, vinic...@gmail.com wrote:
> By the way, I have not found any reference to TP_TEMP_IRQ_EN and TP_TEMP_IRQ_PENDING. Neither the user manual nor the code. This information comes from where? :)

From the sources of the android kernel which allwinner has released.

Regards,

Hans

[Corentin LABBE]

Le 10/10/2013 15:04, vinic...@gmail.com a écrit :

> By the way, I have not found any reference to TP_TEMP_IRQ_EN and TP_TEMP_IRQ_PENDING. Neither the user manual nor the code. This information comes from where? :)

http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf Section 1.15

[Corentin LABBE]

Le 10/10/2013 14:11, vinic...@gmail.com a �crit :
> Em ter�a-feira, 8 de outubro de 2013 13h33min43s UTC-3, clabbe.montjoie escreveu:
>> Le 07/10/2013 17:31, Hans de Goede a �crit :

>>
>>> Hi,
>>> On 10/07/2013 05:09 PM, Corentin LABBE wrote:

>>>> Le 07/10/2013 15:38, Hans de Goede a �crit :

>>>>> Hi,
>>>>> On 10/07/2013 02:01 PM, LABBE Corentin wrote:
>>>>>> Signed-off-by: LABBE Corentin <clabbe....@gmail.com>
>>>>>> ---
>>>>>> This driver exposes the temperature sensor found in the RTP of A20 SoC to the hwmon interface.
>>>>>> Since I am only interested in getting the sensor value, I do not have patched the sun4i-ts driver.
>>>>> Interesting idea to use the rtp temp sensor as a soc temp sensor and to write a hwmon sensor for
>>>>> this, I like :)
>>>>> Note that all of sun4i sun5i and sun7i have the same RTP controller, so you should drop the
>>>>> a20 from the name and use sunxi instead.
>>>> Ok I will do that.
>>>>> Further comments inline.

>>>>>> For the temperature value, I cannot found any document on how to transform the raw value in �C.

No problem you can use it.

[Thomas...@phg-online.de]

clabbe.montjoie wrote:
> For the temperature value, I cannot found any document on how to transform the raw value in °C.

> [...]

> Under heavy loads, the temperature of both sensors rise linearly.

But based on a series of tests with and without heatsinks applied to the A20 I came to the conclusion that the values reported here must be already pre-calibrated. The base idle temperatures reported without an applied heatsink are way higher compared to the value of the very same A20 with heatsink:

http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=8137&pid=40817

Does anyone have a clue how the A20's CHOP_TEMP_EN register (according to the A20's user manual: "Chop temperature calibration enable: 0: Disable, 1: Enable") can be read/set?

[Christian Ege]

For read write access from user space you can try to use devmem2 with the address given in the user manual.

http://manpages.ubuntu.com/manpages/natty/man1/devmem2.1.html

Regards,
Christian
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Thomas...@phg-online.de]

Christian Ege wrote:
> Am 05.11.2014 12:44 schrieb <Thomas...@phg-online.de>:
>> Does anyone have a clue how the A20's CHOP_TEMP_EN register (according to the A20's
>> user manual: "Chop temperature calibration enable: 0: Disable, 1: Enable") can be read/set?
>
> For read write access from user space you can try to use devmem2 with the address given
> in the user manual.
>
> http://manpages.ubuntu.com/manpages/natty/man1/devmem2.1.html

Thx, will give it a try this evening. In the meantime I realized that it's bit 7 of the touchpanel's TP_CTRL1 register so when sunxi-dbgreg.ko is loaded I should succeed with

echo 'f1c25004' > /sys/devices/virtual/misc/sunxi-dbgreg/rw/read;

Corentin's code in this module as well as the sunxi-dbgreg-workaround I use set bit 4 to 1 but leave bit 7 untouched. With CHOP_TEMP_EN enabled I get a whopping 25°C lower reported by the TP controller inside the A20 with an attached heatsink compared to the very same A20 without a heatsink a few minutes before. I'll report back what can be read when CHOP_TEMP_EN is disabled.

[Thomas...@phg-online.de]

thomas...@phg-online.de wrote:
> In the meantime I realized that it's bit 7 of the touchpanel's TP_CTRL1 register so when sunxi-dbgreg.ko is loaded I should succeed with
>
> echo 'f1c25004' > /sys/devices/virtual/misc/sunxi-dbgreg/rw/read;
>
> Corentin's code in this module as well as the sunxi-dbgreg-workaround I use set bit 4 to 1 but leave bit 7 untouched.

Just realized my mistake. The method I used (writing \x10 to TP_CTRL1 using sunxi-dbgreg.ko) led to bit 7 being cleared and therefore setting CHOP_TEMP_EN from enable to disable. Restoring the default by writing \x90 to TP_CTRL1 gives temperature readouts way closer to reality. If CHOP_TEMP_EN is disabled the temperatures reported show in some situations a rather large offset to the actual temperatures in one or the other direction. If CHOP_TEMP_EN is enabled the deviation is much smaller.