All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Hauser <jahau@rocketmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	phone-devel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v3 4/8] iio: magnetometer: yas530: Correct temperature handling
Date: Tue, 21 Jun 2022 02:48:46 +0200	[thread overview]
Message-ID: <a348dbb6-8d4a-bcdb-e992-9b11e1c9f23f@rocketmail.com> (raw)
In-Reply-To: <20220618155331.5da93b88@jic23-huawei>

Hi Jonathan,

On 18.06.22 16:53, Jonathan Cameron wrote:
>
> On Sat, 18 Jun 2022 02:13:12 +0200
> Jakob Hauser <jahau@rocketmail.com> wrote:
...
>>  /* These variant IDs are known from code dumps */
>>  #define YAS537_DEVICE_ID		0x07 /* YAS537 (MS-3T) */
>> @@ -314,7 +315,7 @@ static s32 yas5xx_linearize(struct yas5xx *yas5xx, u16 val, int axis)
> 
> Hmm. I'm not a great fun of big hydra functions to handle differences
> between devices.  This could easily all be one code flow with some
> lookups into chip specific constant data (as btw could a lot of
> the other switch statements in the existing driver).

I'll try to implement the chip_info approach. This should become a
separate patch.

Concerning the patchset, I would prefer to introduce the chip_info
approach rather late. That would mean to leave this patch unchanged and
introduce your suggestions later within the patchset. I think it's
easier to follow the changes along the patchset.

However, you probably would prefer to place the chip_info patch rather
early in the patchset?

