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;
> +}
> +
next prev parent 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