From: Justin Chen <[email protected]>
To read a channel we require 3 cycles to send, process, and receive
the data. The transfer buffer for the third transaction is left blank.
This leaves it up to the SPI driver to decide what to do.
In one particular case, if the tx buffer is not set the spi driver
sets it to 0xff. This puts the ADC in a alarm programming state,
therefore the following read to a channel becomes erroneous.
Instead of leaving us to the mercy of the SPI driver, we send the
ADC cmd on the third transaction to prevent inconsistent behavior.
Signed-off-by: Justin Chen <[email protected]>
---
drivers/iio/adc/ti-ads7950.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
index 0ad6359..5453e10 100644
--- a/drivers/iio/adc/ti-ads7950.c
+++ b/drivers/iio/adc/ti-ads7950.c
@@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi)
st->scan_single_xfer[1].tx_buf = &st->single_tx;
st->scan_single_xfer[1].len = 2;
st->scan_single_xfer[1].cs_change = 1;
+ st->scan_single_xfer[2].rx_buf = &st->single_tx;
st->scan_single_xfer[2].rx_buf = &st->single_rx;
st->scan_single_xfer[2].len = 2;
--
2.7.4
Hi Justin,
On 1/24/19 5:56 PM, [email protected] wrote:
> From: Justin Chen <[email protected]>
>
> To read a channel we require 3 cycles to send, process, and receive
> the data. The transfer buffer for the third transaction is left blank.
> This leaves it up to the SPI driver to decide what to do.
>
> In one particular case, if the tx buffer is not set the spi driver
> sets it to 0xff. This puts the ADC in a alarm programming state,
> therefore the following read to a channel becomes erroneous.
>
> Instead of leaving us to the mercy of the SPI driver, we send the
> ADC cmd on the third transaction to prevent inconsistent behavior.
Do you think this warrants a Fixes: tag?
>
> Signed-off-by: Justin Chen <[email protected]>
> ---
> drivers/iio/adc/ti-ads7950.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> index 0ad6359..5453e10 100644
> --- a/drivers/iio/adc/ti-ads7950.c
> +++ b/drivers/iio/adc/ti-ads7950.c
> @@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi)
> st->scan_single_xfer[1].tx_buf = &st->single_tx;
> st->scan_single_xfer[1].len = 2;
> st->scan_single_xfer[1].cs_change = 1;
> + st->scan_single_xfer[2].rx_buf = &st->single_tx;
Should this be st->scan_single_xfer[2].tx_buf?
> st->scan_single_xfer[2].rx_buf = &st->single_rx;
> st->scan_single_xfer[2].len = 2;
>
>
--
Florian
Hello Florian
On Thu, Jan 24, 2019 at 8:30 PM Florian Fainelli <[email protected]> wrote:
>
>
> Hi Justin,
>
> On 1/24/19 5:56 PM, [email protected] wrote:
> > From: Justin Chen <[email protected]>
> >
> > To read a channel we require 3 cycles to send, process, and receive
> > the data. The transfer buffer for the third transaction is left blank.
> > This leaves it up to the SPI driver to decide what to do.
> >
> > In one particular case, if the tx buffer is not set the spi driver
> > sets it to 0xff. This puts the ADC in a alarm programming state,
> > therefore the following read to a channel becomes erroneous.
> >
> > Instead of leaving us to the mercy of the SPI driver, we send the
> > ADC cmd on the third transaction to prevent inconsistent behavior.
>
> Do you think this warrants a Fixes: tag?
>
This was an issue when the driver was introduced. Should I tag that
commit the introduced the driver?
> >
> > Signed-off-by: Justin Chen <[email protected]>
> > ---
> > drivers/iio/adc/ti-ads7950.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> > index 0ad6359..5453e10 100644
> > --- a/drivers/iio/adc/ti-ads7950.c
> > +++ b/drivers/iio/adc/ti-ads7950.c
> > @@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi)
> > st->scan_single_xfer[1].tx_buf = &st->single_tx;
> > st->scan_single_xfer[1].len = 2;
> > st->scan_single_xfer[1].cs_change = 1;
> > + st->scan_single_xfer[2].rx_buf = &st->single_tx;
>
> Should this be st->scan_single_xfer[2].tx_buf?
>
Oh yes. Good catch. Careless mistake! v2 incoming.
> > st->scan_single_xfer[2].rx_buf = &st->single_rx;
> > st->scan_single_xfer[2].len = 2;
> >
> >
>
> --
> Florian