From: Felix Knopf <knopf@vh-s.de>
To: "Li, Meng" <Meng.Li@windriver.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: "lars@metafoo.de" <lars@metafoo.de>,
"Michael.Hennerich@analog.com" <Michael.Hennerich@analog.com>,
"jic23@kernel.org" <jic23@kernel.org>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH] driver: adc: ltc2497: return directly after reading the adc conversion value
Date: Tue, 25 May 2021 10:22:36 +0200 [thread overview]
Message-ID: <45829810-7921-3150-6df1-c19ffcb2ae6f@vh-s.de> (raw)
In-Reply-To: <PH0PR11MB51913E1982E3208302CE29CCF1269@PH0PR11MB5191.namprd11.prod.outlook.com>
>> On Wed, May 12, 2021 at 12:57:25PM +0800, Meng.Li@windriver.com wrote:
>>> When read adc conversion value with below command:
>>> cat /sys/.../iio:device0/in_voltage0-voltage1_raw
>>> There is an error reported as below:
>>> ltc2497 0-0014: i2c transfer failed: -EREMOTEIO This i2c transfer
>>> issue is introduced by commit 69548b7c2c4f ("iio:
>>> adc: ltc2497: split protocol independent part in a separate module").
>>> When extract the common code into ltc2497-core.c, it change the code
>>> logic of function ltc2497core_read(). With wrong reading sequence, the
>>> action of enable adc channel is sent to chip again during adc channel
>>> is in conversion status. In this way, there is no ack from chip, and
>>> then cause i2c transfer failed.
Hi,
I came across the same or a very similar issue with the ltc2497 but took
a different approach to solve it. I suspect this issue is caused by a
suboptimal I2C access pattern.
The ltc2497 triggers a new conversion on the stop condition of
transactions addressed to it. As the chip cannot communicate during a
conversion, it will not ACK until it is finished. The current driver
produces the following sequence to read from an arbitrary channel:
ltc2497_result_and_measure(…, NULL);
1) S <ADDR> W A | <CONF> A | P (select channel)
2) [sleep 150ms] (wait for conversion)
ltc2497_result_and_measure(…, val);
3) S <ADDR> R A | <data> … | P (read data)
4) S <ADDR> W N | P (chip is busy, error)
Transaction 3 triggers a new conversion on the previously selected
channel and causes the following channel select (4) to fail. The
examples in the datasheet [1] make use of repeated start conditions to
prevent unintended triggers. In our case, 3 and 4 should be combined
into one transaction.
Limeng's patch sikps 4 which solves the problem but causes issues at
high sample rates, were 1 is skipped by the core.
I attached my ad-hoc solution below.
@Limeng: Could you test this with your hardware?
If there is interest, I will prepare a proper patch.
(Should that go into a new thread then?)
Regards, Felix
[1] https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf#page=18
--
Felix Knopf
von Hoerner & Sulger GmbH
https://vh-s.de
diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c
index 1adddf5a88a9..8968bf70859b 100644
--- a/drivers/iio/adc/ltc2497.c
+++ b/drivers/iio/adc/ltc2497.c
@@ -34,20 +34,23 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata,
int ret;
if (val) {
- ret = i2c_master_recv(st->client, (char *)&st->buf, 3);
+ ret = i2c_smbus_read_i2c_block_data(st->client,
+ LTC2497_ENABLE | address, 3,
+ (char *)&st->buf);
if (ret < 0) {
- dev_err(&st->client->dev, "i2c_master_recv failed\n");
+ dev_err(&st->client->dev, "i2c transfer failed\n");
return ret;
}
*val = (be32_to_cpu(st->buf) >> 14) - (1 << 17);
+ } else {
+ ret = i2c_smbus_write_byte(st->client,
+ LTC2497_ENABLE | address);
+ if (ret)
+ dev_err(&st->client->dev, "i2c write failed: %pe\n",
+ ERR_PTR(ret));
}
- ret = i2c_smbus_write_byte(st->client,
- LTC2497_ENABLE | address);
- if (ret)
- dev_err(&st->client->dev, "i2c transfer failed: %pe\n",
- ERR_PTR(ret));
return ret;
}
next prev parent reply other threads:[~2021-05-25 8:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 4:57 [PATCH] driver: adc: ltc2497: return directly after reading the adc conversion value Meng.Li
2021-05-18 17:46 ` Jonathan Cameron
2021-05-19 9:21 ` Uwe Kleine-König
2021-05-21 17:01 ` Jonathan Cameron
2021-05-24 2:49 ` Li, Meng
2021-05-25 8:19 ` Jonathan Cameron
2021-05-24 2:53 ` Li, Meng
2021-05-25 8:22 ` Felix Knopf [this message]
2021-05-25 10:36 ` Li, Meng
2021-06-01 9:28 Meng.Li
2021-06-03 16:20 ` Jonathan Cameron
2021-06-04 2:16 ` Li, Meng
2021-06-04 6:13 ` Uwe Kleine-König
2021-06-04 6:43 ` Li, Meng
2021-06-04 8:20 ` Jonathan Cameron
2021-06-04 8:53 ` Uwe Kleine-König
2021-06-04 9:04 ` Li, Meng
2021-06-04 9:32 ` Uwe Kleine-König
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=45829810-7921-3150-6df1-c19ffcb2ae6f@vh-s.de \
--to=knopf@vh-s.de \
--cc=Meng.Li@windriver.com \
--cc=Michael.Hennerich@analog.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=u.kleine-koenig@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).