Skip to contentSkip to conversation

Patch "iio: dht11: Use usleep_range instead of msleep for start signal" has been added to the 4.9-stable tree

PATCH [email protected] 1 participant 1 message Feb 5, 2017

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

iio: dht11: Use usleep_range instead of msleep for start signal

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
iio-dht11-use-usleep_range-instead-of-msleep-for-start-signal.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27 Mon Sep 17 00:00:00 2001

From: John Brooks <[email protected]>
Date: Wed, 18 Jan 2017 21:50:39 +0000
Subject: iio: dht11: Use usleep_range instead of msleep for start signal

From: John Brooks <[email protected]>

commit 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27 upstream.

The DHT22 (AM2302) datasheet specifies that the LOW start pulse should not exceed 20ms. However, observations with an oscilloscope of an RPi Model 2B (rev 1.1) communicating with a DHT22 sensor showed that the driver was consistently sending start pulses longer than 20ms:

Kernel 4.7.10-v7+ (n=132):
Minimum pulse length: 20.20ms
Maximum: 29.84ms
Mean: 24.96ms
StDev: 2.82ms
Sensor response rate: 100%
Read success rate: 76%

On kernel 4.8, the start pulse was so long that the sensor would not even respond 97% of the time:

Kernel 4.8.16-v7+ (n=100):
Minimum pulse length: 30.4ms
Maximum: 74.4ms
Mean: 39.3ms
StDev: 10.2ms
Sensor response rate: 3%
Read success rate: 3%

The driver would return ETIMEDOUT and write log messages like this:

[   51.430987] dht11 dht11@0: Only 1 signal edges detected
[   66.311019] dht11 dht11@0: Only 0 signal edges detected

Replacing msleep(18) with usleep_range(18000, 20000) made the pulse length sane again and restored responsiveness:

Kernel 4.8.16-v7+ with usleep_range (n=123):
Minimum pulse length: 18.16ms
Maximum: 20.20ms
Mean: 19.85ms
StDev: 0.51ms
Sensor response rate: 100%
Read success rate: 84%

---
 drivers/iio/humidity/dht11.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/iio/humidity/dht11.c +4 -2
@@ -71,7 +71,8 @@
  * a) select an implementation using busy loop polling on those systems
  * b) use the checksum to do some probabilistic decoding
  */
-#define DHT11_START_TRANSMISSION	18  /* ms */
+#define DHT11_START_TRANSMISSION_MIN	18000  /* us */
+#define DHT11_START_TRANSMISSION_MAX	20000  /* us */
 #define DHT11_MIN_TIMERES	34000  /* ns */
 #define DHT11_THRESHOLD		49000  /* ns */
 #define DHT11_AMBIG_LOW		23000  /* ns */
@@ -228,7 +229,8 @@ static int dht11_read_raw(struct iio_dev
 		ret = gpio_direction_output(dht11->gpio, 0);
 		if (ret)
 			goto err;
-		msleep(DHT11_START_TRANSMISSION);
+		usleep_range(DHT11_START_TRANSMISSION_MIN,
+			     DHT11_START_TRANSMISSION_MAX);
 		ret = gpio_direction_input(dht11->gpio);
 		if (ret)
 			goto err;

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/iio-dht11-use-usleep_range-instead-of-msleep-for-start-signal.patch