Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1346272 > unrolled thread

Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 02:00 +0100
    Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Lucas De Marchi <lucas.de.marchi@gmail.com> - 2016-03-01 02:10 +0100
      Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 02:20 +0100
      Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 02:40 +0100
      Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 03:50 +0100
        Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support jic23@jic23.retrosnub.co.uk - 2016-03-01 09:40 +0100
          Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 17:10 +0100
            Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Jonathan Cameron <jic23@jic23.retrosnub.co.uk> - 2016-03-01 18:30 +0100
        Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Daniel Baluta <daniel.baluta@intel.com> - 2016-03-01 12:30 +0100
          Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Michael Welling <mwelling@ieee.org> - 2016-03-01 17:00 +0100

#1346272 — Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> The driver has sysfs readings with runtime PM support for power saving.
> It also offers buffer support that can be used together with IIO software
> triggers.
>

Daniel,

So I noticed something yesterday while testing new boards.
The channels are occassionally swapping when accessing data from multiple channels.

I wrote a simple bash script to demonstrate.

root@dragonboard-410c:~# cat test-analog.sh 
while [ 1 ]; do
voltage0=`cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw`
voltage1=`cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw`
voltage2=`cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw`
voltage3=`cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw`
echo ain0 = $voltage0 ain1 = $voltage1 ain2 = $voltage2 ain3 = $voltage3
done
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 266 ain1 = 291 ain2 = 268 ain3 = 291
ain0 = 287 ain1 = 294 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 294 ain2 = 286 ain3 = 0
ain0 = 285 ain1 = 288 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 287 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 293 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 290 ain3 = 291
ain0 = 287 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 288 ain3 = 0
ain0 = 285 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 285 ain3 = 0
ain0 = 287 ain1 = 293 ain2 = 289 ain3 = 292
ain0 = 288 ain1 = 292 ain2 = 287 ain3 = 293
ain0 = 286 ain1 = 287 ain2 = 289 ain3 = 0
ain0 = 283 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 288 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 290 ain3 = 0
ain0 = 289 ain1 = 291 ain2 = 287 ain3 = 0
ain0 = 284 ain1 = 286 ain2 = 292 ain3 = 0
ain0 = 286 ain1 = 291 ain2 = 289 ain3 = 292
ain0 = 284 ain1 = 292 ain2 = 291 ain3 = 291
ain0 = 285 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 289 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 288 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 288 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 288 ain3 = 288
ain0 = 289 ain1 = 292 ain2 = 289 ain3 = 293
ain0 = 287 ain1 = 292 ain2 = 290 ain3 = 0
ain0 = 286 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 290 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 285 ain2 = 292 ain3 = 0
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 0
ain0 = 287 ain1 = 287 ain2 = 287 ain3 = 0
ain0 = 287 ain1 = 291 ain2 = 287 ain3 = 291
ain0 = 288 ain1 = 291 ain2 = 290 ain3 = 293
ain0 = 285 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 289 ain2 = 289 ain3 = 292
ain0 = 286 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 0 ain1 = 287 ain2 = 291 ain3 = 0
ain0 = 287 ain1 = 286 ain2 = 291 ain3 = 0
ain0 = 288 ain1 = 286 ain2 = 289 ain3 = 0
ain0 = 284 ain1 = 289 ain2 = 288 ain3 = 0
ain0 = 287 ain1 = 290 ain2 = 287 ain3 = 292
ain0 = 285 ain1 = 292 ain2 = 289 ain3 = 292
ain0 = 289 ain1 = 292 ain2 = 290 ain3 = 0
.
.

The in_voltage3_raw channel is connected to GND the rest are left floating.
This does not happen if only one channels is accessed at a time.

I have not yet found the solution. Please left me know if this can be
duplicated on your end.

Regards,

Michael

[toc] | [next] | [standalone]

#1346274

On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
> On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
>> The driver has sysfs readings with runtime PM support for power saving.
>> It also offers buffer support that can be used together with IIO software
>> triggers.
>>
>
> Daniel,
>
> So I noticed something yesterday while testing new boards.
> The channels are occassionally swapping when accessing data from multiple channels.
>
> I wrote a simple bash script to demonstrate.

This happened to me in a previous version of the patch. I remember it
being fixed in the last version (or at least I could not reproduce).
I'll test again tomorrow with your script.

Lucas De Marchi

[toc] | [prev] | [next] | [standalone]

#1346277

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Okay thanks. I will see if I am using a dated version of the driver for some reason.
 
> Lucas De Marchi

[toc] | [prev] | [next] | [standalone]

#1346284

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Just verified that it is happening to me will the latest in linux-next.

