[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220818202839.GA3431511@roeck-us.net>
Date: Thu, 18 Aug 2022 13:28:39 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Eliav Farber <farbere@...zon.com>
Cc: jdelvare@...e.com, robh+dt@...nel.org, mark.rutland@....com,
linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, talel@...zon.com, hhhawa@...zon.com,
jonnyc@...zon.com, hanochu@...zon.com, ronenk@...zon.com,
itamark@...zon.com, shellykz@...zon.com, shorer@...zon.com,
amitlavi@...zon.com, almogbs@...zon.com, dwmw@...zon.co.uk,
rtanwar@...linear.com
Subject: Re: [PATCH v2 14/16] hwmon: (mr75203) parse thermal coefficients
from device-tree
On Wed, Aug 17, 2022 at 05:43:19AM +0000, Eliav Farber wrote:
> Use thermal coefficients from the device tree if they exist.
> Otherwise, use default values.
>
> The equation used in the driver is:
> T = G + H * (n / cal5 - 0.5) + J * F
>
> With this change we can support also Mode 1 Conversion, which
> uses A instead of G, and B instead of H.
>
> We can also support the series 6 equation that has different
> coefficients and has a slightly different format:
> T = G + H * (n / cal5 - 0.5)
> by setting J to 0.
>
The calculation was just changed to use new defaults in a previous
patch. This patch makes it quite clear that the coefficients
are implementation (?) dependent. So the previous patch just changes
the defaults to (presumably) the coefficients used in your system.
That is inappropriate. Adding non-default corefficients is ok
and makes sense is supported by the chip, but changing defaults
isn't.
Guenter
> Signed-off-by: Eliav Farber <farbere@...zon.com>
> ---
> drivers/hwmon/mr75203.c | 44 +++++++++++++++++++++++++++++++++++++----
> 1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/mr75203.c b/drivers/hwmon/mr75203.c
> index e500897585e4..e54a4d1803e4 100644
> --- a/drivers/hwmon/mr75203.c
> +++ b/drivers/hwmon/mr75203.c
> @@ -131,6 +131,10 @@ struct pvt_device {
> u32 p_num;
> u32 v_num;
> u32 ip_freq;
> + u32 ts_coeff_h;
> + u32 ts_coeff_g;
> + s32 ts_coeff_j;
> + u32 ts_coeff_cal5;
> u8 vm_ch_max;
> u8 vm_ch_total;
> };
> @@ -179,10 +183,10 @@ static int pvt_read_temp(struct device *dev, u32 attr, int channel, long *val)
> * Convert the register value to degrees centigrade temperature:
> * T = G + H * (n / cal5 - 0.5) + J * F
> */
> - *val = PVT_G_CONST;
> - *val += PVT_H_CONST * nbs / PVT_CAL5_CONST;
> - *val -= PVT_H_CONST / 2;
> - *val += PVT_J_CONST * pvt->ip_freq / HZ_PER_MHZ;
> + *val = pvt->ts_coeff_g;
> + *val += pvt->ts_coeff_h * nbs / pvt->ts_coeff_cal5;
> + *val -= pvt->ts_coeff_h / 2;
> + *val += pvt->ts_coeff_j * pvt->ip_freq / HZ_PER_MHZ;
>
> return 0;
> default:
> @@ -619,6 +623,38 @@ static int mr75203_probe(struct platform_device *pdev)
> memset32(temp_config, HWMON_T_INPUT, ts_num);
> pvt_temp.config = temp_config;
> pvt_info[index++] = &pvt_temp;
> +
> + /*
> + * Incase ts-coeff-h/g/j/cal5 property is not defined, use
> + * default value.
> + */
> + ret = of_property_read_u32(np, "ts-coeff-h", &pvt->ts_coeff_h);
> + if (ret)
> + pvt->ts_coeff_h = PVT_H_CONST;
> +
> + ret = of_property_read_u32(np, "ts-coeff-g", &pvt->ts_coeff_g);
> + if (ret)
> + pvt->ts_coeff_g = PVT_G_CONST;
> +
> + ret = of_property_read_s32(np, "ts-coeff-j", &pvt->ts_coeff_j);
> + if (ret)
> + pvt->ts_coeff_j = PVT_J_CONST;
> +
> + ret = of_property_read_u32(np, "ts-coeff-cal5",
> + &pvt->ts_coeff_cal5);
> + if (ret) {
> + pvt->ts_coeff_cal5 = PVT_CAL5_CONST;
> + } else {
> + if (pvt->ts_coeff_cal5 == 0) {
> + dev_err(dev, "invalid ts-coeff-cal5 (%u)\n",
> + pvt->ts_coeff_cal5);
> + return -EINVAL;
> + }
> + }
> +
> + dev_dbg(dev, "ts-coeff: h = %u, g = %u, j = %d, cal5 = %u\n",
> + pvt->ts_coeff_h, pvt->ts_coeff_g, pvt->ts_coeff_j,
> + pvt->ts_coeff_cal5);
> }
>
> if (pd_num) {
Powered by blists - more mailing lists