[PATCH] touchscreen: sun4i-ts: Really fix A10 temperature reporting

[Hans de Goede]

The commit titled:
"touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
contains a math error, the offset it uses is in degrees, but the actual code
applies the offset before multiplying by stepsize :|

Given that this is rather backwards (every math course ever thought applies
the multiplication before the offset for linear functions), this commit
fixes things by changing the code applying the offset to do the logical
thing, adjusting the offset for the other models accordingly.

This has been tested on an A10, A13, A20 and A31 to make sure everything really
is correct now.

Signed-off-by: Hans de Goede <hdeg...@redhat.com>
---
Note if possible this commit should be squashed into the original
"touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
commit as a fixup.
---
drivers/input/touchscreen/sun4i-ts.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c
index 66ccd5a..178d2ef 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -193,7 +193,7 @@ static int sun4i_get_temp(const struct sun4i_ts_data *ts, long *temp)
if (ts->temp_data == -1)
return -EAGAIN;

- *temp = (ts->temp_data - ts->temp_offset) * ts->temp_step;
+ *temp = ts->temp_data * ts->temp_step - ts->temp_offset;

return 0;
}
@@ -255,17 +255,17 @@ static int sun4i_ts_probe(struct platform_device *pdev)
ts->ignore_fifo_data = true;
ts->temp_data = -1;
if (of_device_is_compatible(np, "allwinner,sun6i-a31-ts")) {
- /* Allwinner SDK has temperature = -271 + (value / 6) (C) */
- ts->temp_offset = 1626;
+ /* Allwinner SDK has temperature (C) = (value / 6) - 271 */
+ ts->temp_offset = 271000;
ts->temp_step = 167;
} else if (of_device_is_compatible(np, "allwinner,sun4i-a10-ts")) {
/*
* The A10 temperature sensor has quite a wide spread, these
* parameters are based on the averaging of the calibration
* results of 4 completely different boards, with a spread of
- * temp_step from 96 - 170 and temp_offset from 1758 - 3310.
+ * temp_step from 0.096 - 0.170 and temp_offset from 176 - 331.
*/
- ts->temp_offset = 2570;
+ ts->temp_offset = 257000;
ts->temp_step = 133;
} else {
/*
@@ -273,13 +273,13 @@ static int sun4i_ts_probe(struct platform_device *pdev)
* the temperature. The formula used here is from the AXP209,
* which is designed by X-Powers, an affiliate of Allwinner:
*
- * temperature = -144.7 + (value * 0.1)
+ * temperature (C) = (value * 0.1) - 144.7
*
* Allwinner does not have any documentation whatsoever for
* this hardware. Moreover, it is claimed that the sensor
* is inaccurate and cannot work properly.
*/
- ts->temp_offset = 1447;
+ ts->temp_offset = 144700;
ts->temp_step = 100;
}

--
2.3.1

[Dmitry Torokhov]

On Mon, Mar 09, 2015 at 10:37:50AM +0100, Hans de Goede wrote:
> The commit titled:
> "touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
> contains a math error, the offset it uses is in degrees, but the actual code
> applies the offset before multiplying by stepsize :|
>
> Given that this is rather backwards (every math course ever thought applies
> the multiplication before the offset for linear functions), this commit
> fixes things by changing the code applying the offset to do the logical
> thing, adjusting the offset for the other models accordingly.
>
> This has been tested on an A10, A13, A20 and A31 to make sure everything really
> is correct now.
>
> Signed-off-by: Hans de Goede <hdeg...@redhat.com>
> ---
> Note if possible this commit should be squashed into the original
> "touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
> commit as a fixup.

It's a bit too late, I do not like rewinding my 'next' branch unless it
is a compile error caught recently. So applied as a separate commit.

Thanks.

--
Dmitry

[m.sile...@gmail.com]

Hi Hans,

is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?

On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.

Given that there is no Documentation and things seem quite board-specific, I really don't know how this could be improved, so I can merely report my observation.

Kind regards,

Timo

[Hans de Goede]

Hi,

On 06/23/2015 05:06 PM, m.sile...@gmail.com wrote:
> Hi Hans,
>
> is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?
>
> On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.

The temperature curve for the A20 SoC was not changed, if it did change then
you're using an old dtb file with a new kernel, you must always update your
dtb file together with the kernel.

Regards,

Hans

[Dmitry Torokhov]

On Tue, Jun 23, 2015 at 09:46:20PM +0200, Hans de Goede wrote:
> Hi,
>
> On 06/23/2015 05:06 PM, m.sile...@gmail.com wrote:
> >Hi Hans,
> >
> >is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?
> >
> >On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.
>
> The temperature curve for the A20 SoC was not changed, if it did change then
> you're using an old dtb file with a new kernel, you must always update your
> dtb file together with the kernel.

Umm, we should keep compatibility with old DTS...

--
Dmitry

[m.sile...@gmail.com]

Hi,

Am Dienstag, 23. Juni 2015 21:46:25 UTC+2 schrieb Hans de Goede:
> Hi,
>
> On 06/23/2015 05:06 PM, m.sile...@gmail.com wrote:
> > Hi Hans,
> >
> > is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?
> >
> > On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.
>
> The temperature curve for the A20 SoC was not changed, if it did change then
> you're using an old dtb file with a new kernel, you must always update your
> dtb file together with the kernel.

I always compile the dts that comes with the kernel tree from scratch. So this is up to date. I guess I have to dig in deeper then what caused that change. Any other hint where to look for?