root@dragonboard-410c:~# cat /proc/version 
Linux version 4.5.0-rc6-next-20160229+ (michael@deathstar) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Feb 29 19:27:11 CST 2016
root@dragonboard-410c:~# ./test-analog.sh 
ain0 = 267 ain1 = 286 ain2 = 268 ain3 = 288
ain0 = 283 ain1 = 284 ain2 = 284 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 285 ain2 = 287 ain3 = 0
ain0 = 282 ain1 = 284 ain2 = 287 ain3 = 0
ain0 = 283 ain1 = 284 ain2 = 286 ain3 = 0
ain0 = 283 ain1 = 290 ain2 = 285 ain3 = 288
ain0 = 284 ain1 = 286 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 285 ain3 = 0
ain0 = 0 ain1 = 286 ain2 = 287 ain3 = 0
ain0 = 0 ain1 = 284 ain2 = 289 ain3 = 0
.
.
 
> Lucas De Marchi

[toc] | [prev] | [next] | [standalone]

#1346317

On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> The driver has sysfs readings with runtime PM support for power saving.
> >> It also offers buffer support that can be used together with IIO software
> >> triggers.
> >>
> >
> > Daniel,
> >
> > So I noticed something yesterday while testing new boards.
> > The channels are occassionally swapping when accessing data from multiple channels.
> >
> > I wrote a simple bash script to demonstrate.
> 
> This happened to me in a previous version of the patch. I remember it
> being fixed in the last version (or at least I could not reproduce).
> I'll test again tomorrow with your script.
>

Here is what I believe is happening.

The request for a conversion on a new channel comes in while the conversion
for the previous channel is still converting. The driver waits approximately
one conversion cycle. The previous channel completes within this timeframe
and the MUX is changed and the new sample is started. The new sample is still
converting and the driver returns the value from the previous conversion.

For a test I multiplied the conv_time value by 2 in the ads1015_get_adc_result
function. This allows time for the current sample flush out and always returns
the appropriate channel's value.

Looking at the buffered mode it appears that only one channel is being accessed
at any time. This being the first one in the active_scan_mask found by
find_first_bit. So the MUX would never change is buffered mode as far I can
tell.

Don't we typically want to read all of enabled channels in buffered mode?
 
> Lucas De Marchi

[toc] | [prev] | [next] | [standalone]

#1346448

On 01.03.2016 02:42, Michael Welling wrote:
> On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
>> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> 
>> wrote:
>> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
>> >> The driver has sysfs readings with runtime PM support for power saving.
>> >> It also offers buffer support that can be used together with IIO software
>> >> triggers.
>> >>
>> >
>> > Daniel,
>> >
>> > So I noticed something yesterday while testing new boards.
>> > The channels are occassionally swapping when accessing data from multiple channels.
>> >
>> > I wrote a simple bash script to demonstrate.
>> 
>> This happened to me in a previous version of the patch. I remember it
>> being fixed in the last version (or at least I could not reproduce).
>> I'll test again tomorrow with your script.
>> 
> 
> Here is what I believe is happening.
> 
> The request for a conversion on a new channel comes in while the 
> conversion
> for the previous channel is still converting. The driver waits 
> approximately
> one conversion cycle. The previous channel completes within this 
> timeframe
> and the MUX is changed and the new sample is started. The new sample is 
> still
> converting and the driver returns the value from the previous 
> conversion.
> 
> For a test I multiplied the conv_time value by 2 in the 
> ads1015_get_adc_result
> function. This allows time for the current sample flush out and always 
> returns
> the appropriate channel's value.
> 
> Looking at the buffered mode it appears that only one channel is being 
> accessed
> at any time. This being the first one in the active_scan_mask found by
> find_first_bit. So the MUX would never change is buffered mode as far I 
> can
> tell.
> 
> Don't we typically want to read all of enabled channels in buffered 
> mode?
In some devices that is effectively impossible (fifo's that fill only 
from the currently
selected channel). That is what the onehot validation callback is about.
In this particular case it looks like doing a multichannel read is fair 
bit more time
consuming than a single channel read and so will result in a 
considerable reduction in
throughput.  This is of course why many parts include a simple 
sequencer!

Anyhow, supporting multi channel buffered reads could be done (probably) 
but you
would want to fall back to the single channel case as it is now.

Jonathan
>> Lucas De Marchi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1346721

