Message ID | 20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp771102vqb; Thu, 26 Oct 2023 08:45:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEj9bWqW/K0A3mTKRR+RuOOKlCOH90IiaykBfSIoNn5xIJgszngKRyOwMyMPaIRDdLmC62s X-Received: by 2002:a05:6870:9a87:b0:1bf:df47:7b5e with SMTP id hp7-20020a0568709a8700b001bfdf477b5emr23538764oab.16.1698335140885; Thu, 26 Oct 2023 08:45:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698335140; cv=none; d=google.com; s=arc-20160816; b=SWe2voR3Ct3u44UV8AnEnIkVeH3HAS0rVxRybOvyI94MmQxpVV52NmXng95f0ZZxUv TpziKYKikgo8UJWEuMkcZwyWTtVyddjxS8dLlsQL/WAdpMZGFH44AlAQHWn3sp3AbEeV ihlTaAXV4mBlIt1ZGIBEOGp0Id3Pp1/eLN4UUAAP/DcYGS94y1KcTeDL46oZDL7LzFbY KMJpLoNAlO5mMDUxiXhNVNyXXrS5S90bDbObYgKzTBQk6DkIdQu0MqDmUKWNyXZkx+E5 EpGAoS4LLfSN+A1Dl50XlqIBMOYDPkDMhdHRdb3+zr4ajfViNwyOGQuImVOZV+SDqdMJ +7MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=BOqZewXxQGVP1NcocKVuNRkU9OFyXGemHQI6cQ9yNks=; fh=vJ+ckRlyrG6nFR7c0ZcGMhzTwp7HFEfK4lMdjSFwYAc=; b=uUsg2/+rTQm4q39fABUmSDh46xtWi/azFB2ModAJiPlzq4ba6rH7rmclt3VdS7COPt d5cr/Hi6ztNVrZ0HQ9gap+2gtnkd4GhOYRwvwKH9s2K0lA6krO94liOuDCoF75SjvEBo jS0y/DSQ1y4oSMvCVniCV7Oo7fWvPCeeTULGUsRvL3u6+fBB9AZxsvc68MxmpDDwvVq0 fbIyuMIunArOOUbnpFiF2AeBnjyfuAKR24PL7pPi85XeMTW9l35jHgoq3UI6Uh37vB1P +K37cfWqjP22GxjU549TdkUEuUeuFukHC7w0aW8r/YqirZ8iTFBLzfepdejUdMaBelOA wQ7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EyJe4ebS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id t11-20020a25460b000000b00d86a6df0617si12352453yba.725.2023.10.26.08.45.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 08:45:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EyJe4ebS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 45DB5807EBA5; Thu, 26 Oct 2023 08:45:08 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345468AbjJZPo5 (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Thu, 26 Oct 2023 11:44:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231280AbjJZPoz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Oct 2023 11:44:55 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 648F7196; Thu, 26 Oct 2023 08:44:53 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-9c53e8b7cf4so170807466b.1; Thu, 26 Oct 2023 08:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698335092; x=1698939892; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=BOqZewXxQGVP1NcocKVuNRkU9OFyXGemHQI6cQ9yNks=; b=EyJe4ebSgtQW89MTIf5Rtl6pAASHtePBqfA2YIvG1lBEuYnO+tdCzGLALWqry7SfFD gCdOya0C5boXXYG2ZbMLmXYKPy3kHGn09zvElnMrCSCM6pb3cqeIVk0roZtJ70tlQda6 ldLZzasrN5+28qtkeV9ns8rO/ZEHbN0f5j8PUaiRaN10rxUccE8IqSrjAibaEC/aH/q1 kRQVm95viQO1/6bdBY0XP0KFjaxk0MPrGRiXR6jVFCt+eSLuVdXPHV0E12m2Dc/rISRD T1JLBV7vlA25Z38xZCV9paaFd6RkzQB7TbR3GCY+8KaVuTmMQUB6zpSLecxdk4/9TgSI 6pkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698335092; x=1698939892; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BOqZewXxQGVP1NcocKVuNRkU9OFyXGemHQI6cQ9yNks=; b=uG0VYWeEbeFe9hMioFB+wLZCAAKaTfyoahfsdQJMRE87Ds1Ruojb+gUTfXVhgyf1/1 SjVnvz5tCzZD+b0mEGmhfZJ19vaeoKiQguJhLmy5G5Jl8ZLCoxV3LelPYGNgLTgJJEfq gDnVPVd8fQDo+BqB4RGG7XBCnIAxOguHmEqOIuj8VlZ5QDM8TVJSmUWsXUDbOpn6lOow VhKBbMoE+qMo/iNemafhyuURGuKliXakQGjc0bmrCF6eb7JHjEVzcj4UtUljw9V7Ub86 xLoaFWOTEN4bLV5WkUNQf2irBrlqk91SnwoEbMdYSZcuqMgvbbZn92fLjKzHtd1KM6Mr A8Mg== X-Gm-Message-State: AOJu0Ywpsik4os3pNMMnsHlH5je4sBSvHPtG1iyOoQlxCwGIwh1TL3TC rL5Cj0kh0mSJ1rXSaSmcpJhYv+rZ1b5Hqw== X-Received: by 2002:a17:907:a03:b0:9bf:889e:32a4 with SMTP id bb3-20020a1709070a0300b009bf889e32a4mr43387ejc.54.1698335091602; Thu, 26 Oct 2023 08:44:51 -0700 (PDT) Received: from [127.0.1.1] (2a02-8389-41cf-e200-aa18-f9fe-f627-2a46.cable.dynamic.v6.surfer.at. [2a02:8389:41cf:e200:aa18:f9fe:f627:2a46]) by smtp.gmail.com with ESMTPSA id n17-20020a170906841100b009c8b720cf59sm8331164ejx.42.2023.10.26.08.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 08:44:51 -0700 (PDT) From: Javier Carrasco <javier.carrasco.cruz@gmail.com> Date: Thu, 26 Oct 2023 17:44:49 +0200 Subject: [PATCH] iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com> X-B4-Tracking: v=1; b=H4sIAHCJOmUC/x2NQQrDIBRErxL+uoIaSNNepZRg7KT+RTR8bSiE3 L3a5eMxbw7KEEame3eQYOfMKVYwl458cPENxa/KZLXtjbaDKmljr0L5WDP5FHdIm0yFV6gb3Gg wDlfdL1QLs8tQs7joQ2usLhdIE5tg4e//9vE8zx9aM49KhgAAAA== To: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, William Markezana <william.markezana@meas-spec.com>, Ludovic Tancerel <ludovic.tancerel@maplehightech.com> Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Javier Carrasco <javier.carrasco.cruz@gmail.com> X-Mailer: b4 0.12.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1698335090; l=4449; i=javier.carrasco.cruz@gmail.com; s=20230509; h=from:subject:message-id; bh=8iImRaAF6cpsowlFJX62gZM3TPXl66xs7q2hHDrIAkk=; b=2mcpbQsmBS2XjpaRDf036urt72rxf6gtyy25oLE2pfF8dJKutOcZswYf8URTLU4Pq20/P4BZi L+mLBnl8LcrA6Xqp2tPmEv8E/1XcwFmqLvP9HNmhSZR9vTueKfM6bsy X-Developer-Key: i=javier.carrasco.cruz@gmail.com; a=ed25519; pk=tIGJV7M+tCizagNijF0eGMBGcOsPD+0cWGfKjl4h6K8= X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 26 Oct 2023 08:45:08 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780833468151742530 X-GMAIL-MSGID: 1780833468151742530 |
Series |
iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table
|
|
Commit Message
Javier Carrasco
Oct. 26, 2023, 3:44 p.m. UTC
The HTU21 offers 4 sampling frequencies: 20, 40, 70 and 120, which are
associated to an index that is used to select the right measurement
resolution and its corresponding measurement time. The current
implementation selects the measurement resolution and the temperature
measurement time properly, but it does not select the right humidity
measurement time in all cases.
In summary, the 40 and 70 humidity measurement times are swapped.
The reason for that is probably the unusual coding for the measurement
resolution. According to the datasheet, the bits [7,0] of the "user
register" are used as follows to select the bit resolution:
--------------------------------------------------
| Bit 7 | Bit 0 | RH | Temp | Trh (us) | Tt (us) |
--------------------------------------------------
| 0 | 0 | 12 | 14 | 16000 | 50000 |
--------------------------------------------------
| 0 | 1 | 8 | 12 | 3000 | 13000 |
--------------------------------------------------
| 1 | 0 | 10 | 13 | 5000 | 25000 |
--------------------------------------------------
| 1 | 1 | 11 | 11 | 8000 | 7000 |
--------------------------------------------------
*This table is available in the official datasheet, page 13/21. I have
just appended the times provided in the humidity/temperature tables,
pages 3/21, 5/21. Note that always a pair of resolutions is selected.
The sampling frequencies [20, 40, 70, 120] are assigned to a linear
index [0..3] which is then coded as follows [1]:
Index [7,0]
--------------
idx 0 0,0
idx 1 1,0
idx 2 0,1
idx 3 1,1
That is done that way because the temperature measurements are being
used as the reference for the sampling frequency (the frequencies and
the temperature measurement times are correlated), so increasing the
index always reduces the temperature measurement time and its
resolution. Therefore, the temperature measurement time array is as
simple as [50000, 25000, 13000, 7000]
On the other hand, the humidity resolution cannot follow the same
pattern because of the way it is coded in the "user register", where
both resolutions are selected at the same time. The humidity measurement
time array is the following: [16000, 3000, 5000, 8000], which defines
the following assignments:
Index [7,0] Trh
-----------------------
idx 0 0,0 16000 -> right, [0,0] selects 12 bits (Trh = 16000)
idx 1 1,0 3000 -> wrong! [1,0] selects 10 bits (Trh = 5000)
idx 2 0,1 5000 -> wrong! [0,1] selects 8 bits (Trh = 3000)
idx 3 1,1 8000 -> right, [1,1] selects 11 bits (Trh = 8000)
The times have been ordered as if idx = 1 -> [0,1] and idx = 2 -> [1,0],
which is not the case for the reason explained above.
So a simple modification is required to obtain the right humidity
measurement time array, swapping the values in the positions 1 and 2.
The right table should be the following: [16000, 5000, 3000, 8000]
Fix the humidity measurement time array with the right idex/value
coding.
[1] The actual code that makes this coding and assigns it to the current
value of the "user register" is the following:
config_reg &= 0x7E;
config_reg |= ((i & 1) << 7) + ((i & 2) >> 1);
Fixes: d574a87cc311 ("Add meas-spec sensors common part")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
drivers/iio/common/ms_sensors/ms_sensors_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 611da07b89fdd53f140d7b33013f255bf0ed8f34
change-id: 20231026-topic-htu21_conversion_time-9ea81e86703f
Best regards,
Comments
On Thu, 26 Oct 2023 17:44:49 +0200 Javier Carrasco <javier.carrasco.cruz@gmail.com> wrote: > The HTU21 offers 4 sampling frequencies: 20, 40, 70 and 120, which are > associated to an index that is used to select the right measurement > resolution and its corresponding measurement time. The current > implementation selects the measurement resolution and the temperature > measurement time properly, but it does not select the right humidity > measurement time in all cases. > > In summary, the 40 and 70 humidity measurement times are swapped. > > The reason for that is probably the unusual coding for the measurement > resolution. According to the datasheet, the bits [7,0] of the "user > register" are used as follows to select the bit resolution: > > -------------------------------------------------- > | Bit 7 | Bit 0 | RH | Temp | Trh (us) | Tt (us) | > -------------------------------------------------- > | 0 | 0 | 12 | 14 | 16000 | 50000 | > -------------------------------------------------- > | 0 | 1 | 8 | 12 | 3000 | 13000 | > -------------------------------------------------- > | 1 | 0 | 10 | 13 | 5000 | 25000 | > -------------------------------------------------- > | 1 | 1 | 11 | 11 | 8000 | 7000 | > -------------------------------------------------- > *This table is available in the official datasheet, page 13/21. I have > just appended the times provided in the humidity/temperature tables, > pages 3/21, 5/21. Note that always a pair of resolutions is selected. > > The sampling frequencies [20, 40, 70, 120] are assigned to a linear > index [0..3] which is then coded as follows [1]: > > Index [7,0] > -------------- > idx 0 0,0 > idx 1 1,0 > idx 2 0,1 > idx 3 1,1 > > That is done that way because the temperature measurements are being > used as the reference for the sampling frequency (the frequencies and > the temperature measurement times are correlated), so increasing the > index always reduces the temperature measurement time and its > resolution. Therefore, the temperature measurement time array is as > simple as [50000, 25000, 13000, 7000] > > On the other hand, the humidity resolution cannot follow the same > pattern because of the way it is coded in the "user register", where > both resolutions are selected at the same time. The humidity measurement > time array is the following: [16000, 3000, 5000, 8000], which defines > the following assignments: > > Index [7,0] Trh > ----------------------- > idx 0 0,0 16000 -> right, [0,0] selects 12 bits (Trh = 16000) > idx 1 1,0 3000 -> wrong! [1,0] selects 10 bits (Trh = 5000) > idx 2 0,1 5000 -> wrong! [0,1] selects 8 bits (Trh = 3000) > idx 3 1,1 8000 -> right, [1,1] selects 11 bits (Trh = 8000) > > The times have been ordered as if idx = 1 -> [0,1] and idx = 2 -> [1,0], > which is not the case for the reason explained above. > > So a simple modification is required to obtain the right humidity > measurement time array, swapping the values in the positions 1 and 2. > > The right table should be the following: [16000, 5000, 3000, 8000] > > Fix the humidity measurement time array with the right idex/value > coding. > > [1] The actual code that makes this coding and assigns it to the current > value of the "user register" is the following: > config_reg &= 0x7E; > config_reg |= ((i & 1) << 7) + ((i & 2) >> 1); > > Fixes: d574a87cc311 ("Add meas-spec sensors common part") > Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Good description. That's horrible :( Applied to the fixes-togreg branch of iio.git and marked for stable. Note however that I probably won't send a fixes pull request until after rc1 is out in about 3 weeks time. Thanks, Jonathan > --- > drivers/iio/common/ms_sensors/ms_sensors_i2c.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c > index 6633b35a94e6..9c9bc77003c7 100644 > --- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c > +++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c > @@ -15,8 +15,8 @@ > /* Conversion times in us */ > static const u16 ms_sensors_ht_t_conversion_time[] = { 50000, 25000, > 13000, 7000 }; > -static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 3000, > - 5000, 8000 }; > +static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 5000, > + 3000, 8000 }; > static const u16 ms_sensors_tp_conversion_time[] = { 500, 1100, 2100, > 4100, 8220, 16440 }; > > > --- > base-commit: 611da07b89fdd53f140d7b33013f255bf0ed8f34 > change-id: 20231026-topic-htu21_conversion_time-9ea81e86703f > > Best regards,
diff --git a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c index 6633b35a94e6..9c9bc77003c7 100644 --- a/drivers/iio/common/ms_sensors/ms_sensors_i2c.c +++ b/drivers/iio/common/ms_sensors/ms_sensors_i2c.c @@ -15,8 +15,8 @@ /* Conversion times in us */ static const u16 ms_sensors_ht_t_conversion_time[] = { 50000, 25000, 13000, 7000 }; -static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 3000, - 5000, 8000 }; +static const u16 ms_sensors_ht_h_conversion_time[] = { 16000, 5000, + 3000, 8000 }; static const u16 ms_sensors_tp_conversion_time[] = { 500, 1100, 2100, 4100, 8220, 16440 };