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 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.