On Tue, Mar 01, 2016 at 08:35:01AM +0000, jic23@jic23.retrosnub.co.uk wrote:
> On 01.03.2016 02:42, Michael Welling wrote:
> >On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >>On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org>
> >>wrote:
> >>> On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >>>> The driver has sysfs readings with runtime PM support for power saving.
> >>>> It also offers buffer support that can be used together with IIO software
> >>>> triggers.
> >>>>
> >>>
> >>> Daniel,
> >>>
> >>> So I noticed something yesterday while testing new boards.
> >>> The channels are occassionally swapping when accessing data from multiple channels.
> >>>
> >>> I wrote a simple bash script to demonstrate.
> >>
> >>This happened to me in a previous version of the patch. I remember it
> >>being fixed in the last version (or at least I could not reproduce).
> >>I'll test again tomorrow with your script.
> >>
> >
> >Here is what I believe is happening.
> >
> >The request for a conversion on a new channel comes in while the
> >conversion
> >for the previous channel is still converting. The driver waits
> >approximately
> >one conversion cycle. The previous channel completes within this timeframe
> >and the MUX is changed and the new sample is started. The new sample is
> >still
> >converting and the driver returns the value from the previous conversion.
> >
> >For a test I multiplied the conv_time value by 2 in the
> >ads1015_get_adc_result
> >function. This allows time for the current sample flush out and always
> >returns
> >the appropriate channel's value.
> >
> >Looking at the buffered mode it appears that only one channel is being
> >accessed
> >at any time. This being the first one in the active_scan_mask found by
> >find_first_bit. So the MUX would never change is buffered mode as far I
> >can
> >tell.
> >
> >Don't we typically want to read all of enabled channels in buffered mode?
> In some devices that is effectively impossible (fifo's that fill only from
> the currently
> selected channel). That is what the onehot validation callback is about.
> In this particular case it looks like doing a multichannel read is fair bit
> more time
> consuming than a single channel read and so will result in a considerable
> reduction in
> throughput.  This is of course why many parts include a simple sequencer!

Yes the sampling rate would effectively be divided by the number of channels
enabled.

> 
> Anyhow, supporting multi channel buffered reads could be done (probably) but
> you
> would want to fall back to the single channel case as it is now.

Understood.

> 
> Jonathan
> >>Lucas De Marchi
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1346793

On 1 March 2016 16:02:00 GMT+00:00, Michael Welling <mwelling@ieee.org> wrote:
>On Tue, Mar 01, 2016 at 08:35:01AM +0000, jic23@jic23.retrosnub.co.uk
>wrote:
>> On 01.03.2016 02:42, Michael Welling wrote:
>> >On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
>> >>On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling
><mwelling@ieee.org>
>> >>wrote:
>> >>> On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
>> >>>> The driver has sysfs readings with runtime PM support for power
>saving.
>> >>>> It also offers buffer support that can be used together with IIO
>software
>> >>>> triggers.
>> >>>>
>> >>>
>> >>> Daniel,
>> >>>
>> >>> So I noticed something yesterday while testing new boards.
>> >>> The channels are occassionally swapping when accessing data from
>multiple channels.
>> >>>
>> >>> I wrote a simple bash script to demonstrate.
>> >>
>> >>This happened to me in a previous version of the patch. I remember
>it
>> >>being fixed in the last version (or at least I could not
>reproduce).
>> >>I'll test again tomorrow with your script.
>> >>
>> >
>> >Here is what I believe is happening.
>> >
>> >The request for a conversion on a new channel comes in while the
>> >conversion
>> >for the previous channel is still converting. The driver waits
>> >approximately
>> >one conversion cycle. The previous channel completes within this
>timeframe
>> >and the MUX is changed and the new sample is started. The new sample
>is
>> >still
>> >converting and the driver returns the value from the previous
>conversion.
>> >
>> >For a test I multiplied the conv_time value by 2 in the
>> >ads1015_get_adc_result
>> >function. This allows time for the current sample flush out and
>always
>> >returns
>> >the appropriate channel's value.
>> >
>> >Looking at the buffered mode it appears that only one channel is
>being
>> >accessed
>> >at any time. This being the first one in the active_scan_mask found
>by
>> >find_first_bit. So the MUX would never change is buffered mode as
>far I
>> >can
>> >tell.
>> >
>> >Don't we typically want to read all of enabled channels in buffered
>mode?
>> In some devices that is effectively impossible (fifo's that fill only
>from
>> the currently
>> selected channel). That is what the onehot validation callback is
>about.
>> In this particular case it looks like doing a multichannel read is
>fair bit
>> more time
>> consuming than a single channel read and so will result in a
>considerable
>> reduction in
>> throughput.  This is of course why many parts include a simple
>sequencer!
>
>Yes the sampling rate would effectively be divided by the number of
>channels
>enabled.
Worse than that as you have to explicitly change the mux for each channel requiring an i2c write.
>
>> 
>> Anyhow, supporting multi channel buffered reads could be done
>(probably) but
>> you
>> would want to fall back to the single channel case as it is now.
>
>Understood.
>
>> 
>> Jonathan
>> >>Lucas De Marchi
>> >--
>> >To unsubscribe from this list: send the line "unsubscribe linux-iio"
>in
>> >the body of a message to majordomo@vger.kernel.org
>> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1346540

On Tue, Mar 1, 2016 at 4:42 AM, Michael Welling <mwelling@ieee.org> wrote:
> On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
>> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
>> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
>> >> The driver has sysfs readings with runtime PM support for power saving.
>> >> It also offers buffer support that can be used together with IIO software
>> >> triggers.
>> >>
>> >
>> > Daniel,
>> >
>> > So I noticed something yesterday while testing new boards.
>> > The channels are occassionally swapping when accessing data from multiple channels.
>> >
>> > I wrote a simple bash script to demonstrate.
>>
>> This happened to me in a previous version of the patch. I remember it
>> being fixed in the last version (or at least I could not reproduce).
>> I'll test again tomorrow with your script.
>>
>
> Here is what I believe is happening.
>
> The request for a conversion on a new channel comes in while the conversion
> for the previous channel is still converting. The driver waits approximately
> one conversion cycle. The previous channel completes within this timeframe
> and the MUX is changed and the new sample is started. The new sample is still
> converting and the driver returns the value from the previous conversion.
>

Yes, this was the problem in the initial driver. The fix was to wait
for the conversion to complete
but it seems that it doesn't always work on your setup :(.

     if (change) {
+               conv_time = DIV_ROUND_UP(USEC_PER_SEC, ads1015_data_rate[dr]);
+               usleep_range(conv_time, conv_time + 1);
+       }
+


> For a test I multiplied the conv_time value by 2 in the ads1015_get_adc_result
> function. This allows time for the current sample flush out and always returns
> the appropriate channel's value.
>
> Looking at the buffered mode it appears that only one channel is being accessed
> at any time. This being the first one in the active_scan_mask found by
> find_first_bit. So the MUX would never change is buffered mode as far I can
> tell.
>
> Don't we typically want to read all of enabled channels in buffered mode?

For the moment we allow only a single channel to be enabled in buffer mode.

[toc] | [prev] | [next] | [standalone]

#1346715

On Tue, Mar 01, 2016 at 01:28:26PM +0200, Daniel Baluta wrote:
> On Tue, Mar 1, 2016 at 4:42 AM, Michael Welling <mwelling@ieee.org> wrote:
> > On Mon, Feb 29, 2016 at 10:09:10PM -0300, Lucas De Marchi wrote:
> >> On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling <mwelling@ieee.org> wrote:
> >> > On Fri, Feb 05, 2016 at 03:17:18PM +0200, Daniel Baluta wrote:
> >> >> The driver has sysfs readings with runtime PM support for power saving.
> >> >> It also offers buffer support that can be used together with IIO software
> >> >> triggers.
> >> >>
> >> >
> >> > Daniel,
> >> >
> >> > So I noticed something yesterday while testing new boards.
> >> > The channels are occassionally swapping when accessing data from multiple channels.
> >> >
> >> > I wrote a simple bash script to demonstrate.
> >>
> >> This happened to me in a previous version of the patch. I remember it
> >> being fixed in the last version (or at least I could not reproduce).
> >> I'll test again tomorrow with your script.
> >>
> >
> > Here is what I believe is happening.
> >
> > The request for a conversion on a new channel comes in while the conversion
> > for the previous channel is still converting. The driver waits approximately
> > one conversion cycle. The previous channel completes within this timeframe
> > and the MUX is changed and the new sample is started. The new sample is still
> > converting and the driver returns the value from the previous conversion.
> >
> 
> Yes, this was the problem in the initial driver. The fix was to wait
> for the conversion to complete
> but it seems that it doesn't always work on your setup :(.
> 
>      if (change) {
> +               conv_time = DIV_ROUND_UP(USEC_PER_SEC, ads1015_data_rate[dr]);
> +               usleep_range(conv_time, conv_time + 1);
> +       }
> +
>

The result can theoretically take up to nearly 2 conversion cycles if the
request for a new channel comes in just as the previous conversion starts.

> 
> > For a test I multiplied the conv_time value by 2 in the ads1015_get_adc_result
> > function. This allows time for the current sample flush out and always returns
> > the appropriate channel's value.
> >
> > Looking at the buffered mode it appears that only one channel is being accessed
> > at any time. This being the first one in the active_scan_mask found by
> > find_first_bit. So the MUX would never change is buffered mode as far I can
> > tell.
> >
> > Don't we typically want to read all of enabled channels in buffered mode?
> 
> For the moment we allow only a single channel to be enabled in buffer mode.

Okay just making sure. Adding more channels would effectively divide the sampling
rate and increase the complexity of the driver.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web