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.
Signed-off-by: Eliav Farber <[email protected]>
---
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) {
--
2.37.1
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 <[email protected]>
> ---
> 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) {
On 8/18/2022 11:28 PM, Guenter Roeck wrote:
> 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.
The calculation was changed in previous patch to match series 5 of the
Moortec Embedded Temperature Sensor (METS) datasheet.
In our SOC we use series 6 which has a slightly different equation and
different coefficients.
I did the changes in steps.
With this last change, both series 5 and 6 are supported, in addition to
calibrated vs. non-calibrated modes.
In addition the data sheet just recommends default values but they also
specifically mention that actual values might vary from product to product.
--
Regards, Eliav
On Fri, Aug 19, 2022 at 10:57:58AM +0300, Farber, Eliav wrote:
> On 8/18/2022 11:28 PM, Guenter Roeck wrote:
> > 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.
> The calculation was changed in previous patch to match series 5 of the
> Moortec Embedded Temperature Sensor (METS) datasheet.
> In our SOC we use series 6 which has a slightly different equation and
> different coefficients.
> I did the changes in steps.
> With this last change, both series 5 and 6 are supported, in addition to
> calibrated vs. non-calibrated modes.
> In addition the data sheet just recommends default values but they also
> specifically mention that actual values might vary from product to product.
>
Please mention all this in the commit description.
Guenter
> --
> Regards, Eliav
On Fri, Aug 19, 2022 at 10:57:58AM +0300, Farber, Eliav wrote:
> On 8/18/2022 11:28 PM, Guenter Roeck wrote:
> > 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.
> The calculation was changed in previous patch to match series 5 of the
> Moortec Embedded Temperature Sensor (METS) datasheet.
> In our SOC we use series 6 which has a slightly different equation and
> different coefficients.
If the coefficients are different based on the series, it would probably
make sense to create a separate devicetree compatible property for series 6
instead or requiring the user to list the actual coefficients. Those can
still be present, but the code should be able to use the defaults for
each series.
Guenter
> I did the changes in steps.
> With this last change, both series 5 and 6 are supported, in addition to
> calibrated vs. non-calibrated modes.
> In addition the data sheet just recommends default values but they also
> specifically mention that actual values might vary from product to product.
>
> --
> Regards, Eliav
On 8/19/2022 2:38 PM, Guenter Roeck wrote:
> On Fri, Aug 19, 2022 at 10:57:58AM +0300, Farber, Eliav wrote:
>> On 8/18/2022 11:28 PM, Guenter Roeck wrote:
>> > 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.
>> The calculation was changed in previous patch to match series 5 of the
>> Moortec Embedded Temperature Sensor (METS) datasheet.
>> In our SOC we use series 6 which has a slightly different equation and
>> different coefficients.
>
> If the coefficients are different based on the series, it would probably
> make sense to create a separate devicetree compatible property for
> series 6
> instead or requiring the user to list the actual coefficients. Those can
> still be present, but the code should be able to use the defaults for
> each series.
There is a different set of coefficients for series 5 and for series 6,
so it would make sense to add a single property (e.g. series) instead
of adding 4 properties, one for each coefficient.
But that would not always be enough.
The Moortec datasheet explicitly says that coefficients can vary between
product and product, and be different from the default values.
That is the situation in our SOC.
The coefficients we use are slightly different from the defaults for
series 6.
So just adding a single series property would not be enough, and we would
anyway want to have the option to specifically determine the coefficient
values.
Do you suggest to add both, also series and also coefficients? (and I can
fail the probe in case both are set, to avoid conflicts).
--
Thanks, Eliav
On Mon, Aug 22, 2022 at 04:41:07PM +0300, Farber, Eliav wrote:
> On 8/19/2022 2:38 PM, Guenter Roeck wrote:
> > On Fri, Aug 19, 2022 at 10:57:58AM +0300, Farber, Eliav wrote:
> > > On 8/18/2022 11:28 PM, Guenter Roeck wrote:
> > > > 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.
> > > The calculation was changed in previous patch to match series 5 of the
> > > Moortec Embedded Temperature Sensor (METS) datasheet.
> > > In our SOC we use series 6 which has a slightly different equation and
> > > different coefficients.
> >
> > If the coefficients are different based on the series, it would probably
> > make sense to create a separate devicetree compatible property for
> > series 6
> > instead or requiring the user to list the actual coefficients. Those can
> > still be present, but the code should be able to use the defaults for
> > each series.
> There is a different set of coefficients for series 5 and for series 6,
> so it would make sense to add a single property (e.g. series) instead
> of adding 4 properties, one for each coefficient.
> But that would not always be enough.
> The Moortec datasheet explicitly says that coefficients can vary between
> product and product, and be different from the default values.
> That is the situation in our SOC.
> The coefficients we use are slightly different from the defaults for
> series 6.
> So just adding a single series property would not be enough, and we would
> anyway want to have the option to specifically determine the coefficient
> values.
> Do you suggest to add both, also series and also coefficients? (and I can
> fail the probe in case both are set, to avoid conflicts).
>
It should not be necessary to provide explicit default values for any of the
series. Yes, default values can be overwritten with explicit coefficient
properties, but it should not be necessary to provide those if the defaults
are used. So I would expect separate compatible properties for each of the
supported series plus separate coefficient properties.
However, since we are discussiong DT properties here, I'll step back and let
DT maintainers decide.
Thanks,
Guenter
On 8/22/2022 7:31 PM, Guenter Roeck wrote:
> It should not be necessary to provide explicit default values for any
> of the
> series. Yes, default values can be overwritten with explicit coefficient
> properties, but it should not be necessary to provide those if the
> defaults
> are used. So I would expect separate compatible properties for each of
> the
> supported series plus separate coefficient properties.
I added a "moortec,ts-series" so that user will not need to provide all
4 coefficients.
The values of the "moortec,ts-series" can be 5 (default) or 6.
I didn't do it as a compatible property because the the driver is for
the Moortec controller (mr75203) while series 5 or 6 are only relevant
for the thermal sensor (mr74137).
--
Thanks, Eliav