>>  static int yas5xx_get_measure(struct yas5xx *yas5xx, s32 *to, s32 *xo, s32 *yo, s32 *zo)
>>  {
>>  	struct yas5xx_calibration *c = &yas5xx->calibration;
>> -	u16 t, x, y1, y2;
>> +	u16 t_ref, t, x, y1, y2;
>>  	/* These are "signed x, signed y1 etc */
>>  	s32 sx, sy1, sy2, sy, sz;
>>  	int ret;
>> @@ -329,16 +330,46 @@ static int yas5xx_get_measure(struct yas5xx *yas5xx, s32 *to, s32 *xo, s32 *yo,
>>  	sy1 = yas5xx_linearize(yas5xx, y1, 1);
>>  	sy2 = yas5xx_linearize(yas5xx, y2, 2);
>>  
>> -	/*
>> -	 * Temperature compensation for x, y1, y2 respectively:
>> -	 *
>> -	 *          Cx * t
>> -	 * x' = x - ------
>> -	 *           100
>> -	 */
>> -	sx = sx - (c->Cx * t) / 100;
>> -	sy1 = sy1 - (c->Cy1 * t) / 100;
>> -	sy2 = sy2 - (c->Cy2 * t) / 100;
>> +	/* Set the temperature reference value (unit: counts) */
>> +	switch (yas5xx->devid) {
>> +	case YAS530_DEVICE_ID:
>> +		t_ref = YAS530_20DEGREES;
> 
> One thought to simplify the divergent flow below.
> 
> 		t_ref2 = 0;
>> +		break;
>> +	case YAS532_DEVICE_ID:
>> +		t_ref = YAS532_20DEGREES;
> 		if (yas5xx->version == YAS532_VERSION_AC)
> 			t_ref2 = YAS432_20DEGREES;
> 		else
> 			t_ref2 = 0;

The t_ref2 approach looks confusing to me. Because for the most version
it's "t_ref2 = 0", only one version out of four needs this.

Another approach: I would rather introduce t_comp (for compensation). In
the chip_info, for the most version it would be...

        .t_comp = t,

... and for the one variant it would be:

        .t_comp = t - t_ref,

A problem: I would include the YAS variants like YAS530, YAS532 etc. in
the chip_info. The versions like "AB" and "AC", on the other hand, I
wouldn't include into the chip_info, instead I would handle these in the
functions. In that case the, "t_comp" thing would need to be done in the
function using an if statement, similar to what you suggested up here.
I'll have a closer look when setting up patchset v4.

> Possibly with moving some of the comments below up here.
> As mentioned below, this stuff would be even better if
> in a chip type specific const structure rather than as code.
> That is have one switch statement in probe that picks from
> an array of 
> 
> struct yas5xx_chip_info {
> 	/* COMMENTS ON WHAT these are.. *
> 	u16 tref;
> 	u16 tref2;
> 	int ref_temp_celsius;
> 	int min_temp_celsuis;
> };
> static const struct yas5xx_chip_info[] = {
> 	[ENUM value we will use to pick right on in probe] = {
> 		...
> 
> etc

Thanks for writing down what it's supposed to look, that's helpful to
compare with other examples.

...

>> @@ -347,11 +378,37 @@ static int yas5xx_get_measure(struct yas5xx *yas5xx, s32 *to, s32 *xo, s32 *yo,
>>  	sy = sy1 - sy2;
>>  	sz = -sy1 - sy2;
>>  
>> -	/*
>> -	 * FIXME: convert to Celsius? Just guessing this is given
>> -	 * as 1/10:s of degrees so multiply by 100 to get millicentigrades.
>> -	 */
>> -	*to = t * 100;
>> +	/* Process temperature readout */
>> +	switch (yas5xx->devid) {
>> +	case YAS530_DEVICE_ID:
>> +		/*
>> +		 * Raw temperature value t is the number of counts starting
>> +		 * at -62 °C. Reference value t_ref is the number of counts
>> +		 * between -62 °C and 20 °C (82 °C range).
> Roll this info into the maths and only have the constants set in the switch
> statement.  Even better if you just move them into chip specific data so
> look them up directly rather than via a switch of devid.  The whole driver
> would benefit from moving this stuff to const data rather than switch
> statements all over the place.
> 
> 	int min_temp_x10 = yas5xx->chip_info.min_temp_x10;
> 	const int ref_temp_x10 = 200;
> 
> 	*to = (min_temp_x10 + ((ref_temp_x10 - min_temp_x10) * t / t_ref)) * 100;
> 
> That should make the code self explanatory and remove need for the comments.

I'll have a look and will try to implement this.

...

Kind regards,
Jakob

  reply	other threads:[~2022-06-21  0:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1655509425.git.jahau.ref@rocketmail.com>
2022-06-18  0:13 ` [PATCH v3 0/8] Add support for magnetometer Yamaha YAS537 Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 1/8] iio: magnetometer: yas530: Change data type of hard_offsets to signed Jakob Hauser
2022-06-18 14:18     ` Jonathan Cameron
2022-06-21  0:36       ` Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 2/8] iio: magnetometer: yas530: Change range of data in volatile register Jakob Hauser
2022-06-18 14:21     ` Jonathan Cameron
2022-06-21  0:39       ` Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 3/8] iio: magnetometer: yas530: Correct scaling of magnetic axes Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 4/8] iio: magnetometer: yas530: Correct temperature handling Jakob Hauser
2022-06-18 14:53     ` Jonathan Cameron
2022-06-21  0:48       ` Jakob Hauser [this message]
2022-06-25 14:14         ` Jonathan Cameron
2022-06-18  0:13   ` [PATCH v3 5/8] iio: magnetometer: yas530: Change data type of calibration coefficients Jakob Hauser
2022-06-18 14:56     ` Jonathan Cameron
2022-06-21  0:51       ` Jakob Hauser
2022-06-22  8:49         ` Linus Walleij
2022-06-26  7:51         ` Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 6/8] iio: magnetometer: yas530: Rename functions and registers Jakob Hauser
2022-06-18 15:00     ` Jonathan Cameron
2022-06-21  0:53       ` Jakob Hauser
2022-06-21  8:51         ` Andy Shevchenko
2022-06-25 14:16         ` Jonathan Cameron
2022-06-26  8:39           ` Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 7/8] iio: magnetometer: yas530: Apply minor cleanups Jakob Hauser
2022-06-18  9:53     ` Andy Shevchenko
2022-06-21  0:57       ` Jakob Hauser
2022-06-18  0:13   ` [PATCH v3 8/8] iio: magnetometer: yas530: Add YAS537 variant Jakob Hauser
2022-06-18 10:57     ` Andy Shevchenko
2022-06-21  1:10       ` Jakob Hauser
2022-06-18 15:28     ` Jonathan Cameron
2022-06-19 10:32       ` Andy Shevchenko
2022-06-19 10:58         ` Jonathan Cameron
2022-06-21  1:29       ` Jakob Hauser
2022-06-25 14:22         ` Jonathan Cameron

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=a348dbb6-8d4a-bcdb-e992-9b11e1c9f23f@rocketmail.com \
    --to=jahau@rocketmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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.