diff options
author | John Brooks <john@fastquake.com> | 2017-01-18 21:50:39 +0000 |
---|---|---|
committer | Jonathan Cameron <jic23@kernel.org> | 2017-01-22 13:35:40 +0000 |
commit | 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27 (patch) | |
tree | caf374a799c6c5f8bdf865d7fc0e936e9685f4ca /include/dt-bindings/interrupt-controller/mips-gic.h | |
parent | d1aaf20ee655888c227d5137b7a63551f8d15416 (diff) |
iio: dht11: Use usleep_range instead of msleep for start signal
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%
Cc: stable@vger.kernel.org
Signed-off-by: John Brooks <john@fastquake.com>
Reviewed-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Diffstat (limited to 'include/dt-bindings/interrupt-controller/mips-gic.h')
0 files changed, 0 insertions, 0 deletions