linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Li, Meng" <Meng.Li@windriver.com>
To: "Felix Knopf" <knopf@vh-s.de>,
	"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:36:43 +0000	[thread overview]
Message-ID: <PH0PR11MB51912636A22942C6F08DE117F1259@PH0PR11MB5191.namprd11.prod.outlook.com> (raw)
In-Reply-To: <45829810-7921-3150-6df1-c19ffcb2ae6f@vh-s.de>



> -----Original Message-----
> From: Felix Knopf <knopf@vh-s.de>
> Sent: Tuesday, May 25, 2021 4:23 PM
> To: Li, Meng <Meng.Li@windriver.com>; Uwe Kleine-König <u.kleine-
> koenig@pengutronix.de>
> Cc: lars@metafoo.de; Michael.Hennerich@analog.com; jic23@kernel.org;
> pmeerw@pmeerw.net; linux-kernel@vger.kernel.org; linux-
> iio@vger.kernel.org
> Subject: Re: [PATCH] driver: adc: ltc2497: return directly after reading the adc
> conversion value
> 
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> >> 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.

Hi Felix,

Thanks for your new ideal firstly. I will test your patch in later.
I had a look your patch, and I found out there is no essential difference from my patch.
You put the step 4 in the else branch, I think it is the same effective with my return solution.

In additional, about the high sample rates, you pointed out that my patch will skip the step1
But I check the ltc2497 datasheet
https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
in page 18, there is a "Consecutive Reading with the Same Input/Configuration" mode, I think it is able to read data continuously without setting channel address every time.

Thanks,
Limeng

> @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;
>  }

  reply	other threads:[~2021-05-25 10:38 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
2021-05-25 10:36       ` Li, Meng [this message]
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=PH0PR11MB51912636A22942C6F08DE117F1259@PH0PR11MB5191.namprd11.prod.outlook.com \
    --to=meng.li@windriver.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=jic23@kernel.org \
    --cc=knopf@vh-s.de \
    --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).