public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Rajat Khandelwal <rajat.khandelwal@linux.intel.com>
Cc: <jic23@kernel.org>, <lars@metafoo.de>,
	<linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>,
	<jdelvare@suse.com>, <linux@roeck-us.net>,
	<linux-hwmon@vger.kernel.org>, <rajat.khandelwal@intel.com>
Subject: Re: [PATCH v10] iio: temperature: Add driver support for Maxim MAX30208
Date: Thu, 17 Nov 2022 16:30:40 +0000	[thread overview]
Message-ID: <20221117163040.00001f5a@Huawei.com> (raw)
In-Reply-To: <20221118153729.762018-1-rajat.khandelwal@linux.intel.com>

On Fri, 18 Nov 2022 21:07:29 +0530
Rajat Khandelwal <rajat.khandelwal@linux.intel.com> wrote:

> Maxim MAX30208 is a digital temperature sensor with 0.1°C accuracy.
> 
> Add support for max30208 driver in iio subsystem.

Blank line here.

> Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX30208.pdf
> 
Datasheet part of the tags block, so no blank line between that and the SoB.
That makes life easy for tools parsing git messages.

> Signed-off-by: Rajat Khandelwal <rajat.khandelwal@linux.intel.com>

One query inline.  Basically boils down to what we do after
overflow occurs.  I assume you are right and the first reading is the most recent, but
I think we still want to flush the whole fifo in that case to get back to
a sane state for future reads.

Jonathan

> +/**
> + * max30208_request() - Request a reading
> + * @data: Struct comprising member elements of the device
> + *
> + * Requests a reading from the device and waits until the conversion is ready.
> + */
> +static int max30208_request(struct max30208_data *data)
> +{
> +	/*
> +	 * Sensor can take up to 500 ms to respond so execute a total of
> +	 * 10 retries to give the device sufficient time.
> +	 */
> +	int retries = 10;
> +	u8 regval;
> +	int ret;
> +
> +	ret = i2c_smbus_read_byte_data(data->client, MAX30208_TEMP_SENSOR_SETUP);
> +	if (ret < 0)
> +		return ret;
> +
> +	regval = ret | MAX30208_TEMP_SENSOR_SETUP_CONV;
> +
> +	ret = i2c_smbus_write_byte_data(data->client, MAX30208_TEMP_SENSOR_SETUP, regval);
> +	if (ret)
> +		return ret;
> +
> +	while (retries--) {
> +		ret = i2c_smbus_read_byte_data(data->client, MAX30208_STATUS);
> +		if (ret < 0)
> +			return ret;
> +
> +		if (ret & MAX30208_STATUS_TEMP_RDY)
> +			return 0;
> +
> +		msleep(50);
> +	}
> +	dev_err(&data->client->dev, "Temperature conversion failed\n");
> +
> +	return -ETIMEDOUT;
> +}
> +
> +static int max30208_update_temp(struct max30208_data *data)
> +{
> +	u8 data_count;
> +	int ret;
> +
> +	mutex_lock(&data->lock);
> +
> +	ret = max30208_request(data);
> +	if (ret)
> +		goto unlock;
> +
> +	ret = i2c_smbus_read_byte_data(data->client, MAX30208_FIFO_OVF_CNTR);
> +	if (ret < 0)
> +		goto unlock;
> +	else if (!ret) {
> +		ret = i2c_smbus_read_byte_data(data->client, MAX30208_FIFO_DATA_CNTR);
> +		if (ret < 0)
> +			goto unlock;
> +
> +		data_count = ret;
> +	} else
> +		data_count = 1;
> +
> +	while (data_count) {
> +		ret = i2c_smbus_read_word_swapped(data->client, MAX30208_FIFO_DATA);
> +		if (ret < 0)
> +			goto unlock;
> +
> +		data_count--;
> +	}
Hmm. Given you've been poking this a lot, I guess this works and the part is
as just odd. Just to check one last case... Does max30208_request() guarantee we can't
get...

1. Read first time, overflow set so we read latest result - leaving
   31 ancient values in the fifo.
2. Read again really quickly and get those ancient values.
?

Perhaps we should flush out those unwanted values from the fifo, so after
overflow we get back to a normal state rather than immediately overflowing again.

More than possible that I still don't understand how this device works though!

> +
> +unlock:
> +	mutex_unlock(&data->lock);
> +	return ret;
> +}
> +


  reply	other threads:[~2022-11-17 16:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 15:37 [PATCH v10] iio: temperature: Add driver support for Maxim MAX30208 Rajat Khandelwal
2022-11-17 16:30 ` Jonathan Cameron [this message]
     [not found]   ` <ed7b5e4e-cd3b-ab83-0b61-568b95656740@linux.intel.com>
2022-11-21 16:42     ` 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=20221117163040.00001f5a@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=jdelvare@suse.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rajat.khandelwal@intel.com \
    --cc=rajat.khandelwal@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox