From: Guenter Roeck <linux@roeck-us.net>
To: Nishanth Menon <nm@ti.com>
Cc: Jean Delvare <jdelvare@suse.com>,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
linux-omap@vger.kernel.org, beagleboard-x15@googlegroups.com,
Eduardo Valentin <edubezval@gmail.com>
Subject: Re: [PATCH V2] hwmon: (tmp102) Force wait for conversion time for the first valid data
Date: Tue, 1 Dec 2015 13:06:24 -0800 [thread overview]
Message-ID: <20151201210624.GA9177@roeck-us.net> (raw)
In-Reply-To: <1448986221-6190-1-git-send-email-nm@ti.com>
On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote:
> TMP102 works based on conversions done periodically. However, as per
> the TMP102 data sheet[1] the first conversion is triggered immediately
> after we program the configuration register. The temperature data
> registers do not reflect proper data until the first conversion is
> complete (in our case HZ/4).
>
> The driver currently sets the last_update to be jiffies - HZ, just
> after the configuration is complete. When TMP102 driver registers
> with the thermal framework, it immediately tries to read the sensor
> temperature data. This takes place even before the conversion on the
> TMP102 is complete and results in an invalid temperature read.
>
> Depending on the value read, this may cause thermal framework to
> assume that a critical temperature event has occurred and attempts to
> shutdown the system.
>
> Instead of causing an invalid mid-conversion value to be read
> erroneously, we mark the last_update to be in-line with the current
> jiffies. This allows the tmp102_update_device function to skip update
> until the required conversion time is complete. Further, we ensure to
> return -EAGAIN result instead of returning spurious temperature (such
> as 0C) values to the caller to prevent any wrong decisions made with
> such values. NOTE: this allows the read functions not to be blocking
> and allows the callers to make the decision if they would like to
> block or try again later. At least the current user(thermal) seems to
> handle this by retrying later.
>
> A simpler alternative approach could be to sleep in the probe for the
> duration required, but that will result in latency that is undesirable
> and delay boot sequence un-necessarily.
>
> [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Reported-by: Aparna Balasubramanian <aparnab@ti.com>
> Reported-by: Elvita Lobo <elvita@ti.com>
> Reported-by: Yan Liu <yan-liu@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Applied.
Thanks,
Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Nishanth Menon <nm@ti.com>
Cc: Jean Delvare <jdelvare@suse.com>,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org,
linux-omap@vger.kernel.org, beagleboard-x15@googlegroups.com,
Eduardo Valentin <edubezval@gmail.com>
Subject: Re: [lm-sensors] [PATCH V2] hwmon: (tmp102) Force wait for conversion time for the first valid data
Date: Tue, 01 Dec 2015 21:06:24 +0000 [thread overview]
Message-ID: <20151201210624.GA9177@roeck-us.net> (raw)
In-Reply-To: <1448986221-6190-1-git-send-email-nm@ti.com>
On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote:
> TMP102 works based on conversions done periodically. However, as per
> the TMP102 data sheet[1] the first conversion is triggered immediately
> after we program the configuration register. The temperature data
> registers do not reflect proper data until the first conversion is
> complete (in our case HZ/4).
>
> The driver currently sets the last_update to be jiffies - HZ, just
> after the configuration is complete. When TMP102 driver registers
> with the thermal framework, it immediately tries to read the sensor
> temperature data. This takes place even before the conversion on the
> TMP102 is complete and results in an invalid temperature read.
>
> Depending on the value read, this may cause thermal framework to
> assume that a critical temperature event has occurred and attempts to
> shutdown the system.
>
> Instead of causing an invalid mid-conversion value to be read
> erroneously, we mark the last_update to be in-line with the current
> jiffies. This allows the tmp102_update_device function to skip update
> until the required conversion time is complete. Further, we ensure to
> return -EAGAIN result instead of returning spurious temperature (such
> as 0C) values to the caller to prevent any wrong decisions made with
> such values. NOTE: this allows the read functions not to be blocking
> and allows the callers to make the decision if they would like to
> block or try again later. At least the current user(thermal) seems to
> handle this by retrying later.
>
> A simpler alternative approach could be to sleep in the probe for the
> duration required, but that will result in latency that is undesirable
> and delay boot sequence un-necessarily.
>
> [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Reported-by: Aparna Balasubramanian <aparnab@ti.com>
> Reported-by: Elvita Lobo <elvita@ti.com>
> Reported-by: Yan Liu <yan-liu@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Applied.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2015-12-01 21:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 4:25 [PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data Nishanth Menon
2015-12-01 4:25 ` Nishanth Menon
2015-12-01 4:25 ` [lm-sensors] " Nishanth Menon
2015-12-01 5:50 ` Guenter Roeck
2015-12-01 5:50 ` [lm-sensors] " Guenter Roeck
2015-12-01 13:47 ` Nishanth Menon
2015-12-01 13:47 ` Nishanth Menon
2015-12-01 13:47 ` [lm-sensors] " Nishanth Menon
2015-12-01 14:21 ` Nishanth Menon
2015-12-01 14:21 ` Nishanth Menon
2015-12-01 14:21 ` [lm-sensors] " Nishanth Menon
2015-12-01 15:09 ` Guenter Roeck
2015-12-01 15:09 ` [lm-sensors] " Guenter Roeck
2015-12-01 15:14 ` Nishanth Menon
2015-12-01 15:14 ` Nishanth Menon
2015-12-01 15:14 ` [lm-sensors] " Nishanth Menon
2015-12-01 16:10 ` [PATCH V2] " Nishanth Menon
2015-12-01 16:10 ` Nishanth Menon
2015-12-01 16:10 ` [lm-sensors] " Nishanth Menon
2015-12-01 21:06 ` Guenter Roeck [this message]
2015-12-01 21:06 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151201210624.GA9177@roeck-us.net \
--to=linux@roeck-us.net \
--cc=beagleboard-x15@googlegroups.com \
--cc=edubezval@gmail.com \
--cc=jdelvare@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=nm@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.