Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability"
measurement to complete. Attempting to read the result too early
triggers a NAK which then causes an EREMOTEIO error.
This behavior has been confirmed with a logic analyzer while running
the I2C bus at only 40kHz. The low frequency precludes any
signal-integrity issues, which was also confirmed by the absence of
any CRC8 errors. In this configuration, a NAK occurred on any read
that followed the measurement command within less than 8.2ms.
Signed-off-by: David Mosberger-Tang <[email protected]>
---
drivers/hwmon/sht4x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
index 09c2a0b06444..3415d7a0e0fc 100644
--- a/drivers/hwmon/sht4x.c
+++ b/drivers/hwmon/sht4x.c
@@ -23,7 +23,7 @@
/*
* I2C command delays (in microseconds)
*/
-#define SHT4X_MEAS_DELAY 1000
+#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */
#define SHT4X_DELAY_EXTRA 10000
/*
@@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data)
if (ret < 0)
goto unlock;
- usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA);
+ usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA);
ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH);
if (ret != SHT4X_RESPONSE_LENGTH) {
--
2.25.1
On 11/20/21 12:40 PM, David Mosberger-Tang wrote:
> Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability"
> measurement to complete. Attempting to read the result too early
> triggers a NAK which then causes an EREMOTEIO error.
>
> This behavior has been confirmed with a logic analyzer while running
> the I2C bus at only 40kHz. The low frequency precludes any
> signal-integrity issues, which was also confirmed by the absence of
> any CRC8 errors. In this configuration, a NAK occurred on any read
> that followed the measurement command within less than 8.2ms.
>
> Signed-off-by: David Mosberger-Tang <[email protected]>
You sent v2 after 5 minutes, and there is no change log.
Please never do that, and always provide a change log.
Guenter
> ---
> drivers/hwmon/sht4x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
> index 09c2a0b06444..3415d7a0e0fc 100644
> --- a/drivers/hwmon/sht4x.c
> +++ b/drivers/hwmon/sht4x.c
> @@ -23,7 +23,7 @@
> /*
> * I2C command delays (in microseconds)
> */
> -#define SHT4X_MEAS_DELAY 1000
> +#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */
> #define SHT4X_DELAY_EXTRA 10000
>
> /*
> @@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data)
> if (ret < 0)
> goto unlock;
>
> - usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA);
> + usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA);
>
> ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH);
> if (ret != SHT4X_RESPONSE_LENGTH) {
>
Repeat of previous patch but split into separate emails so the
device-tree bits can be sent to the proper group of maintainers, as
per Guenter's suggestion.
Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability"
measurement to complete. Attempting to read the result too early
triggers a NAK which then causes an EREMOTEIO error.
This behavior has been confirmed with a logic analyzer while running
the I2C bus at only 40kHz. The low frequency precludes any
signal-integrity issues, which was also confirmed by the absence of
any CRC8 errors. In this configuration, a NAK occurred on any read
that followed the measurement command within less than 8.2ms.
Signed-off-by: David Mosberger-Tang <[email protected]>
---
drivers/hwmon/sht4x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
index 09c2a0b06444..3415d7a0e0fc 100644
--- a/drivers/hwmon/sht4x.c
+++ b/drivers/hwmon/sht4x.c
@@ -23,7 +23,7 @@
/*
* I2C command delays (in microseconds)
*/
-#define SHT4X_MEAS_DELAY 1000
+#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */
#define SHT4X_DELAY_EXTRA 10000
/*
@@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data)
if (ret < 0)
goto unlock;
- usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA);
+ usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA);
ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH);
if (ret != SHT4X_RESPONSE_LENGTH) {
--
2.25.1
On Sat, Nov 20, 2021 at 09:28:53PM +0000, David Mosberger-Tang wrote:
> Repeat of previous patch but split into separate emails so the
> device-tree bits can be sent to the proper group of maintainers, as
> per Guenter's suggestion.
>
Another rule: Never send a follow-up patch series as reply to a
previous one; otherwise it might get lost.
Also, if you send a single patch, there is not need for an
introduction patch like this one.
Thanks,
Guenter
On Sat, Nov 20, 2021 at 09:28:56PM +0000, David Mosberger-Tang wrote:
> Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability"
> measurement to complete. Attempting to read the result too early
> triggers a NAK which then causes an EREMOTEIO error.
>
> This behavior has been confirmed with a logic analyzer while running
> the I2C bus at only 40kHz. The low frequency precludes any
> signal-integrity issues, which was also confirmed by the absence of
> any CRC8 errors. In this configuration, a NAK occurred on any read
> that followed the measurement command within less than 8.2ms.
>
> Signed-off-by: David Mosberger-Tang <[email protected]>
Applied.
Thanks,
Guenter
> ---
> drivers/hwmon/sht4x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
> index 09c2a0b06444..3415d7a0e0fc 100644
> --- a/drivers/hwmon/sht4x.c
> +++ b/drivers/hwmon/sht4x.c
> @@ -23,7 +23,7 @@
> /*
> * I2C command delays (in microseconds)
> */
> -#define SHT4X_MEAS_DELAY 1000
> +#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */
> #define SHT4X_DELAY_EXTRA 10000
>
> /*
> @@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data)
> if (ret < 0)
> goto unlock;
>
> - usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA);
> + usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA);
>
> ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH);
> if (ret != SHT4X_RESPONSE_LENGTH) {