Thanks,

Timo

[m.sile...@gmail.com]

Hi again,

Am Dienstag, 23. Juni 2015 21:46:25 UTC+2 schrieb Hans de Goede:

> Hi,
>
> On 06/23/2015 05:06 PM, m.sile...@gmail.com wrote:
> > Hi Hans,
> >
> > is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?
> >
> > On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.
>
> The temperature curve for the A20 SoC was not changed, if it did change then
> you're using an old dtb file with a new kernel, you must always update your
> dtb file together with the kernel.

I just checked the diff for Linux 4.0 and 4.1 and noticed that sun7i-a20.dtsi in fact has not changed. Is it possible that something that should have been merged got delayed?

I looked in Maxime's tree "dt-for-4.2" and found this patch that looks like it could be related: https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-4.2&id=8bf1b9b3d90194a174493febc731f7783f2adf1a

Regards,

Timo

[Hans de Goede]

Hi,

On 23-06-15 21:54, Dmitry Torokhov wrote:
> On Tue, Jun 23, 2015 at 09:46:20PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 06/23/2015 05:06 PM, m.sile...@gmail.com wrote:
>>> Hi Hans,
>>>
>>> is it possible that this patch (and the parent commit "Input: sun4i-ts - allow controlling filter and sensitivity via DT") has quite an adversial effect on other boards than the ones tested?
>>>
>>> On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.
>>
>> The temperature curve for the A20 SoC was not changed, if it did change then
>> you're using an old dtb file with a new kernel, you must always update your
>> dtb file together with the kernel.
>
> Umm, we should keep compatibility with old DTS...

Right, unfortunately that is not always possible, and with sunxi boards the dtb
is always shipped together with the kernel, and the dtb as ABI rule really is
intended for the case where the dtb ships with the board/firmware.

That does not mean that we can go and break it every other day, but the problem
in this case is that we shipped a dts for all boards with a compatible of
allwinner,sun4i-a10-ts, and then later on we found out that the temperature
curve for the build in temp sensor is different for the A10 compared to the
A13/A20, so we adjusted the kernel driver to have 2 temperature curves,
1 for the A10 and one for the later models, and adjusted the compatible in
the dts for later models to allwinner,sun5i-a13-ts, note that the actual
touchscreen functionality is unchanged and works fine with both compatibles,
the only thing which is happening now is that Timo is seeing a different
temperature because he is using the new A10 temperature curve on his A20,
other then that everything still works 100%, and there really was
no other way to deal with this.

Let me also reply to one of Timo's later mails here, as that explains
the real problem:

On 23-06-15 23:06, m.sile...@gmail.com wrote:> Hi again,

>
> Am Dienstag, 23. Juni 2015 21:46:25 UTC+2 schrieb Hans de Goede:

<snip>

>>> On my Lemaker Bananapi the temperature is now being reported as somwhere between -15°C to -10°C with the latest Kernel 4.1.0. These negative values are obviously way off. On Kernel 4.0.5 the temperature reading was usually around 40°C. While that might not have been accurate either, it was at least plausible.
>>
>> The temperature curve for the A20 SoC was not changed, if it did change then
>> you're using an old dtb file with a new kernel, you must always update your
>> dtb file together with the kernel.
>

> I just checked the diff for Linux 4.0 and 4.1 and noticed that sun7i-a20.dtsi in fact has not changed. Is it possible that something that should have been merged got delayed?
>
> I looked in Maxime's tree "dt-for-4.2" and found this patch that looks like it could be related: https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-4.2&id=8bf1b9b3d90194a174493febc731f7783f2adf1a

Ah yes, something went wrong during the 4.1 cycle wrt merging ARM patches
which have caused almost all ARM patches intended for 4.1 to get delayed to
4.2, including that one, that is the problem.

We did our best to update the driver and the dts in lockstep, and you should
have never seen this problem, but the missing of the merge window for all
ARM patches during the 4.1 cycle has caused our carefully planned lock-step
update to fail, sorry about that.

Maxime I think we should send the mentioned dts patch to stable for 4.1 ,
do you agree ?

Regards,

Hans

[Maxime Ripard]

Hi,

On Wed, Jun 24, 2015 at 09:16:54AM +0200, Hans de Goede wrote:
> Maxime I think we should send the mentioned dts patch to stable for
> 4.1 , do you agree ?

Yep. We should definitely do that. You take care of this?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Hans de Goede]

Hi,

On 24-06-15 09:28, Maxime Ripard wrote:
> Hi,
>
> On Wed, Jun 24, 2015 at 09:16:54AM +0200, Hans de Goede wrote:
>> Maxime I think we should send the mentioned dts patch to stable for
>> 4.1 , do you agree ?
>
> Yep. We should definitely do that. You take care of this?

Yes I'll try to do so later today.

Regards,

Hans

[Timo S.]

Hi Hans,

On Wed, Jun 24, 2015 at 9:16 AM, Hans de Goede <hdeg...@redhat.com> wrote:

Ah yes, something went wrong during the 4.1 cycle wrt merging ARM patches
which have caused almost all ARM patches intended for 4.1 to get delayed to
4.2, including that one, that is the problem.

We did our best to update the driver and the dts in lockstep, and you should
have never seen this problem, but the missing of the merge window for all
ARM patches during the 4.1 cycle has caused our carefully planned lock-step
update to fail, sorry about that.

No need to apologize. Things happen. Glad to see this cleared up so quickly.

Thanks for the help (and all the other work you do ;)).

Kind regards,

Timo