| Message ID | 20210601092805.18385-1-Meng.Li@windriver.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | driver: adc: ltc2497: return directly after reading the adc conversion value | expand |
On Tue, 1 Jun 2021 17:28:05 +0800 Meng.Li@windriver.com wrote: > From: Meng Li <Meng.Li@windriver.com> > > 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. > In order to keep the code logic is the same with original ideal, > it is need to return direct after reading the adc conversion value. > > v2: > According to ltc2497 datasheet, the max value of conversion time is > 149.9 ms. So, add 20% to the 150msecs so that there is enough time > for data conversion. Version change logs go below the --- as we don't want to preserve them forever in the git history. I may have lost track of the discussion, but I thought the idea was that perhaps the longer time period would remove the need for the early return? Thanks, Jonathan > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a separate module ") > Cc: stable@vger.kernel.org > Signed-off-by: Meng Li <Meng.Li@windriver.com> > --- > drivers/iio/adc/ltc2497.c | 2 ++ > drivers/iio/adc/ltc2497.h | 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > index 1adddf5a88a9..fd5a66860a47 100644 > --- a/drivers/iio/adc/ltc2497.c > +++ b/drivers/iio/adc/ltc2497.c > @@ -41,6 +41,8 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata, > } > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > + > + return ret; > } > > ret = i2c_smbus_write_byte(st->client, > diff --git a/drivers/iio/adc/ltc2497.h b/drivers/iio/adc/ltc2497.h > index d0b42dd6b8ad..e451930837d8 100644 > --- a/drivers/iio/adc/ltc2497.h > +++ b/drivers/iio/adc/ltc2497.h > @@ -2,7 +2,7 @@ > > #define LTC2497_ENABLE 0xA0 > #define LTC2497_CONFIG_DEFAULT LTC2497_ENABLE > -#define LTC2497_CONVERSION_TIME_MS 150ULL > +#define LTC2497_CONVERSION_TIME_MS 180ULL > > struct ltc2497core_driverdata { > struct regulator *ref;
> -----Original Message----- > From: Jonathan Cameron <jic23@kernel.org> > Sent: Friday, June 4, 2021 12:20 AM > To: Li, Meng <Meng.Li@windriver.com> > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 > Meng.Li@windriver.com wrote: > > > From: Meng Li <Meng.Li@windriver.com> > > > > 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. > > In order to keep the code logic is the same with original ideal, it is > > need to return direct after reading the adc conversion value. > > > > v2: > > According to ltc2497 datasheet, the max value of conversion time is > > 149.9 ms. So, add 20% to the 150msecs so that there is enough time for > > data conversion. > > Version change logs go below the --- as we don't want to preserve them > forever in the git history. > > I may have lost track of the discussion, but I thought the idea was that > perhaps the longer time period would remove the need for the early return? > No! I think the ret is essential. Because when call i2c_master_recv() to receive data from chip, there is a stop bit sent to chip at the last step. When the chip receive the stop bit, it will start the next conversion operation. So, if we send any command on I2C bus when the chip is in conversion status, there will be a i2c error occurred. Thanks, Limeng > Thanks, > > Jonathan > > > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent > > part in a separate module ") > > Cc: stable@vger.kernel.org > > Signed-off-by: Meng Li <Meng.Li@windriver.com> > > --- > > drivers/iio/adc/ltc2497.c | 2 ++ > > drivers/iio/adc/ltc2497.h | 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > > index 1adddf5a88a9..fd5a66860a47 100644 > > --- a/drivers/iio/adc/ltc2497.c > > +++ b/drivers/iio/adc/ltc2497.c > > @@ -41,6 +41,8 @@ static int ltc2497_result_and_measure(struct > ltc2497core_driverdata *ddata, > > } > > > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > > + > > + return ret; > > } > > > > ret = i2c_smbus_write_byte(st->client, diff --git > > a/drivers/iio/adc/ltc2497.h b/drivers/iio/adc/ltc2497.h index > > d0b42dd6b8ad..e451930837d8 100644 > > --- a/drivers/iio/adc/ltc2497.h > > +++ b/drivers/iio/adc/ltc2497.h > > @@ -2,7 +2,7 @@ > > > > #define LTC2497_ENABLE 0xA0 > > #define LTC2497_CONFIG_DEFAULT LTC2497_ENABLE > > -#define LTC2497_CONVERSION_TIME_MS 150ULL > > +#define LTC2497_CONVERSION_TIME_MS 180ULL > > > > struct ltc2497core_driverdata { > > struct regulator *ref;
Hello, On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > -----Original Message----- > > From: Jonathan Cameron <jic23@kernel.org> > > Sent: Friday, June 4, 2021 12:20 AM > > To: Li, Meng <Meng.Li@windriver.com> > > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 > > Meng.Li@windriver.com wrote: > > > > > From: Meng Li <Meng.Li@windriver.com> > > > > > > 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. > > > In order to keep the code logic is the same with original ideal, it is > > > need to return direct after reading the adc conversion value. As background about the choice of the .result_and_measure callback: A difference between the ltc2497 (i2c) and ltc2496 (spi) is that for the latter reading the result of the last conversion and starting a new is a single bus operation and the one cannot be done without the other. > > > v2: > > > According to ltc2497 datasheet, the max value of conversion time is > > > 149.9 ms. So, add 20% to the 150msecs so that there is enough time for > > > data conversion. > > > > Version change logs go below the --- as we don't want to preserve them > > forever in the git history. > > > > I may have lost track of the discussion, but I thought the idea was that > > perhaps the longer time period would remove the need for the early return? > > > > No! > I think the ret is essential. I'd like to understand why. Currently ltc2497core_read() looks as follows (simplified by dropping error handling, and unrolling the result_and_measure callback for the i2c case): ltc2497core_wait_conv() // result_and_measure(address, NULL) i2c_smbus_write_byte(client, LTC2497_ENABLE | address); msleep_interruptible(LTC2497_CONVERSION_TIME_MS) // result_and_measure(address, val); i2c_master_recv(client, &buf, 3); i2c_smbus_write_byte(client, LTC2497_ENABLE | address); With the early return you suggest to introduce with your patch you save the last i2c_smbus_write_byte call. The data sheet indeed claims to start a new conversion at the stop condition. So either the reading of the conversion result and programming of the (maybe) new address has to be done in a single i2c transfer, or we have to do something like your patch. What I don't like about your approach is that it changes the semantic of the callback to result_*or*_measure which is something the spi variant cannot implement. With the current use of the function this is fine, however if at some time in the future we implement a bulk conversion shortcut this hurts. So I suggest to do: ---->8---- From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Date: Fri, 4 Jun 2021 08:02:44 +0200 Subject: [PATCH] iio: ltc2497: Fix reading conversion results After the result of the previous conversion is read the chip automatically starts a new conversion and doesn't accept new i2c transfers until this conversion is completed which makes the function return failure. So add an early return iff the programming of the new address isn't needed. Note this will not fix the problem in general, but all cases that are currently used. Once this changes we get the failure back, but this can be addressed when the need arises. Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a separate module ") Reported-by: Meng Li <Meng.Li@windriver.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/iio/adc/ltc2497.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c --- a/drivers/iio/adc/ltc2497.c +++ b/drivers/iio/adc/ltc2497.c @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata, } *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); + + /* + * The part started a new conversion at the end of the above i2c + * transfer, so if the address didn't change since the last call + * everything is fine and we can return early. + * If not (which should only happen when some sort of bulk + * conversion is implemented) we have to program the new + * address. Note that this probably fails as the conversion that + * was triggered above is like not complete yet and the two + * operations have to be done in a single transfer. + */ + if (ddata->addr_prev == address) + return 0; } ret = i2c_smbus_write_byte(st->client, Compared to Meng Li's patch this doesn't introduce reporting of bogus conversion results once we implement bulk conversion. Best regards Uwe
> -----Original Message----- > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Sent: Friday, June 4, 2021 2:13 PM > To: Li, Meng <Meng.Li@windriver.com> > Cc: Jonathan Cameron <jic23@kernel.org>; lars@metafoo.de; > Michael.Hennerich@analog.com; 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 > > Hello, > > On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > > > > -----Original Message----- > > > From: Jonathan Cameron <jic23@kernel.org> > > > Sent: Friday, June 4, 2021 12:20 AM > > > To: Li, Meng <Meng.Li@windriver.com> > > > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > > > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 > > > Meng.Li@windriver.com wrote: > > > > > > > From: Meng Li <Meng.Li@windriver.com> > > > > > > > > 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. > > > > In order to keep the code logic is the same with original ideal, > > > > it is need to return direct after reading the adc conversion value. > > As background about the choice of the .result_and_measure callback: > A difference between the ltc2497 (i2c) and ltc2496 (spi) is that for the latter > reading the result of the last conversion and starting a new is a single bus > operation and the one cannot be done without the other. > > > > > v2: > > > > According to ltc2497 datasheet, the max value of conversion time > > > > is > > > > 149.9 ms. So, add 20% to the 150msecs so that there is enough time > > > > for data conversion. > > > > > > Version change logs go below the --- as we don't want to preserve > > > them forever in the git history. > > > > > > I may have lost track of the discussion, but I thought the idea was > > > that perhaps the longer time period would remove the need for the early > return? > > > > > > > No! > > I think the ret is essential. > > I'd like to understand why. Currently ltc2497core_read() looks as follows > (simplified by dropping error handling, and unrolling the result_and_measure > callback for the i2c case): > > ltc2497core_wait_conv() > > // result_and_measure(address, NULL) > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > msleep_interruptible(LTC2497_CONVERSION_TIME_MS) > > // result_and_measure(address, val); > i2c_master_recv(client, &buf, 3); > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > With the early return you suggest to introduce with your patch you save the > last i2c_smbus_write_byte call. The data sheet indeed claims to start a new > conversion at the stop condition. > > So either the reading of the conversion result and programming of the > (maybe) new address has to be done in a single i2c transfer, or we have to do > something like your patch. > > What I don't like about your approach is that it changes the semantic of the > callback to result_*or*_measure which is something the spi variant cannot > implement. With the current use of the function this is fine, however if at > some time in the future we implement a bulk conversion shortcut this hurts. > > So I suggest to do: > > ---->8---- > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Date: Fri, 4 Jun 2021 08:02:44 +0200 > Subject: [PATCH] iio: ltc2497: Fix reading conversion results > > After the result of the previous conversion is read the chip automatically > starts a new conversion and doesn't accept new i2c transfers until this > conversion is completed which makes the function return failure. > > So add an early return iff the programming of the new address isn't needed. > Note this will not fix the problem in general, but all cases that are currently > used. Once this changes we get the failure back, but this can be addressed > when the need arises. > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a > separate module ") > Reported-by: Meng Li <Meng.Li@windriver.com> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > drivers/iio/adc/ltc2497.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > --- a/drivers/iio/adc/ltc2497.c > +++ b/drivers/iio/adc/ltc2497.c > @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct > ltc2497core_driverdata *ddata, > } > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > + > + /* > + * The part started a new conversion at the end of the above > i2c > + * transfer, so if the address didn't change since the last call > + * everything is fine and we can return early. > + * If not (which should only happen when some sort of bulk > + * conversion is implemented) we have to program the new > + * address. Note that this probably fails as the conversion > that > + * was triggered above is like not complete yet and the two > + * operations have to be done in a single transfer. > + */ > + if (ddata->addr_prev == address) > + return 0; > } > > ret = i2c_smbus_write_byte(st->client, > > Compared to Meng Li's patch this doesn't introduce reporting of bogus > conversion results once we implement bulk conversion. > Ok! Understand. I agree you to push patch to upstream and it is more reasonable that the original author to fix this issue. Thanks, Limeng > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri, 4 Jun 2021 06:43:20 +0000 "Li, Meng" <Meng.Li@windriver.com> wrote: > > -----Original Message----- > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > Sent: Friday, June 4, 2021 2:13 PM > > To: Li, Meng <Meng.Li@windriver.com> > > Cc: Jonathan Cameron <jic23@kernel.org>; lars@metafoo.de; > > Michael.Hennerich@analog.com; 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 > > > > Hello, > > > > On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > > > > > > > -----Original Message----- > > > > From: Jonathan Cameron <jic23@kernel.org> > > > > Sent: Friday, June 4, 2021 12:20 AM > > > > To: Li, Meng <Meng.Li@windriver.com> > > > > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > > > > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 > > > > Meng.Li@windriver.com wrote: > > > > > > > > > From: Meng Li <Meng.Li@windriver.com> > > > > > > > > > > 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. > > > > > In order to keep the code logic is the same with original ideal, > > > > > it is need to return direct after reading the adc conversion value. > > > > As background about the choice of the .result_and_measure callback: > > A difference between the ltc2497 (i2c) and ltc2496 (spi) is that for the latter > > reading the result of the last conversion and starting a new is a single bus > > operation and the one cannot be done without the other. > > > > > > > v2: > > > > > According to ltc2497 datasheet, the max value of conversion time > > > > > is > > > > > 149.9 ms. So, add 20% to the 150msecs so that there is enough time > > > > > for data conversion. > > > > > > > > Version change logs go below the --- as we don't want to preserve > > > > them forever in the git history. > > > > > > > > I may have lost track of the discussion, but I thought the idea was > > > > that perhaps the longer time period would remove the need for the early > > return? > > > > > > > > > > No! > > > I think the ret is essential. > > > > I'd like to understand why. Currently ltc2497core_read() looks as follows > > (simplified by dropping error handling, and unrolling the result_and_measure > > callback for the i2c case): > > > > ltc2497core_wait_conv() > > > > // result_and_measure(address, NULL) > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > msleep_interruptible(LTC2497_CONVERSION_TIME_MS) > > > > // result_and_measure(address, val); > > i2c_master_recv(client, &buf, 3); > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > With the early return you suggest to introduce with your patch you save the > > last i2c_smbus_write_byte call. The data sheet indeed claims to start a new > > conversion at the stop condition. > > > > So either the reading of the conversion result and programming of the > > (maybe) new address has to be done in a single i2c transfer, or we have to do > > something like your patch. > > > > What I don't like about your approach is that it changes the semantic of the > > callback to result_*or*_measure which is something the spi variant cannot > > implement. With the current use of the function this is fine, however if at > > some time in the future we implement a bulk conversion shortcut this hurts. > > > > So I suggest to do: > > > > ---->8---- > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > Date: Fri, 4 Jun 2021 08:02:44 +0200 > > Subject: [PATCH] iio: ltc2497: Fix reading conversion results > > > > After the result of the previous conversion is read the chip automatically > > starts a new conversion and doesn't accept new i2c transfers until this > > conversion is completed which makes the function return failure. > > > > So add an early return iff the programming of the new address isn't needed. > > Note this will not fix the problem in general, but all cases that are currently > > used. Once this changes we get the failure back, but this can be addressed > > when the need arises. > > > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a > > separate module ") > > Reported-by: Meng Li <Meng.Li@windriver.com> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > --- > > drivers/iio/adc/ltc2497.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > > --- a/drivers/iio/adc/ltc2497.c > > +++ b/drivers/iio/adc/ltc2497.c > > @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct > > ltc2497core_driverdata *ddata, > > } > > > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > > + > > + /* > > + * The part started a new conversion at the end of the above > > i2c > > + * transfer, so if the address didn't change since the last call > > + * everything is fine and we can return early. > > + * If not (which should only happen when some sort of bulk > > + * conversion is implemented) we have to program the new > > + * address. Note that this probably fails as the conversion > > that > > + * was triggered above is like not complete yet and the two > > + * operations have to be done in a single transfer. > > + */ I'm a little confused by this comment. It seems to say it will fail if we ever do have a different address? That doesn't seem very helpful... J > > + if (ddata->addr_prev == address) > > + return 0; > > } > > > > ret = i2c_smbus_write_byte(st->client, > > > > Compared to Meng Li's patch this doesn't introduce reporting of bogus > > conversion results once we implement bulk conversion. > > > > Ok! > Understand. > I agree you to push patch to upstream and it is more reasonable that the original author to fix this issue. > > Thanks, > Limeng > > > Best regards > > Uwe > > > > -- > > Pengutronix e.K. | Uwe Kleine-König | > > Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri, Jun 04, 2021 at 09:20:43AM +0100, Jonathan Cameron wrote: > On Fri, 4 Jun 2021 06:43:20 +0000 > "Li, Meng" <Meng.Li@windriver.com> wrote: > > > > -----Original Message----- > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > Sent: Friday, June 4, 2021 2:13 PM > > > To: Li, Meng <Meng.Li@windriver.com> > > > Cc: Jonathan Cameron <jic23@kernel.org>; lars@metafoo.de; > > > Michael.Hennerich@analog.com; 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 > > > > > > Hello, > > > > > > On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Cameron <jic23@kernel.org> > > > > > Sent: Friday, June 4, 2021 12:20 AM > > > > > To: Li, Meng <Meng.Li@windriver.com> > > > > > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > > > > > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 > > > > > Meng.Li@windriver.com wrote: > > > > > > > > > > > From: Meng Li <Meng.Li@windriver.com> > > > > > > > > > > > > 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. > > > > > > In order to keep the code logic is the same with original ideal, > > > > > > it is need to return direct after reading the adc conversion value. > > > > > > As background about the choice of the .result_and_measure callback: > > > A difference between the ltc2497 (i2c) and ltc2496 (spi) is that for the latter > > > reading the result of the last conversion and starting a new is a single bus > > > operation and the one cannot be done without the other. > > > > > > > > > v2: > > > > > > According to ltc2497 datasheet, the max value of conversion time > > > > > > is > > > > > > 149.9 ms. So, add 20% to the 150msecs so that there is enough time > > > > > > for data conversion. > > > > > > > > > > Version change logs go below the --- as we don't want to preserve > > > > > them forever in the git history. > > > > > > > > > > I may have lost track of the discussion, but I thought the idea was > > > > > that perhaps the longer time period would remove the need for the early > > > return? > > > > > > > > > > > > > No! > > > > I think the ret is essential. > > > > > > I'd like to understand why. Currently ltc2497core_read() looks as follows > > > (simplified by dropping error handling, and unrolling the result_and_measure > > > callback for the i2c case): > > > > > > ltc2497core_wait_conv() > > > > > > // result_and_measure(address, NULL) > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > msleep_interruptible(LTC2497_CONVERSION_TIME_MS) > > > > > > // result_and_measure(address, val); > > > i2c_master_recv(client, &buf, 3); > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > > > > With the early return you suggest to introduce with your patch you save the > > > last i2c_smbus_write_byte call. The data sheet indeed claims to start a new > > > conversion at the stop condition. > > > > > > So either the reading of the conversion result and programming of the > > > (maybe) new address has to be done in a single i2c transfer, or we have to do > > > something like your patch. > > > > > > What I don't like about your approach is that it changes the semantic of the > > > callback to result_*or*_measure which is something the spi variant cannot > > > implement. With the current use of the function this is fine, however if at > > > some time in the future we implement a bulk conversion shortcut this hurts. > > > > > > So I suggest to do: > > > > > > ---->8---- > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > Date: Fri, 4 Jun 2021 08:02:44 +0200 > > > Subject: [PATCH] iio: ltc2497: Fix reading conversion results > > > > > > After the result of the previous conversion is read the chip automatically > > > starts a new conversion and doesn't accept new i2c transfers until this > > > conversion is completed which makes the function return failure. > > > > > > So add an early return iff the programming of the new address isn't needed. > > > Note this will not fix the problem in general, but all cases that are currently > > > used. Once this changes we get the failure back, but this can be addressed > > > when the need arises. > > > > > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a > > > separate module ") > > > Reported-by: Meng Li <Meng.Li@windriver.com> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > --- > > > drivers/iio/adc/ltc2497.c | 13 +++++++++++++ > > > 1 file changed, 13 insertions(+) > > > > > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > > > --- a/drivers/iio/adc/ltc2497.c > > > +++ b/drivers/iio/adc/ltc2497.c > > > @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct > > > ltc2497core_driverdata *ddata, > > > } > > > > > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > > > + > > > + /* > > > + * The part started a new conversion at the end of the above i2c > > > + * transfer, so if the address didn't change since the last call > > > + * everything is fine and we can return early. > > > + * If not (which should only happen when some sort of bulk > > > + * conversion is implemented) we have to program the new > > > + * address. Note that this probably fails as the conversion that > > > + * was triggered above is like not complete yet and the two > > > + * operations have to be done in a single transfer. > > > + */ > > I'm a little confused by this comment. It seems to say it will fail if we > ever do have a different address? That doesn't seem very helpful... It's not a real problem in the sense that it triggers today. If you want to read out (say) the channels 1, 5, 6 and 7, you could do: start conversion for channel 1 wait for the conversion to complete read out conversion for channel 1 and start channel 5 wait for the conversion to complete read out conversion for channel 5 and start channel 6 wait for the conversion to complete read out conversion for channel 6 and start channel 7 wait for the conversion to complete read out conversion for channel 7 With this procedure the step "read out conversion for channel X and start channel Y" has to (and can) be done in a single transfer. But the status quo is, that when these channels are to be read the following happens: start conversion for channel 1 wait for the conversion to complete read out conversion for channel 1 and (implicitly) start another conversion for channel 1 wait for the conversion to complete start conversion for channel 5 wait for the conversion to complete read out conversion for channel 5 and (implicitly) start another conversion for channel 5 wait for the conversion to complete ... and ltc2497_result_and_measure is well suited to handle this. So maybe reword the comment to: The part started a new conversion at the end of the above i2c transfer. With the current implementation of how reading is implemented in ltc2497core it never happens that this new conversion should be done for a different channel which would require writing a new channel address. (Actually writing such a new address requires more effort, either another delay must be added or the now two transfers must be combined into a single one.) So check the assumption that the channel really didn't change and then return early which does the right thing today. ? Best regards Uwe
> -----Original Message----- > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Sent: Friday, June 4, 2021 4:53 PM > To: Jonathan Cameron <jic23@kernel.org> > Cc: Li, Meng <Meng.Li@windriver.com>; lars@metafoo.de; > Michael.Hennerich@analog.com; 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 > > On Fri, Jun 04, 2021 at 09:20:43AM +0100, Jonathan Cameron wrote: > > On Fri, 4 Jun 2021 06:43:20 +0000 > > "Li, Meng" <Meng.Li@windriver.com> wrote: > > > > > > -----Original Message----- > > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > Sent: Friday, June 4, 2021 2:13 PM > > > > To: Li, Meng <Meng.Li@windriver.com> > > > > Cc: Jonathan Cameron <jic23@kernel.org>; lars@metafoo.de; > > > > Michael.Hennerich@analog.com; 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 > > > > > > > > Hello, > > > > > > > > On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Cameron <jic23@kernel.org> > > > > > > Sent: Friday, June 4, 2021 12:20 AM > > > > > > To: Li, Meng <Meng.Li@windriver.com> > > > > > > Cc: lars@metafoo.de; Michael.Hennerich@analog.com; > > > > > > pmeerw@pmeerw.net; u.kleine-koenig@pengutronix.de; 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 Tue, 1 Jun 2021 17:28:05 +0800 Meng.Li@windriver.com > > > > > > wrote: > > > > > > > > > > > > > From: Meng Li <Meng.Li@windriver.com> > > > > > > > > > > > > > > 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. > > > > > > > In order to keep the code logic is the same with original > > > > > > > ideal, it is need to return direct after reading the adc conversion > value. > > > > > > > > As background about the choice of the .result_and_measure callback: > > > > A difference between the ltc2497 (i2c) and ltc2496 (spi) is that > > > > for the latter reading the result of the last conversion and > > > > starting a new is a single bus operation and the one cannot be done > without the other. > > > > > > > > > > > v2: > > > > > > > According to ltc2497 datasheet, the max value of conversion > > > > > > > time is > > > > > > > 149.9 ms. So, add 20% to the 150msecs so that there is > > > > > > > enough time for data conversion. > > > > > > > > > > > > Version change logs go below the --- as we don't want to > > > > > > preserve them forever in the git history. > > > > > > > > > > > > I may have lost track of the discussion, but I thought the > > > > > > idea was that perhaps the longer time period would remove the > > > > > > need for the early > > > > return? > > > > > > > > > > > > > > > > No! > > > > > I think the ret is essential. > > > > > > > > I'd like to understand why. Currently ltc2497core_read() looks as > > > > follows (simplified by dropping error handling, and unrolling the > > > > result_and_measure callback for the i2c case): > > > > > > > > ltc2497core_wait_conv() > > > > > > > > // result_and_measure(address, NULL) > > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > > > msleep_interruptible(LTC2497_CONVERSION_TIME_MS) > > > > > > > > // result_and_measure(address, val); > > > > i2c_master_recv(client, &buf, 3); > > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > > > > > > > With the early return you suggest to introduce with your patch you > > > > save the last i2c_smbus_write_byte call. The data sheet indeed > > > > claims to start a new conversion at the stop condition. > > > > > > > > So either the reading of the conversion result and programming of > > > > the > > > > (maybe) new address has to be done in a single i2c transfer, or we > > > > have to do something like your patch. > > > > > > > > What I don't like about your approach is that it changes the > > > > semantic of the callback to result_*or*_measure which is something > > > > the spi variant cannot implement. With the current use of the > > > > function this is fine, however if at some time in the future we > implement a bulk conversion shortcut this hurts. > > > > > > > > So I suggest to do: > > > > > > > > ---->8---- > > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > Date: Fri, 4 Jun 2021 08:02:44 +0200 > > > > Subject: [PATCH] iio: ltc2497: Fix reading conversion results > > > > > > > > After the result of the previous conversion is read the chip > > > > automatically starts a new conversion and doesn't accept new i2c > > > > transfers until this conversion is completed which makes the function > return failure. > > > > > > > > So add an early return iff the programming of the new address isn't > needed. > > > > Note this will not fix the problem in general, but all cases that > > > > are currently used. Once this changes we get the failure back, but > > > > this can be addressed when the need arises. > > > > > > > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol > > > > independent part in a separate module ") > > > > Reported-by: Meng Li <Meng.Li@windriver.com> > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > --- > > > > drivers/iio/adc/ltc2497.c | 13 +++++++++++++ > > > > 1 file changed, 13 insertions(+) > > > > > > > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > > > > --- a/drivers/iio/adc/ltc2497.c > > > > +++ b/drivers/iio/adc/ltc2497.c > > > > @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct > > > > ltc2497core_driverdata *ddata, > > > > } > > > > > > > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > > > > + > > > > + /* > > > > + * The part started a new conversion at the end of the above > i2c > > > > + * transfer, so if the address didn't change since the last call > > > > + * everything is fine and we can return early. > > > > + * If not (which should only happen when some sort of bulk > > > > + * conversion is implemented) we have to program the new > > > > + * address. Note that this probably fails as the conversion > that > > > > + * was triggered above is like not complete yet and the two > > > > + * operations have to be done in a single transfer. > > > > + */ > > > > I'm a little confused by this comment. It seems to say it will fail > > if we ever do have a different address? That doesn't seem very helpful... > > It's not a real problem in the sense that it triggers today. If you want to read > out (say) the channels 1, 5, 6 and 7, you could do: > > start conversion for channel 1 > wait for the conversion to complete > read out conversion for channel 1 and start channel 5 > wait for the conversion to complete > read out conversion for channel 5 and start channel 6 > wait for the conversion to complete > read out conversion for channel 6 and start channel 7 > wait for the conversion to complete > read out conversion for channel 7 > Have you tested above case on real hardware? Or only a inference based on data sheet? Thanks. Limeng > With this procedure the step "read out conversion for channel X and start > channel Y" has to (and can) be done in a single transfer. But the status quo is, > that when these channels are to be read the following > happens: > > start conversion for channel 1 > wait for the conversion to complete > read out conversion for channel 1 and (implicitly) start another > conversion for channel 1 > > wait for the conversion to complete > > start conversion for channel 5 > wait for the conversion to complete > read out conversion for channel 5 and (implicitly) start another > conversion for channel 5 > > wait for the conversion to complete > > ... > > and ltc2497_result_and_measure is well suited to handle this. > > So maybe reword the comment to: > > The part started a new conversion at the end of the above i2c > transfer. With the current implementation of how reading is > implemented in ltc2497core it never happens that this new > conversion should be done for a different channel which would > require writing a new channel address. (Actually writing such a > new address requires more effort, either another delay must be > added or the now two transfers must be combined into a single > one.) > > So check the assumption that the channel really didn't change > and then return early which does the right thing today. > > ? > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri, Jun 04, 2021 at 09:04:48AM +0000, Li, Meng wrote: > > On Fri, Jun 04, 2021 at 09:20:43AM +0100, Jonathan Cameron wrote: > > > On Fri, 4 Jun 2021 06:43:20 +0000 > > > "Li, Meng" <Meng.Li@windriver.com> wrote: > > > > > On Fri, Jun 04, 2021 at 02:16:39AM +0000, Li, Meng wrote: > > > > > > I think the ret is essential. > > > > > > > > > > I'd like to understand why. Currently ltc2497core_read() looks as > > > > > follows (simplified by dropping error handling, and unrolling the > > > > > result_and_measure callback for the i2c case): > > > > > > > > > > ltc2497core_wait_conv() > > > > > > > > > > // result_and_measure(address, NULL) > > > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > > > > > msleep_interruptible(LTC2497_CONVERSION_TIME_MS) > > > > > > > > > > // result_and_measure(address, val); > > > > > i2c_master_recv(client, &buf, 3); > > > > > i2c_smbus_write_byte(client, LTC2497_ENABLE | address); > > > > > > > > > > > > > > > With the early return you suggest to introduce with your patch you > > > > > save the last i2c_smbus_write_byte call. The data sheet indeed > > > > > claims to start a new conversion at the stop condition. > > > > > > > > > > So either the reading of the conversion result and programming of > > > > > the > > > > > (maybe) new address has to be done in a single i2c transfer, or we > > > > > have to do something like your patch. > > > > > > > > > > What I don't like about your approach is that it changes the > > > > > semantic of the callback to result_*or*_measure which is something > > > > > the spi variant cannot implement. With the current use of the > > > > > function this is fine, however if at some time in the future we > > > > > implement a bulk conversion shortcut this hurts. > > > > > > > > > > So I suggest to do: > > > > > > > > > > ---->8---- > > > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > > Date: Fri, 4 Jun 2021 08:02:44 +0200 > > > > > Subject: [PATCH] iio: ltc2497: Fix reading conversion results > > > > > > > > > > After the result of the previous conversion is read the chip > > > > > automatically starts a new conversion and doesn't accept new i2c > > > > > transfers until this conversion is completed which makes the function return failure. > > > > > > > > > > So add an early return iff the programming of the new address isn't needed. > > > > > Note this will not fix the problem in general, but all cases that > > > > > are currently used. Once this changes we get the failure back, but > > > > > this can be addressed when the need arises. > > > > > > > > > > Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol > > > > > independent part in a separate module ") > > > > > Reported-by: Meng Li <Meng.Li@windriver.com> > > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > > > > --- > > > > > drivers/iio/adc/ltc2497.c | 13 +++++++++++++ > > > > > 1 file changed, 13 insertions(+) > > > > > > > > > > diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c > > > > > --- a/drivers/iio/adc/ltc2497.c > > > > > +++ b/drivers/iio/adc/ltc2497.c > > > > > @@ -41,6 +41,19 @@ static int ltc2497_result_and_measure(struct > > > > > ltc2497core_driverdata *ddata, > > > > > } > > > > > > > > > > *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); > > > > > + > > > > > + /* > > > > > + * The part started a new conversion at the end of the above i2c > > > > > + * transfer, so if the address didn't change since the last call > > > > > + * everything is fine and we can return early. > > > > > + * If not (which should only happen when some sort of bulk > > > > > + * conversion is implemented) we have to program the new > > > > > + * address. Note that this probably fails as the conversion that > > > > > + * was triggered above is like not complete yet and the two > > > > > + * operations have to be done in a single transfer. > > > > > + */ > > > > > > I'm a little confused by this comment. It seems to say it will fail > > > if we ever do have a different address? That doesn't seem very helpful... > > > > It's not a real problem in the sense that it triggers today. If you want to read > > out (say) the channels 1, 5, 6 and 7, you could do: > > > > start conversion for channel 1 > > wait for the conversion to complete > > read out conversion for channel 1 and start channel 5 > > wait for the conversion to complete > > read out conversion for channel 5 and start channel 6 > > wait for the conversion to complete > > read out conversion for channel 6 and start channel 7 > > wait for the conversion to complete > > read out conversion for channel 7 > > Have you tested above case on real hardware? Or only a inference based on data sheet? I never had the ltc2497 in my hands, but the customer I created my patches for uses the ltc2496 (i.e. its spi variant) and did the above from userspace using spidev. And I'm confident enough to claim that if your patch fixes your problem, then mine does it, too. Best regards Uwe
diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c index 1adddf5a88a9..fd5a66860a47 100644 --- a/drivers/iio/adc/ltc2497.c +++ b/drivers/iio/adc/ltc2497.c @@ -41,6 +41,8 @@ static int ltc2497_result_and_measure(struct ltc2497core_driverdata *ddata, } *val = (be32_to_cpu(st->buf) >> 14) - (1 << 17); + + return ret; } ret = i2c_smbus_write_byte(st->client, diff --git a/drivers/iio/adc/ltc2497.h b/drivers/iio/adc/ltc2497.h index d0b42dd6b8ad..e451930837d8 100644 --- a/drivers/iio/adc/ltc2497.h +++ b/drivers/iio/adc/ltc2497.h @@ -2,7 +2,7 @@ #define LTC2497_ENABLE 0xA0 #define LTC2497_CONFIG_DEFAULT LTC2497_ENABLE -#define LTC2497_CONVERSION_TIME_MS 150ULL +#define LTC2497_CONVERSION_TIME_MS 180ULL struct ltc2497core_driverdata { struct regulator *ref;