linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>
Cc: kernel@collabora.com, "Chen-Yu Tsai" <wenst@chromium.org>,
	"Bernhard Rosenkränzer" <bero@baylibre.com>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Balsam CHIHI" <bchihi@baylibre.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Zhang Rui" <rui.zhang@intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH] thermal/drivers/mediatek/lvts_thermal: Make readings valid in filtered mode
Date: Fri, 7 Jul 2023 10:32:02 +0200	[thread overview]
Message-ID: <a08862e5-4e84-c3a8-b373-5fbff1e84704@collabora.com> (raw)
In-Reply-To: <20230706161509.204546-1-nfraprado@collabora.com>

Il 06/07/23 18:14, Nícolas F. R. A. Prado ha scritto:
> Currently, when a controller is configured to use filtered mode, thermal
> readings are valid only about 30% of the time.
> 
> Upon testing, it was noticed that lowering any of the interval settings
> resulted in an improved rate of valid data. The same was observed when
> decreasing the number of samples for each sensor (which also results in
> quicker measurements).
> 
> Retrying the read with a timeout longer than the time it takes to
> resample (about 344us with these settings and 4 sensors) also improves
> the rate.
> 
> Lower all timing settings to the minimum, configure the filtering to
> single sample, and poll the measurement register for at least one period
> to improve the data validity on filtered mode.  With these changes in
> place, out of 100000 reads, a single one failed, ie 99.999% of the data
> was valid.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> ---
> 
>   drivers/thermal/mediatek/lvts_thermal.c | 15 ++++++++-------
>   1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
> index 1e11defe4f35..b5fb1d8bc3d8 100644
> --- a/drivers/thermal/mediatek/lvts_thermal.c
> +++ b/drivers/thermal/mediatek/lvts_thermal.c
> @@ -58,11 +58,11 @@
>   #define LVTS_PROTTC(__base)		(__base + 0x00CC)
>   #define LVTS_CLKEN(__base)		(__base + 0x00E4)
>   
> -#define LVTS_PERIOD_UNIT			((118 * 1000) / (256 * 38))
> -#define LVTS_GROUP_INTERVAL			1
> -#define LVTS_FILTER_INTERVAL		1
> -#define LVTS_SENSOR_INTERVAL		1
> -#define LVTS_HW_FILTER				0x2
> +#define LVTS_PERIOD_UNIT			0
> +#define LVTS_GROUP_INTERVAL			0
> +#define LVTS_FILTER_INTERVAL		0
> +#define LVTS_SENSOR_INTERVAL		0
> +#define LVTS_HW_FILTER				0x0
>   #define LVTS_TSSEL_CONF				0x13121110
>   #define LVTS_CALSCALE_CONF			0x300
>   #define LVTS_MONINT_CONF			0x9FBF7BDE
> @@ -257,6 +257,7 @@ static int lvts_get_temp(struct thermal_zone_device *tz, int *temp)
>   	struct lvts_sensor *lvts_sensor = thermal_zone_device_priv(tz);
>   	void __iomem *msr = lvts_sensor->msr;
>   	u32 value;
> +	int rc;
>   
>   	/*
>   	 * Measurement registers:
> @@ -269,7 +270,7 @@ static int lvts_get_temp(struct thermal_zone_device *tz, int *temp)
>   	 * 16	: Valid temperature
>   	 * 15-0	: Raw temperature
>   	 */
> -	value = readl(msr);

#define LVTS_MSR_READ_TIMEOUT_US	400

then, either 240 like this...

#define LVTS_MSR_READ_WAIT_US		((LVTS_MSR_READ_TIMEOUT_US / 2) - 10)

..or 220 (if valid) like this..

#define LVTS_MSR_READ_WAIT_US		((LVTS_MSR_READ_TIMEOUT_US / 20) + \
					 (LVTS_MSR_READ_TIMEOUT_US / 2))

..or just "240-and-that's-it"

#define LVTS_MSR_READ_WAIT_US		240

	rc = readl_poll_timeout(msr, value, value & BIT(16),
				LVTS_MSR_READ_WAIT_US, LVTS_MSR_READ_TIMEOUT_US);

Cheers,
Angelo



      parent reply	other threads:[~2023-07-07  8:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06 16:14 [PATCH] thermal/drivers/mediatek/lvts_thermal: Make readings valid in filtered mode Nícolas F. R. A. Prado
2023-07-07  7:53 ` Chen-Yu Tsai
2023-07-07  8:32 ` AngeloGioacchino Del Regno [this message]

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=a08862e5-4e84-c3a8-b373-5fbff1e84704@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=amitk@kernel.org \
    --cc=bchihi@baylibre.com \
    --cc=bero@baylibre.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nfraprado@collabora.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=wenst@chromium.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).