From: Meng Li <[email protected]>
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.
Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a separate module ")
Cc: [email protected]
Signed-off-by: Meng Li <[email protected]>
---
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;
--
2.17.1
On Tue, 1 Jun 2021 17:28:05 +0800
[email protected] wrote:
> From: Meng Li <[email protected]>
>
> 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: [email protected]
> Signed-off-by: Meng Li <[email protected]>
> ---
> 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 <[email protected]>
> Sent: Friday, June 4, 2021 12:20 AM
> To: Li, Meng <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> 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
> [email protected] wrote:
>
> > From: Meng Li <[email protected]>
> >
> > 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: [email protected]
> > Signed-off-by: Meng Li <[email protected]>
> > ---
> > 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 <[email protected]>
> > Sent: Friday, June 4, 2021 12:20 AM
> > To: Li, Meng <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; [email protected]
> > 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
> > [email protected] wrote:
> >
> > > From: Meng Li <[email protected]>
> > >
> > > 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Uwe Kleine-K?nig <[email protected]>
---
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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
> -----Original Message-----
> From: Uwe Kleine-K?nig <[email protected]>
> Sent: Friday, June 4, 2021 2:13 PM
> To: Li, Meng <[email protected]>
> Cc: Jonathan Cameron <[email protected]>; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> 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 <[email protected]>
> > > Sent: Friday, June 4, 2021 12:20 AM
> > > To: Li, Meng <[email protected]>
> > > Cc: [email protected]; [email protected];
> > > [email protected]; [email protected]; linux-
> > > [email protected]; [email protected]
> > > 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
> > > [email protected] wrote:
> > >
> > > > From: Meng Li <[email protected]>
> > > >
> > > > 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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Uwe Kleine-K?nig <[email protected]>
> ---
> 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" <[email protected]> wrote:
> > -----Original Message-----
> > From: Uwe Kleine-König <[email protected]>
> > Sent: Friday, June 4, 2021 2:13 PM
> > To: Li, Meng <[email protected]>
> > Cc: Jonathan Cameron <[email protected]>; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; [email protected]
> > 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 <[email protected]>
> > > > Sent: Friday, June 4, 2021 12:20 AM
> > > > To: Li, Meng <[email protected]>
> > > > Cc: [email protected]; [email protected];
> > > > [email protected]; [email protected]; linux-
> > > > [email protected]; [email protected]
> > > > 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
> > > > [email protected] wrote:
> > > >
> > > > > From: Meng Li <[email protected]>
> > > > >
> > > > > 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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: Uwe Kleine-König <[email protected]>
> > ---
> > 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" <[email protected]> wrote:
>
> > > -----Original Message-----
> > > From: Uwe Kleine-K?nig <[email protected]>
> > > Sent: Friday, June 4, 2021 2:13 PM
> > > To: Li, Meng <[email protected]>
> > > Cc: Jonathan Cameron <[email protected]>; [email protected];
> > > [email protected]; [email protected]; linux-
> > > [email protected]; [email protected]
> > > 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 <[email protected]>
> > > > > Sent: Friday, June 4, 2021 12:20 AM
> > > > > To: Li, Meng <[email protected]>
> > > > > Cc: [email protected]; [email protected];
> > > > > [email protected]; [email protected]; linux-
> > > > > [email protected]; [email protected]
> > > > > 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
> > > > > [email protected] wrote:
> > > > >
> > > > > > From: Meng Li <[email protected]>
> > > > > >
> > > > > > 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 <[email protected]>
> > > 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 <[email protected]>
> > > Signed-off-by: Uwe Kleine-K?nig <[email protected]>
> > > ---
> > > 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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
> -----Original Message-----
> From: Uwe Kleine-K?nig <[email protected]>
> Sent: Friday, June 4, 2021 4:53 PM
> To: Jonathan Cameron <[email protected]>
> Cc: Li, Meng <[email protected]>; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> 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" <[email protected]> wrote:
> >
> > > > -----Original Message-----
> > > > From: Uwe Kleine-K?nig <[email protected]>
> > > > Sent: Friday, June 4, 2021 2:13 PM
> > > > To: Li, Meng <[email protected]>
> > > > Cc: Jonathan Cameron <[email protected]>; [email protected];
> > > > [email protected]; [email protected]; linux-
> > > > [email protected]; [email protected]
> > > > 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 <[email protected]>
> > > > > > Sent: Friday, June 4, 2021 12:20 AM
> > > > > > To: Li, Meng <[email protected]>
> > > > > > Cc: [email protected]; [email protected];
> > > > > > [email protected]; [email protected]; linux-
> > > > > > [email protected]; [email protected]
> > > > > > 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 [email protected]
> > > > > > wrote:
> > > > > >
> > > > > > > From: Meng Li <[email protected]>
> > > > > > >
> > > > > > > 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 <[email protected]>
> > > > 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 <[email protected]>
> > > > Signed-off-by: Uwe Kleine-K?nig <[email protected]>
> > > > ---
> > > > 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" <[email protected]> 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 <[email protected]>
> > > > > 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 <[email protected]>
> > > > > Signed-off-by: Uwe Kleine-K?nig <[email protected]>
> > > > > ---
> > > > > 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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |