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

[Jonathan Cameron]

On 1 March 2016 16:02:00 GMT+00:00, Michael Welling  wrote:
>On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@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
>
>> >>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 majord...@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 majord...@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.

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

[Jonathan Cameron]

On 1 March 2016 16:02:00 GMT+00:00, Michael Welling  wrote:
>On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@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
>
>> >>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 majord...@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 majord...@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.

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

[Michael Welling]

On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@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 
> >>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 majord...@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Welling]

On Tue, Mar 01, 2016 at 08:35:01AM +, ji...@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 
> >>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 majord...@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Welling]

On Tue, Mar 01, 2016 at 01:28:26PM +0200, Daniel Baluta wrote:
> On Tue, Mar 1, 2016 at 4:42 AM, 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  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.

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

[Michael Welling]

On Tue, Mar 01, 2016 at 01:28:26PM +0200, Daniel Baluta wrote:
> On Tue, Mar 1, 2016 at 4:42 AM, 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  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.

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

[Daniel Baluta]

On Tue, Mar 1, 2016 at 4:42 AM, 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  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.

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

[Daniel Baluta]

On Tue, Mar 1, 2016 at 4:42 AM, 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  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.

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

[jic23]

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  
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[jic23]

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  
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Welling]

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  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

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

[Michael Welling]

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  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

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

[Michael Welling]

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  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

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

[Michael Welling]

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  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

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

[Michael Welling]

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  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

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

[Michael Welling]

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  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

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

[Lucas De Marchi]

On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  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

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

[Lucas De Marchi]

On Mon, Feb 29, 2016 at 9:50 PM, Michael Welling  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

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

[Michael Welling]

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

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

[Michael Welling]

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

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

[Sricharan]

Hi,

> On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> > On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > > Hi Sricharan,
> > > >
> > > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-
> pca9685.c
> > > > right?
> > > >
> > >  Yes.
> > >
> > > > I'm asking this because this driver doesn't seem to support
> > > > runtime pm and there is no check for regmap_write/regmap_write
> > > > return code in the probe function.
> > >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which
> fails right ?
> > >I was tracking that when there are i2c_xfers from pwm. I did not see
> any failures there.
> > >So wanted to know the correct sequence to reproduce.
> > >
> >
> > The problem was discovered using the patch that this thread is on. The
> > PWM driver does not have the problem.
> >
> > When the driver in this patch called pm_runtime_get_sync you got -EINVAL
> back.
> 
> I noticed some patches for the QUP I2C driver in linux-next so I built against
> it.
> 
> The ADC driver now appears to work as desired.
> 
   Ok, I suppose those were changes merged last week to add qup V2 tags 
support, but
   not sure how that is helping to solve the pm_runtime issue here. 

Regards,
  Sricharan

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

[Sricharan]

Hi,

> On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> > On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > > Hi Sricharan,
> > > >
> > > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-
> pca9685.c
> > > > right?
> > > >
> > >  Yes.
> > >
> > > > I'm asking this because this driver doesn't seem to support
> > > > runtime pm and there is no check for regmap_write/regmap_write
> > > > return code in the probe function.
> > >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which
> fails right ?
> > >I was tracking that when there are i2c_xfers from pwm. I did not see
> any failures there.
> > >So wanted to know the correct sequence to reproduce.
> > >
> >
> > The problem was discovered using the patch that this thread is on. The
> > PWM driver does not have the problem.
> >
> > When the driver in this patch called pm_runtime_get_sync you got -EINVAL
> back.
> 
> I noticed some patches for the QUP I2C driver in linux-next so I built against
> it.
> 
> The ADC driver now appears to work as desired.
> 
   Ok, I suppose those were changes merged last week to add qup V2 tags 
support, but
   not sure how that is helping to solve the pm_runtime issue here. 

Regards,
  Sricharan

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

[Michael Welling]

On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > Hi Sricharan,
> > > 
> > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > > right?
> > >
> >  Yes.
> >  
> > > I'm asking this because this driver doesn't seem to support runtime pm and
> > > there is no check for regmap_write/regmap_write return code in the probe
> > > function.
> >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> > right ?
> >I was tracking that when there are i2c_xfers from pwm. I did not see any 
> > failures there.
> >So wanted to know the correct sequence to reproduce.
> >
> 
> The problem was discovered using the patch that this thread is on. The PWM 
> driver does
> not have the problem.
> 
> When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

I noticed some patches for the QUP I2C driver in linux-next so I built against 
it.

The ADC driver now appears to work as desired.

root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw 
287
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw 
269
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw 
270
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw 
271

> 
> > Regards,
> >   Sricharan
> >   
> > 
> > 

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

[Michael Welling]

On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > Hi Sricharan,
> > > 
> > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > > right?
> > >
> >  Yes.
> >  
> > > I'm asking this because this driver doesn't seem to support runtime pm and
> > > there is no check for regmap_write/regmap_write return code in the probe
> > > function.
> >Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> > right ?
> >I was tracking that when there are i2c_xfers from pwm. I did not see any 
> > failures there.
> >So wanted to know the correct sequence to reproduce.
> >
> 
> The problem was discovered using the patch that this thread is on. The PWM 
> driver does
> not have the problem.
> 
> When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

I noticed some patches for the QUP I2C driver in linux-next so I built against 
it.

The ADC driver now appears to work as desired.

root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw 
287
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw 
269
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage2_raw 
270
root@dragonboard-410c:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage3_raw 
271

> 
> > Regards,
> >   Sricharan
> >   
> > 
> > 

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

[Michael Welling]

On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > Hi Sricharan,
> > 
> > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > right?
> >
>  Yes.
>  
> > I'm asking this because this driver doesn't seem to support runtime pm and
> > there is no check for regmap_write/regmap_write return code in the probe
> > function.
>Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> right ?
>I was tracking that when there are i2c_xfers from pwm. I did not see any 
> failures there.
>So wanted to know the correct sequence to reproduce.
>

The problem was discovered using the patch that this thread is on. The PWM 
driver does
not have the problem.

When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

> Regards,
>   Sricharan
>   
> 
> 

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

[Sricharan]

...

> >> > > > >
> >> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> >> > > > >
> >> > > > > > >
> >> > > > > > > When I comment out the break the readings come back but
> >> > > > > > > are not
> >> > > updated continually.
> >> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw
> >> > > > > > > the value
> >> > is
> >> > > updated.
> >> > > > > >
> >> > > > > > I guess this is normal if set_power_state fails.
> >> > > > >
> >> > > > > The hwmod driver works fine BTW.
> >> > > > >
> >> > > > > My guess is there is an issue with the qup i2c driver seeing
> >> > > > > as it has worked on other system without issue.
> >> > > > >
> >> > > > > CC'd some the latest developer on the qup i2c driver.
> >> > > > >
> >> > > > > I2C guys have any ideas on this?
> >> > > > >
> >> > > >
> >> > > > Adding some more people who recently worked on this. Might be
> >> > > > nice to know which kernel version you are using.
> >> > > >
> >> >  Which i2c bus is this connected to ? I can give a try with 410c to
> >> > see why pm_runtime_get_sync from qup  fails.
> >>
> >> It is on the lowspeed header. Here is my devicetree entry:
> >>
> >>  i2c@78b6000 {
> >>  /* On Low speed expansion */
> >>  label = "LS-I2C0";
> >>  status = "okay";
> >>
> >>  pca: pca@40 {
> >>  compatible = "nxp,pca9685-pwm";
> >>  #pwm-cells = <2>;
> >>  reg = <0x40>;
> >>  };
> >>
> >>  adc: adc@48 {
> >>  compatible = "ti,ads1015";
> >>  reg = <0x48>;
> >>  };
> >>  };
> >
> > Whats the sequence in which the failure happens ?
> >
> > I tested on DB410c by adding the DT entry that you mentioned above on
> > 4.5-rc2 and rc3.
> > I see that the i2c transfers call from pca9685  during
> > pca9685_pwm_probe did go through and no failure from
> > pm_runtime_get_sync
> 
> Hi Sricharan,
> 
> Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> right?
>
 Yes.
 
> I'm asking this because this driver doesn't seem to support runtime pm and
> there is no check for regmap_write/regmap_write return code in the probe
> function.
   Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
right ?
   I was tracking that when there are i2c_xfers from pwm. I did not see any 
failures there.
   So wanted to know the correct sequence to reproduce.
  
Regards,
  Sricharan
  

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

[Daniel Baluta]

>> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>> > > > > > >> + struct iio_chan_spec const *chan,
>> > > > > > >> +int
>> > *val,
>> > > > > > >> + int *val2, long mask) {
>> > > > > > >> + int ret, idx;
>> > > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
>> > > > > > >> +
>> > > > > > >> + mutex_lock(>lock);
>> > > > > > >> + switch (mask) {
>> > > > > > >> + case IIO_CHAN_INFO_RAW:
>> > > > > > >> + if (iio_buffer_enabled(indio_dev)) {
>> > > > > > >> + ret = -EBUSY;
>> > > > > > >> + break;
>> > > > > > >> + }
>> > > > > > >> +
>> > > > > > >> + ret = ads1015_set_power_state(data, true);
>> > > > > > >> + if (ret < 0)
>> > > > > > >> + break;
>> > > > > > >
>> > > > > > > Just tested the driver on a Dragonboard 410C with a robotics
>> > > > > > > mezzanine that I designed.
>> > > > > > >
>> > > > > > > The above ads1015_set_power_state(data, true) is always
>> > > > > > > returning
>> > -
>> > > EINVAL.
>> > > > > > >
>> > > > > > > Any ideas why that would be happening?
>> > > > > > > I think it may be the return from pm_runtime_get_sync?
>> > > > > >
>> > > > > > Can you confirm that pm_runtime_get_sync fails? Using some
>> printk?
>> > > > > >
>> > > > > > Also adding printks in suspend/resume function would be helpful.
>> > > > > > Do you have CONFIG_PM enabled?
>> > > > > >
>> > > > >
>> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
>> > > > >
>> > > > > > >
>> > > > > > > When I comment out the break the readings come back but are
>> > > > > > > not
>> > > updated continually.
>> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the
>> > > > > > > value
>> > is
>> > > updated.
>> > > > > >
>> > > > > > I guess this is normal if set_power_state fails.
>> > > > >
>> > > > > The hwmod driver works fine BTW.
>> > > > >
>> > > > > My guess is there is an issue with the qup i2c driver seeing as
>> > > > > it has worked on other system without issue.
>> > > > >
>> > > > > CC'd some the latest developer on the qup i2c driver.
>> > > > >
>> > > > > I2C guys have any ideas on this?
>> > > > >
>> > > >
>> > > > Adding some more people who recently worked on this. Might be nice
>> > > > to know which kernel version you are using.
>> > > >
>> >  Which i2c bus is this connected to ? I can give a try with 410c to
>> > see why pm_runtime_get_sync from qup  fails.
>>
>> It is on the lowspeed header. Here is my devicetree entry:
>>
>>  i2c@78b6000 {
>>  /* On Low speed expansion */
>>  label = "LS-I2C0";
>>  status = "okay";
>>
>>  pca: pca@40 {
>>  compatible = "nxp,pca9685-pwm";
>>  #pwm-cells = <2>;
>>  reg = <0x40>;
>>  };
>>
>>  adc: adc@48 {
>>  compatible = "ti,ads1015";
>>  reg = <0x48>;
>>  };
>>  };
>
> Whats the sequence in which the failure happens ?
>
> I tested on DB410c by adding the DT entry that you mentioned above on
> 4.5-rc2 and rc3.
> I see that the i2c transfers call from pca9685  during  pca9685_pwm_probe
> did
> go through and no failure from pm_runtime_get_sync

Hi Sricharan,

Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c right?

I'm asking this because this driver doesn't seem to support runtime
pm and there is no check for regmap_write/regmap_write return
code in the probe function.


Daniel.

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

[Sricharan]

Hi,

> -Original Message-
> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
> ow...@vger.kernel.org] On Behalf Of Michael Welling
> Sent: Tuesday, February 09, 2016 12:47 AM
> To: Sricharan
> Cc: 'Wolfram Sang'; 'Daniel Baluta'; 'Jonathan Cameron'; 'Hartmut Knaack';
> 'Lars-Peter Clausen'; 'Peter Meerwald-Stadler'; 'Linux Kernel Mailing
List';
> linux-...@vger.kernel.org; 'Lucas De Marchi'; 'Andy Gross'; 'Pramod
Gurav';
> 'Bjorn Andersson'; 'Guenter Roeck'; eib...@gdsys.de; linux-arm-
> m...@vger.kernel.org
> Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> 
> On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of
> > > Michael Welling
> > > Sent: Monday, February 08, 2016 10:07 PM
> > > To: Wolfram Sang
> > > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter
> > > Clausen; Peter Meerwald-Stadler; Linux Kernel Mailing List;
> > linux-...@vger.kernel.org;
> > > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > >
> > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > >> + struct iio_chan_spec const *chan,
> > > > > > >> +int
> > *val,
> > > > > > >> + int *val2, long mask) {
> > > > > > >> + int ret, idx;
> > > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > > >> +
> > > > > > >> + mutex_lock(>lock);
> > > > > > >> + switch (mask) {
> > > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > > >> + ret = -EBUSY;
> > > > > > >> + break;
> > > > > > >> + }
> > > > > > >> +
> > > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > > >> + if (ret < 0)
> > > > > > >> + break;
> > > > > > >
> > > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > > mezzanine that I designed.
> > > > > > >
> > > > > > > The above ads1015_set_power_state(data, true) is always
> > > > > > > returning
> > -
> > > EINVAL.
> > > > > > >
> > > > > > > Any ideas why that would be happening?
> > > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > > >
> > > > > > Can you confirm that pm_runtime_get_sync fails? Using some
> printk?
> > > > > >
> > > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > > Do you have CONFIG_PM enabled?
> > > > > >
> > > > >
> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > > >
> > > > > > >
> > > > > > > When I comment out the break the readings come back but are
> > > > > > > not
> > > updated continually.
> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the
> > > > > > > value
> > is
> > > updated.
> > > > > >
> > > > > > I guess this is normal if set_power_state fails.
> > > > >
> > > > > The hwmod driver works fine BTW.
> > > > >
> > > > > My guess is there is an issue with the qup i2c driver seeing as
> > > > > it has worked on other system without issue.
> > > > >
> > > > > CC'd some the latest developer on the qup i2c driver.
> > > > >
> > > > > I2C guys have any ideas on this?
> > > > >
> > > >
> > > > Adding some more people who recently worked on this. Might be nice
> > > > to know which kernel version you are using.
> > > >
> >  Which i2c bus is this connected to ? I can give a try with 410c to
> > see why pm_runtime_get_sync from qup  fails.
> 
> It is on the lowspeed header. Here is my devicetree entry:
> 
>  i2c@78b6000 {
>  /* On Low speed expansion */
>  label = "LS-I2C0";
>  status = "okay";
> 
>  pca: pca@40 {
>  compatible = "nxp,pca9685-pwm";
>  #pwm-cells = <2>;
>  reg = <0x40>;
>  };
> 
>  adc: adc@48 {
>  compatible = "ti,ads1015";
>  reg = <0x48>;
>  };
>  };

Whats the sequence in which the failure happens ?

I tested on DB410c by adding the DT entry that you mentioned above on
4.5-rc2 and rc3.
I see that the i2c transfers call from pca9685  during  pca9685_pwm_probe
did
go through and no failure from pm_runtime_get_sync

Regards,
 Sricharan

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

[Sricharan]

...

> >> > > > >
> >> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> >> > > > >
> >> > > > > > >
> >> > > > > > > When I comment out the break the readings come back but
> >> > > > > > > are not
> >> > > updated continually.
> >> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw
> >> > > > > > > the value
> >> > is
> >> > > updated.
> >> > > > > >
> >> > > > > > I guess this is normal if set_power_state fails.
> >> > > > >
> >> > > > > The hwmod driver works fine BTW.
> >> > > > >
> >> > > > > My guess is there is an issue with the qup i2c driver seeing
> >> > > > > as it has worked on other system without issue.
> >> > > > >
> >> > > > > CC'd some the latest developer on the qup i2c driver.
> >> > > > >
> >> > > > > I2C guys have any ideas on this?
> >> > > > >
> >> > > >
> >> > > > Adding some more people who recently worked on this. Might be
> >> > > > nice to know which kernel version you are using.
> >> > > >
> >> >  Which i2c bus is this connected to ? I can give a try with 410c to
> >> > see why pm_runtime_get_sync from qup  fails.
> >>
> >> It is on the lowspeed header. Here is my devicetree entry:
> >>
> >>  i2c@78b6000 {
> >>  /* On Low speed expansion */
> >>  label = "LS-I2C0";
> >>  status = "okay";
> >>
> >>  pca: pca@40 {
> >>  compatible = "nxp,pca9685-pwm";
> >>  #pwm-cells = <2>;
> >>  reg = <0x40>;
> >>  };
> >>
> >>  adc: adc@48 {
> >>  compatible = "ti,ads1015";
> >>  reg = <0x48>;
> >>  };
> >>  };
> >
> > Whats the sequence in which the failure happens ?
> >
> > I tested on DB410c by adding the DT entry that you mentioned above on
> > 4.5-rc2 and rc3.
> > I see that the i2c transfers call from pca9685  during
> > pca9685_pwm_probe did go through and no failure from
> > pm_runtime_get_sync
> 
> Hi Sricharan,
> 
> Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> right?
>
 Yes.
 
> I'm asking this because this driver doesn't seem to support runtime pm and
> there is no check for regmap_write/regmap_write return code in the probe
> function.
   Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
right ?
   I was tracking that when there are i2c_xfers from pwm. I did not see any 
failures there.
   So wanted to know the correct sequence to reproduce.
  
Regards,
  Sricharan
  

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

[Michael Welling]

On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > Hi Sricharan,
> > 
> > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c
> > right?
> >
>  Yes.
>  
> > I'm asking this because this driver doesn't seem to support runtime pm and
> > there is no check for regmap_write/regmap_write return code in the probe
> > function.
>Hmm to be clear, so it’s the pm_runtime_getsync from i2c-qup which fails 
> right ?
>I was tracking that when there are i2c_xfers from pwm. I did not see any 
> failures there.
>So wanted to know the correct sequence to reproduce.
>

The problem was discovered using the patch that this thread is on. The PWM 
driver does
not have the problem.

When the driver in this patch called pm_runtime_get_sync you got -EINVAL back.

> Regards,
>   Sricharan
>   
> 
> 

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

[Sricharan]

Hi,

> -Original Message-
> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
> ow...@vger.kernel.org] On Behalf Of Michael Welling
> Sent: Tuesday, February 09, 2016 12:47 AM
> To: Sricharan
> Cc: 'Wolfram Sang'; 'Daniel Baluta'; 'Jonathan Cameron'; 'Hartmut Knaack';
> 'Lars-Peter Clausen'; 'Peter Meerwald-Stadler'; 'Linux Kernel Mailing
List';
> linux-...@vger.kernel.org; 'Lucas De Marchi'; 'Andy Gross'; 'Pramod
Gurav';
> 'Bjorn Andersson'; 'Guenter Roeck'; eib...@gdsys.de; linux-arm-
> m...@vger.kernel.org
> Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> 
> On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of
> > > Michael Welling
> > > Sent: Monday, February 08, 2016 10:07 PM
> > > To: Wolfram Sang
> > > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter
> > > Clausen; Peter Meerwald-Stadler; Linux Kernel Mailing List;
> > linux-...@vger.kernel.org;
> > > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > >
> > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > >> + struct iio_chan_spec const *chan,
> > > > > > >> +int
> > *val,
> > > > > > >> + int *val2, long mask) {
> > > > > > >> + int ret, idx;
> > > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > > >> +
> > > > > > >> + mutex_lock(>lock);
> > > > > > >> + switch (mask) {
> > > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > > >> + ret = -EBUSY;
> > > > > > >> + break;
> > > > > > >> + }
> > > > > > >> +
> > > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > > >> + if (ret < 0)
> > > > > > >> + break;
> > > > > > >
> > > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > > mezzanine that I designed.
> > > > > > >
> > > > > > > The above ads1015_set_power_state(data, true) is always
> > > > > > > returning
> > -
> > > EINVAL.
> > > > > > >
> > > > > > > Any ideas why that would be happening?
> > > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > > >
> > > > > > Can you confirm that pm_runtime_get_sync fails? Using some
> printk?
> > > > > >
> > > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > > Do you have CONFIG_PM enabled?
> > > > > >
> > > > >
> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > > >
> > > > > > >
> > > > > > > When I comment out the break the readings come back but are
> > > > > > > not
> > > updated continually.
> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the
> > > > > > > value
> > is
> > > updated.
> > > > > >
> > > > > > I guess this is normal if set_power_state fails.
> > > > >
> > > > > The hwmod driver works fine BTW.
> > > > >
> > > > > My guess is there is an issue with the qup i2c driver seeing as
> > > > > it has worked on other system without issue.
> > > > >
> > > > > CC'd some the latest developer on the qup i2c driver.
> > > > >
> > > > > I2C guys have any ideas on this?
> > > > >
> > > >
> > > > Adding some more people who recently worked on this. Might be nice
> > > > to know which kernel version you are using.
> > > >
> >  Which i2c bus is this connected to ? I can give a try with 410c to
> > see why pm_runtime_get_sync from qup  fails.
> 
> It is on the lowspeed header. Here is my devicetree entry:
> 
>  i2c@78b6000 {
>  /* On Low speed expansion */
>  label = "LS-I2C0";
>  status = "okay";
> 
>  pca: pca@40 {
>  compatible = "nxp,pca9685-pwm";
>  #pwm-cells = <2>;
>  reg = <0x40>;
>  };
> 
>  adc: adc@48 {
>  compatible = "ti,ads1015";
>  reg = <0x48>;
>  };
>  };

Whats the sequence in which the failure happens ?

I tested on DB410c by adding the DT entry that you mentioned above on
4.5-rc2 and rc3.
I see that the i2c transfers call from pca9685  during  pca9685_pwm_probe
did
go through and no failure from pm_runtime_get_sync

Regards,
 Sricharan

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

[Daniel Baluta]

>> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>> > > > > > >> + struct iio_chan_spec const *chan,
>> > > > > > >> +int
>> > *val,
>> > > > > > >> + int *val2, long mask) {
>> > > > > > >> + int ret, idx;
>> > > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
>> > > > > > >> +
>> > > > > > >> + mutex_lock(>lock);
>> > > > > > >> + switch (mask) {
>> > > > > > >> + case IIO_CHAN_INFO_RAW:
>> > > > > > >> + if (iio_buffer_enabled(indio_dev)) {
>> > > > > > >> + ret = -EBUSY;
>> > > > > > >> + break;
>> > > > > > >> + }
>> > > > > > >> +
>> > > > > > >> + ret = ads1015_set_power_state(data, true);
>> > > > > > >> + if (ret < 0)
>> > > > > > >> + break;
>> > > > > > >
>> > > > > > > Just tested the driver on a Dragonboard 410C with a robotics
>> > > > > > > mezzanine that I designed.
>> > > > > > >
>> > > > > > > The above ads1015_set_power_state(data, true) is always
>> > > > > > > returning
>> > -
>> > > EINVAL.
>> > > > > > >
>> > > > > > > Any ideas why that would be happening?
>> > > > > > > I think it may be the return from pm_runtime_get_sync?
>> > > > > >
>> > > > > > Can you confirm that pm_runtime_get_sync fails? Using some
>> printk?
>> > > > > >
>> > > > > > Also adding printks in suspend/resume function would be helpful.
>> > > > > > Do you have CONFIG_PM enabled?
>> > > > > >
>> > > > >
>> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
>> > > > >
>> > > > > > >
>> > > > > > > When I comment out the break the readings come back but are
>> > > > > > > not
>> > > updated continually.
>> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the
>> > > > > > > value
>> > is
>> > > updated.
>> > > > > >
>> > > > > > I guess this is normal if set_power_state fails.
>> > > > >
>> > > > > The hwmod driver works fine BTW.
>> > > > >
>> > > > > My guess is there is an issue with the qup i2c driver seeing as
>> > > > > it has worked on other system without issue.
>> > > > >
>> > > > > CC'd some the latest developer on the qup i2c driver.
>> > > > >
>> > > > > I2C guys have any ideas on this?
>> > > > >
>> > > >
>> > > > Adding some more people who recently worked on this. Might be nice
>> > > > to know which kernel version you are using.
>> > > >
>> >  Which i2c bus is this connected to ? I can give a try with 410c to
>> > see why pm_runtime_get_sync from qup  fails.
>>
>> It is on the lowspeed header. Here is my devicetree entry:
>>
>>  i2c@78b6000 {
>>  /* On Low speed expansion */
>>  label = "LS-I2C0";
>>  status = "okay";
>>
>>  pca: pca@40 {
>>  compatible = "nxp,pca9685-pwm";
>>  #pwm-cells = <2>;
>>  reg = <0x40>;
>>  };
>>
>>  adc: adc@48 {
>>  compatible = "ti,ads1015";
>>  reg = <0x48>;
>>  };
>>  };
>
> Whats the sequence in which the failure happens ?
>
> I tested on DB410c by adding the DT entry that you mentioned above on
> 4.5-rc2 and rc3.
> I see that the i2c transfers call from pca9685  during  pca9685_pwm_probe
> did
> go through and no failure from pm_runtime_get_sync

Hi Sricharan,

Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c right?

I'm asking this because this driver doesn't seem to support runtime
pm and there is no check for regmap_write/regmap_write return
code in the probe function.


Daniel.

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

[Michael Welling]

On Mon, Feb 08, 2016 at 09:00:27PM +0100, Wolfram Sang wrote:
> > > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > > >> + struct iio_chan_spec const *chan, int
> 
> Guys, please quote only relevant sections.
>

Sorry. 

> >  pca: pca@40 {
> >  compatible = "nxp,pca9685-pwm";
> >  #pwm-cells = <2>;
> >  reg = <0x40>;
> >  };
> 
> Does accessing the pca work?
> 

Yes.

https://plus.google.com/+MichaelWelling79/posts/PdmGysBfZp4

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

[Wolfram Sang]

> > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > >> + struct iio_chan_spec const *chan, int

Guys, please quote only relevant sections.

>  pca: pca@40 {
>  compatible = "nxp,pca9685-pwm";
>  #pwm-cells = <2>;
>  reg = <0x40>;
>  };

Does accessing the pca work?



signature.asc
Description: PGP signature

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

[Michael Welling]

On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> Hi,
> 
> > -Original Message-
> > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> > Welling
> > Sent: Monday, February 08, 2016 10:07 PM
> > To: Wolfram Sang
> > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> > Peter Meerwald-Stadler; Linux Kernel Mailing List;
> linux-...@vger.kernel.org;
> > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > 
> > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > >> + struct iio_chan_spec const *chan, int
> *val,
> > > > > >> + int *val2, long mask) {
> > > > > >> + int ret, idx;
> > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > >> +
> > > > > >> + mutex_lock(>lock);
> > > > > >> + switch (mask) {
> > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > >> + ret = -EBUSY;
> > > > > >> + break;
> > > > > >> + }
> > > > > >> +
> > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > >> + if (ret < 0)
> > > > > >> + break;
> > > > > >
> > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > mezzanine that I designed.
> > > > > >
> > > > > > The above ads1015_set_power_state(data, true) is always returning
> -
> > EINVAL.
> > > > > >
> > > > > > Any ideas why that would be happening?
> > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > >
> > > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > > >
> > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > Do you have CONFIG_PM enabled?
> > > > >
> > > >
> > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > >
> > > > > >
> > > > > > When I comment out the break the readings come back but are not
> > updated continually.
> > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
> is
> > updated.
> > > > >
> > > > > I guess this is normal if set_power_state fails.
> > > >
> > > > The hwmod driver works fine BTW.
> > > >
> > > > My guess is there is an issue with the qup i2c driver seeing as it
> > > > has worked on other system without issue.
> > > >
> > > > CC'd some the latest developer on the qup i2c driver.
> > > >
> > > > I2C guys have any ideas on this?
> > > >
> > >
> > > Adding some more people who recently worked on this. Might be nice to
> > > know which kernel version you are using.
> > >
>  Which i2c bus is this connected to ? I can give a try with 410c to see why
> pm_runtime_get_sync from qup
>  fails.

It is on the lowspeed header. Here is my devicetree entry:

 i2c@78b6000 {
 /* On Low speed expansion */
 label = "LS-I2C0";
 status = "okay";
 
 pca: pca@40 {
 compatible = "nxp,pca9685-pwm";
 #pwm-cells = <2>;
 reg = <0x40>;
 };
 
 adc: adc@48 {
 compatible = "ti,ads1015";
 reg = <0x48>;
 };
 };

> 
> Regards,
>   Sricharan
> 
> 
> 

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

[Sricharan]

Hi,

> -Original Message-
> From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> Welling
> Sent: Monday, February 08, 2016 10:07 PM
> To: Wolfram Sang
> Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> Peter Meerwald-Stadler; Linux Kernel Mailing List;
linux-...@vger.kernel.org;
> Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> 
> On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > >> + struct iio_chan_spec const *chan, int
*val,
> > > > >> + int *val2, long mask) {
> > > > >> + int ret, idx;
> > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > >> +
> > > > >> + mutex_lock(>lock);
> > > > >> + switch (mask) {
> > > > >> + case IIO_CHAN_INFO_RAW:
> > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > >> + ret = -EBUSY;
> > > > >> + break;
> > > > >> + }
> > > > >> +
> > > > >> + ret = ads1015_set_power_state(data, true);
> > > > >> + if (ret < 0)
> > > > >> + break;
> > > > >
> > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > mezzanine that I designed.
> > > > >
> > > > > The above ads1015_set_power_state(data, true) is always returning
-
> EINVAL.
> > > > >
> > > > > Any ideas why that would be happening?
> > > > > I think it may be the return from pm_runtime_get_sync?
> > > >
> > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > >
> > > > Also adding printks in suspend/resume function would be helpful.
> > > > Do you have CONFIG_PM enabled?
> > > >
> > >
> > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > >
> > > > >
> > > > > When I comment out the break the readings come back but are not
> updated continually.
> > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
is
> updated.
> > > >
> > > > I guess this is normal if set_power_state fails.
> > >
> > > The hwmod driver works fine BTW.
> > >
> > > My guess is there is an issue with the qup i2c driver seeing as it
> > > has worked on other system without issue.
> > >
> > > CC'd some the latest developer on the qup i2c driver.
> > >
> > > I2C guys have any ideas on this?
> > >
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.
> >
 Which i2c bus is this connected to ? I can give a try with 410c to see why
pm_runtime_get_sync from qup
 fails.

Regards,
  Sricharan

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

[Michael Welling]

On Mon, Feb 08, 2016 at 04:44:02PM +0200, Daniel Baluta wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> >> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> > >> + struct iio_chan_spec const *chan, int *val,
> >> > >> + int *val2, long mask)
> >> > >> +{
> >> > >> + int ret, idx;
> >> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> > >> +
> >> > >> + mutex_lock(>lock);
> >> > >> + switch (mask) {
> >> > >> + case IIO_CHAN_INFO_RAW:
> >> > >> + if (iio_buffer_enabled(indio_dev)) {
> >> > >> + ret = -EBUSY;
> >> > >> + break;
> >> > >> + }
> >> > >> +
> >> > >> + ret = ads1015_set_power_state(data, true);
> >> > >> + if (ret < 0)
> >> > >> + break;
> >> > >
> >> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> >> > > that I
> >> > > designed.
> >> > >
> >> > > The above ads1015_set_power_state(data, true) is always returning 
> >> > > -EINVAL.
> >> > >
> >> > > Any ideas why that would be happening?
> >> > > I think it may be the return from pm_runtime_get_sync?
> >> >
> >> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> >> >
> >> > Also adding printks in suspend/resume function would be helpful. Do
> >> > you have CONFIG_PM enabled?
> >> >
> >>
> >> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
> 
> * after insmod

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> * after a reading from sysfs

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> 
> >>
> >> > >
> >> > > When I comment out the break the readings come back but are not 
> >> > > updated continually.
> >> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> >> > > updated.
> >> >
> >> > I guess this is normal if set_power_state fails.
> >>
> >> The hwmod driver works fine BTW.
> >>
> >> My guess is there is an issue with the qup i2c driver seeing as it has 
> >> worked on
> >> other system without issue.
> >>
> >> CC'd some the latest developer on the qup i2c driver.
> >>
> >> I2C guys have any ideas on this?
> >>
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.

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

[Michael Welling]

On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > >> + struct iio_chan_spec const *chan, int *val,
> > > >> + int *val2, long mask)
> > > >> +{
> > > >> + int ret, idx;
> > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > >> +
> > > >> + mutex_lock(>lock);
> > > >> + switch (mask) {
> > > >> + case IIO_CHAN_INFO_RAW:
> > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > >> + ret = -EBUSY;
> > > >> + break;
> > > >> + }
> > > >> +
> > > >> + ret = ads1015_set_power_state(data, true);
> > > >> + if (ret < 0)
> > > >> + break;
> > > >
> > > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > > that I
> > > > designed.
> > > >
> > > > The above ads1015_set_power_state(data, true) is always returning 
> > > > -EINVAL.
> > > >
> > > > Any ideas why that would be happening?
> > > > I think it may be the return from pm_runtime_get_sync?
> > > 
> > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > 
> > > Also adding printks in suspend/resume function would be helpful. Do
> > > you have CONFIG_PM enabled?
> > >
> > 
> > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > 
> > > >
> > > > When I comment out the break the readings come back but are not updated 
> > > > continually.
> > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > > updated.
> > > 
> > > I guess this is normal if set_power_state fails.
> > 
> > The hwmod driver works fine BTW.
> > 
> > My guess is there is an issue with the qup i2c driver seeing as it has 
> > worked on
> > other system without issue.
> > 
> > CC'd some the latest developer on the qup i2c driver.
> > 
> > I2C guys have any ideas on this?
> > 
> 
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.
>

4.5.0-rc2
 
> > > 
> > > thanks,
> > > Daniel.

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

[Daniel Baluta]

On Mon, Feb 8, 2016 at 4:44 PM, Daniel Baluta  wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
>> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
>>> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
>>> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>>> > >> + struct iio_chan_spec const *chan, int *val,
>>> > >> + int *val2, long mask)
>>> > >> +{
>>> > >> + int ret, idx;
>>> > >> + struct ads1015_data *data = iio_priv(indio_dev);
>>> > >> +
>>> > >> + mutex_lock(>lock);
>>> > >> + switch (mask) {
>>> > >> + case IIO_CHAN_INFO_RAW:
>>> > >> + if (iio_buffer_enabled(indio_dev)) {
>>> > >> + ret = -EBUSY;
>>> > >> + break;
>>> > >> + }
>>> > >> +
>>> > >> + ret = ads1015_set_power_state(data, true);
>>> > >> + if (ret < 0)
>>> > >> + break;
>>> > >
>>> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
>>> > > that I
>>> > > designed.
>>> > >
>>> > > The above ads1015_set_power_state(data, true) is always returning 
>>> > > -EINVAL.
>>> > >
>>> > > Any ideas why that would be happening?
>>> > > I think it may be the return from pm_runtime_get_sync?
>>> >
>>> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
>>> >
>>> > Also adding printks in suspend/resume function would be helpful. Do
>>> > you have CONFIG_PM enabled?
>>> >
>>>
>>> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
>
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
>
> * after insmod
> * after a reading from sysfs
>
>>>
>>> > >
>>> > > When I comment out the break the readings come back but are not updated 
>>> > > continually.
>>> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
>>> > > updated.
>>> >
>>> > I guess this is normal if set_power_state fails.
>>>
>>> The hwmod driver works fine BTW.
>>>
>>> My guess is there is an issue with the qup i2c driver seeing as it has 
>>> worked on
>>> other system without issue.
>>>
>>> CC'd some the latest developer on the qup i2c driver.
>>>
>>> I2C guys have any ideas on this?
>>>
>>
>> Adding some more people who recently worked on this. Might be nice to
>> know which kernel version you are using.

Jonathan,

I will send an update version with your comments addressed once
we sort out this runtime pm issue.

Michael,

If you questions we can discuss on #linux-iio IRC channel
under irc.oftc.net server.

thanks,
Daniel.

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

[Daniel Baluta]

On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
>> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
>> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>> > >> + struct iio_chan_spec const *chan, int *val,
>> > >> + int *val2, long mask)
>> > >> +{
>> > >> + int ret, idx;
>> > >> + struct ads1015_data *data = iio_priv(indio_dev);
>> > >> +
>> > >> + mutex_lock(>lock);
>> > >> + switch (mask) {
>> > >> + case IIO_CHAN_INFO_RAW:
>> > >> + if (iio_buffer_enabled(indio_dev)) {
>> > >> + ret = -EBUSY;
>> > >> + break;
>> > >> + }
>> > >> +
>> > >> + ret = ads1015_set_power_state(data, true);
>> > >> + if (ret < 0)
>> > >> + break;
>> > >
>> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
>> > > that I
>> > > designed.
>> > >
>> > > The above ads1015_set_power_state(data, true) is always returning 
>> > > -EINVAL.
>> > >
>> > > Any ideas why that would be happening?
>> > > I think it may be the return from pm_runtime_get_sync?
>> >
>> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
>> >
>> > Also adding printks in suspend/resume function would be helpful. Do
>> > you have CONFIG_PM enabled?
>> >
>>
>> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

Can you check the output of:
$ cat /sys/bus/iio/devices/iio:device0/power/runtime_status

* after insmod
* after a reading from sysfs

>>
>> > >
>> > > When I comment out the break the readings come back but are not updated 
>> > > continually.
>> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
>> > > updated.
>> >
>> > I guess this is normal if set_power_state fails.
>>
>> The hwmod driver works fine BTW.
>>
>> My guess is there is an issue with the qup i2c driver seeing as it has 
>> worked on
>> other system without issue.
>>
>> CC'd some the latest developer on the qup i2c driver.
>>
>> I2C guys have any ideas on this?
>>
>
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.

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

[Wolfram Sang]

On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > >> + struct iio_chan_spec const *chan, int *val,
> > >> + int *val2, long mask)
> > >> +{
> > >> + int ret, idx;
> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > >> +
> > >> + mutex_lock(>lock);
> > >> + switch (mask) {
> > >> + case IIO_CHAN_INFO_RAW:
> > >> + if (iio_buffer_enabled(indio_dev)) {
> > >> + ret = -EBUSY;
> > >> + break;
> > >> + }
> > >> +
> > >> + ret = ads1015_set_power_state(data, true);
> > >> + if (ret < 0)
> > >> + break;
> > >
> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > that I
> > > designed.
> > >
> > > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> > >
> > > Any ideas why that would be happening?
> > > I think it may be the return from pm_runtime_get_sync?
> > 
> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > 
> > Also adding printks in suspend/resume function would be helpful. Do
> > you have CONFIG_PM enabled?
> >
> 
> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> > >
> > > When I comment out the break the readings come back but are not updated 
> > > continually.
> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > updated.
> > 
> > I guess this is normal if set_power_state fails.
> 
> The hwmod driver works fine BTW.
> 
> My guess is there is an issue with the qup i2c driver seeing as it has worked 
> on
> other system without issue.
> 
> CC'd some the latest developer on the qup i2c driver.
> 
> I2C guys have any ideas on this?
> 

Adding some more people who recently worked on this. Might be nice to
know which kernel version you are using.

> > 
> > thanks,
> > Daniel.


signature.asc
Description: PGP signature

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

[Michael Welling]

On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > >> + struct iio_chan_spec const *chan, int *val,
> > > >> + int *val2, long mask)
> > > >> +{
> > > >> + int ret, idx;
> > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > >> +
> > > >> + mutex_lock(>lock);
> > > >> + switch (mask) {
> > > >> + case IIO_CHAN_INFO_RAW:
> > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > >> + ret = -EBUSY;
> > > >> + break;
> > > >> + }
> > > >> +
> > > >> + ret = ads1015_set_power_state(data, true);
> > > >> + if (ret < 0)
> > > >> + break;
> > > >
> > > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > > that I
> > > > designed.
> > > >
> > > > The above ads1015_set_power_state(data, true) is always returning 
> > > > -EINVAL.
> > > >
> > > > Any ideas why that would be happening?
> > > > I think it may be the return from pm_runtime_get_sync?
> > > 
> > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > 
> > > Also adding printks in suspend/resume function would be helpful. Do
> > > you have CONFIG_PM enabled?
> > >
> > 
> > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > 
> > > >
> > > > When I comment out the break the readings come back but are not updated 
> > > > continually.
> > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > > updated.
> > > 
> > > I guess this is normal if set_power_state fails.
> > 
> > The hwmod driver works fine BTW.
> > 
> > My guess is there is an issue with the qup i2c driver seeing as it has 
> > worked on
> > other system without issue.
> > 
> > CC'd some the latest developer on the qup i2c driver.
> > 
> > I2C guys have any ideas on this?
> > 
> 
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.
>

4.5.0-rc2
 
> > > 
> > > thanks,
> > > Daniel.

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

[Michael Welling]

On Mon, Feb 08, 2016 at 04:44:02PM +0200, Daniel Baluta wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> >> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> > >> + struct iio_chan_spec const *chan, int *val,
> >> > >> + int *val2, long mask)
> >> > >> +{
> >> > >> + int ret, idx;
> >> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> > >> +
> >> > >> + mutex_lock(>lock);
> >> > >> + switch (mask) {
> >> > >> + case IIO_CHAN_INFO_RAW:
> >> > >> + if (iio_buffer_enabled(indio_dev)) {
> >> > >> + ret = -EBUSY;
> >> > >> + break;
> >> > >> + }
> >> > >> +
> >> > >> + ret = ads1015_set_power_state(data, true);
> >> > >> + if (ret < 0)
> >> > >> + break;
> >> > >
> >> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> >> > > that I
> >> > > designed.
> >> > >
> >> > > The above ads1015_set_power_state(data, true) is always returning 
> >> > > -EINVAL.
> >> > >
> >> > > Any ideas why that would be happening?
> >> > > I think it may be the return from pm_runtime_get_sync?
> >> >
> >> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> >> >
> >> > Also adding printks in suspend/resume function would be helpful. Do
> >> > you have CONFIG_PM enabled?
> >> >
> >>
> >> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
> 
> * after insmod

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> * after a reading from sysfs

root@dragonboard-410c:~# cat 
/sys/bus/iio/devices/iio:device0/power/runtime_status
unsupported

> 
> >>
> >> > >
> >> > > When I comment out the break the readings come back but are not 
> >> > > updated continually.
> >> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> >> > > updated.
> >> >
> >> > I guess this is normal if set_power_state fails.
> >>
> >> The hwmod driver works fine BTW.
> >>
> >> My guess is there is an issue with the qup i2c driver seeing as it has 
> >> worked on
> >> other system without issue.
> >>
> >> CC'd some the latest developer on the qup i2c driver.
> >>
> >> I2C guys have any ideas on this?
> >>
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.

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

[Wolfram Sang]

On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > >> + struct iio_chan_spec const *chan, int *val,
> > >> + int *val2, long mask)
> > >> +{
> > >> + int ret, idx;
> > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > >> +
> > >> + mutex_lock(>lock);
> > >> + switch (mask) {
> > >> + case IIO_CHAN_INFO_RAW:
> > >> + if (iio_buffer_enabled(indio_dev)) {
> > >> + ret = -EBUSY;
> > >> + break;
> > >> + }
> > >> +
> > >> + ret = ads1015_set_power_state(data, true);
> > >> + if (ret < 0)
> > >> + break;
> > >
> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
> > > that I
> > > designed.
> > >
> > > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> > >
> > > Any ideas why that would be happening?
> > > I think it may be the return from pm_runtime_get_sync?
> > 
> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > 
> > Also adding printks in suspend/resume function would be helpful. Do
> > you have CONFIG_PM enabled?
> >
> 
> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> 
> > >
> > > When I comment out the break the readings come back but are not updated 
> > > continually.
> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > > updated.
> > 
> > I guess this is normal if set_power_state fails.
> 
> The hwmod driver works fine BTW.
> 
> My guess is there is an issue with the qup i2c driver seeing as it has worked 
> on
> other system without issue.
> 
> CC'd some the latest developer on the qup i2c driver.
> 
> I2C guys have any ideas on this?
> 

Adding some more people who recently worked on this. Might be nice to
know which kernel version you are using.

> > 
> > thanks,
> > Daniel.


signature.asc
Description: PGP signature

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

[Daniel Baluta]

On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
>> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
>> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>> > >> + struct iio_chan_spec const *chan, int *val,
>> > >> + int *val2, long mask)
>> > >> +{
>> > >> + int ret, idx;
>> > >> + struct ads1015_data *data = iio_priv(indio_dev);
>> > >> +
>> > >> + mutex_lock(>lock);
>> > >> + switch (mask) {
>> > >> + case IIO_CHAN_INFO_RAW:
>> > >> + if (iio_buffer_enabled(indio_dev)) {
>> > >> + ret = -EBUSY;
>> > >> + break;
>> > >> + }
>> > >> +
>> > >> + ret = ads1015_set_power_state(data, true);
>> > >> + if (ret < 0)
>> > >> + break;
>> > >
>> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
>> > > that I
>> > > designed.
>> > >
>> > > The above ads1015_set_power_state(data, true) is always returning 
>> > > -EINVAL.
>> > >
>> > > Any ideas why that would be happening?
>> > > I think it may be the return from pm_runtime_get_sync?
>> >
>> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
>> >
>> > Also adding printks in suspend/resume function would be helpful. Do
>> > you have CONFIG_PM enabled?
>> >
>>
>> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

Can you check the output of:
$ cat /sys/bus/iio/devices/iio:device0/power/runtime_status

* after insmod
* after a reading from sysfs

>>
>> > >
>> > > When I comment out the break the readings come back but are not updated 
>> > > continually.
>> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
>> > > updated.
>> >
>> > I guess this is normal if set_power_state fails.
>>
>> The hwmod driver works fine BTW.
>>
>> My guess is there is an issue with the qup i2c driver seeing as it has 
>> worked on
>> other system without issue.
>>
>> CC'd some the latest developer on the qup i2c driver.
>>
>> I2C guys have any ideas on this?
>>
>
> Adding some more people who recently worked on this. Might be nice to
> know which kernel version you are using.

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

[Daniel Baluta]

On Mon, Feb 8, 2016 at 4:44 PM, Daniel Baluta  wrote:
> On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang  wrote:
>> On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
>>> On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
>>> > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>>> > >> + struct iio_chan_spec const *chan, int *val,
>>> > >> + int *val2, long mask)
>>> > >> +{
>>> > >> + int ret, idx;
>>> > >> + struct ads1015_data *data = iio_priv(indio_dev);
>>> > >> +
>>> > >> + mutex_lock(>lock);
>>> > >> + switch (mask) {
>>> > >> + case IIO_CHAN_INFO_RAW:
>>> > >> + if (iio_buffer_enabled(indio_dev)) {
>>> > >> + ret = -EBUSY;
>>> > >> + break;
>>> > >> + }
>>> > >> +
>>> > >> + ret = ads1015_set_power_state(data, true);
>>> > >> + if (ret < 0)
>>> > >> + break;
>>> > >
>>> > > Just tested the driver on a Dragonboard 410C with a robotics mezzanine 
>>> > > that I
>>> > > designed.
>>> > >
>>> > > The above ads1015_set_power_state(data, true) is always returning 
>>> > > -EINVAL.
>>> > >
>>> > > Any ideas why that would be happening?
>>> > > I think it may be the return from pm_runtime_get_sync?
>>> >
>>> > Can you confirm that pm_runtime_get_sync fails? Using some printk?
>>> >
>>> > Also adding printks in suspend/resume function would be helpful. Do
>>> > you have CONFIG_PM enabled?
>>> >
>>>
>>> Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
>
> Can you check the output of:
> $ cat /sys/bus/iio/devices/iio:device0/power/runtime_status
>
> * after insmod
> * after a reading from sysfs
>
>>>
>>> > >
>>> > > When I comment out the break the readings come back but are not updated 
>>> > > continually.
>>> > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
>>> > > updated.
>>> >
>>> > I guess this is normal if set_power_state fails.
>>>
>>> The hwmod driver works fine BTW.
>>>
>>> My guess is there is an issue with the qup i2c driver seeing as it has 
>>> worked on
>>> other system without issue.
>>>
>>> CC'd some the latest developer on the qup i2c driver.
>>>
>>> I2C guys have any ideas on this?
>>>
>>
>> Adding some more people who recently worked on this. Might be nice to
>> know which kernel version you are using.

Jonathan,

I will send an update version with your comments addressed once
we sort out this runtime pm issue.

Michael,

If you questions we can discuss on #linux-iio IRC channel
under irc.oftc.net server.

thanks,
Daniel.

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

[Michael Welling]

On Tue, Feb 09, 2016 at 12:41:35AM +0530, Sricharan wrote:
> Hi,
> 
> > -Original Message-
> > From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> > Welling
> > Sent: Monday, February 08, 2016 10:07 PM
> > To: Wolfram Sang
> > Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> > Peter Meerwald-Stadler; Linux Kernel Mailing List;
> linux-...@vger.kernel.org;
> > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> > Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> > Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> > 
> > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > >> + struct iio_chan_spec const *chan, int
> *val,
> > > > > >> + int *val2, long mask) {
> > > > > >> + int ret, idx;
> > > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > > >> +
> > > > > >> + mutex_lock(>lock);
> > > > > >> + switch (mask) {
> > > > > >> + case IIO_CHAN_INFO_RAW:
> > > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > > >> + ret = -EBUSY;
> > > > > >> + break;
> > > > > >> + }
> > > > > >> +
> > > > > >> + ret = ads1015_set_power_state(data, true);
> > > > > >> + if (ret < 0)
> > > > > >> + break;
> > > > > >
> > > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > > mezzanine that I designed.
> > > > > >
> > > > > > The above ads1015_set_power_state(data, true) is always returning
> -
> > EINVAL.
> > > > > >
> > > > > > Any ideas why that would be happening?
> > > > > > I think it may be the return from pm_runtime_get_sync?
> > > > >
> > > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > > >
> > > > > Also adding printks in suspend/resume function would be helpful.
> > > > > Do you have CONFIG_PM enabled?
> > > > >
> > > >
> > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > > >
> > > > > >
> > > > > > When I comment out the break the readings come back but are not
> > updated continually.
> > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
> is
> > updated.
> > > > >
> > > > > I guess this is normal if set_power_state fails.
> > > >
> > > > The hwmod driver works fine BTW.
> > > >
> > > > My guess is there is an issue with the qup i2c driver seeing as it
> > > > has worked on other system without issue.
> > > >
> > > > CC'd some the latest developer on the qup i2c driver.
> > > >
> > > > I2C guys have any ideas on this?
> > > >
> > >
> > > Adding some more people who recently worked on this. Might be nice to
> > > know which kernel version you are using.
> > >
>  Which i2c bus is this connected to ? I can give a try with 410c to see why
> pm_runtime_get_sync from qup
>  fails.

It is on the lowspeed header. Here is my devicetree entry:

 i2c@78b6000 {
 /* On Low speed expansion */
 label = "LS-I2C0";
 status = "okay";
 
 pca: pca@40 {
 compatible = "nxp,pca9685-pwm";
 #pwm-cells = <2>;
 reg = <0x40>;
 };
 
 adc: adc@48 {
 compatible = "ti,ads1015";
 reg = <0x48>;
 };
 };

> 
> Regards,
>   Sricharan
> 
> 
> 

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

[Sricharan]

Hi,

> -Original Message-
> From: Michael Welling [mailto:mwellin...@gmail.com] On Behalf Of Michael
> Welling
> Sent: Monday, February 08, 2016 10:07 PM
> To: Wolfram Sang
> Cc: Daniel Baluta; Jonathan Cameron; Hartmut Knaack; Lars-Peter Clausen;
> Peter Meerwald-Stadler; Linux Kernel Mailing List;
linux-...@vger.kernel.org;
> Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
> 
> On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > >> + struct iio_chan_spec const *chan, int
*val,
> > > > >> + int *val2, long mask) {
> > > > >> + int ret, idx;
> > > > >> + struct ads1015_data *data = iio_priv(indio_dev);
> > > > >> +
> > > > >> + mutex_lock(>lock);
> > > > >> + switch (mask) {
> > > > >> + case IIO_CHAN_INFO_RAW:
> > > > >> + if (iio_buffer_enabled(indio_dev)) {
> > > > >> + ret = -EBUSY;
> > > > >> + break;
> > > > >> + }
> > > > >> +
> > > > >> + ret = ads1015_set_power_state(data, true);
> > > > >> + if (ret < 0)
> > > > >> + break;
> > > > >
> > > > > Just tested the driver on a Dragonboard 410C with a robotics
> > > > > mezzanine that I designed.
> > > > >
> > > > > The above ads1015_set_power_state(data, true) is always returning
-
> EINVAL.
> > > > >
> > > > > Any ideas why that would be happening?
> > > > > I think it may be the return from pm_runtime_get_sync?
> > > >
> > > > Can you confirm that pm_runtime_get_sync fails? Using some printk?
> > > >
> > > > Also adding printks in suspend/resume function would be helpful.
> > > > Do you have CONFIG_PM enabled?
> > > >
> > >
> > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
> > >
> > > > >
> > > > > When I comment out the break the readings come back but are not
> updated continually.
> > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value
is
> updated.
> > > >
> > > > I guess this is normal if set_power_state fails.
> > >
> > > The hwmod driver works fine BTW.
> > >
> > > My guess is there is an issue with the qup i2c driver seeing as it
> > > has worked on other system without issue.
> > >
> > > CC'd some the latest developer on the qup i2c driver.
> > >
> > > I2C guys have any ideas on this?
> > >
> >
> > Adding some more people who recently worked on this. Might be nice to
> > know which kernel version you are using.
> >
 Which i2c bus is this connected to ? I can give a try with 410c to see why
pm_runtime_get_sync from qup
 fails.

Regards,
  Sricharan

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

[Michael Welling]

On Mon, Feb 08, 2016 at 09:00:27PM +0100, Wolfram Sang wrote:
> > > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > > >> + struct iio_chan_spec const *chan, int
> 
> Guys, please quote only relevant sections.
>

Sorry. 

> >  pca: pca@40 {
> >  compatible = "nxp,pca9685-pwm";
> >  #pwm-cells = <2>;
> >  reg = <0x40>;
> >  };
> 
> Does accessing the pca work?
> 

Yes.

https://plus.google.com/+MichaelWelling79/posts/PdmGysBfZp4

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

[Wolfram Sang]

> > > On Mon, Feb 08, 2016 at 11:25:00AM +0100, Wolfram Sang wrote:
> > > > On Fri, Feb 05, 2016 at 06:32:45PM -0600, Michael Welling wrote:
> > > > > On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> > > > > > >> + struct iio_chan_spec const *chan, int

Guys, please quote only relevant sections.

>  pca: pca@40 {
>  compatible = "nxp,pca9685-pwm";
>  #pwm-cells = <2>;
>  reg = <0x40>;
>  };

Does accessing the pca work?



signature.asc
Description: PGP signature

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

[Jonathan Cameron]

On 06/02/16 11:05, Jonathan Cameron wrote:
> On 05/02/16 13:17, 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.
>>
>> Datasheet can be found here:
>>  http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
>>
>> Signed-off-by: Daniel Baluta 
> Hmm. The existing hwmon driver device tree bindings are less than ideal!
> (magic numbers left right and centre which always iritates me).
> Ah well, perhaps we can later look at deprecating those (whilst maintaining
> support) in favour of something a little more refined.  I'm guessing that
> binding has been around a while and we've all learnt more about device
> tree bindings since then.
> 
> You need to be a little more careful around buffer / non buffered mode
> state changes.  mlock in the struct iio_dev should be taken whenever
> you need to prevent a race in going in an out of buffered mode.
> (here you need it round most of the raw_read function)
> 
Ah, just noticed the docs in iio.h mark that lock as for core use only which
is wrong - it's used by both drivers and core.

Oops, patches welcome or I'll clean that up sometime.


> One trivial bit of english cleaning up in a comment.
> 
> Also would be ideal to have a resolution on Michael's issue as well
> though it sounds like it is not an issue with this driver from his
> debugging efforts.
> 
> Jonathan
> 
>> ---
>> Changes since v3:
>>  * fixed type connectd -> connected
>>  * move mutex outside of switch in read_raw to be consistent
>>  with write_raw
>>
>> Changes since v2:
>>  * push locking out of the switch in write_raw
>>  * fix  buf allocation in triggered buffer's handler
>>
>> Changes since v1:
>>  * addressed concerns about replacing the ads1015 hwmon driver
>>  * For the moment the IIO driver is compatible with hwmon
>>driver (dt bindings) the only thing left is to also add
>>support for ads1115.
>>  * DT bindings are described in Documentation/devicetree/
>>bindings/hwmon/ads1015.txt. If needed will copy this file
>>in a later patch to the IIO corresponding location.
>>  * addressed comments from Jonathan
>>  * added proper locking
>>  * added timestamp channel
>>  * removed magic constants
>>  * added some new lines to increase readability
>>  * used regmap_get_device instead of keeping a copy of
>>  i2c_client pointer.
>>  * used non-devm function to correct the cleanup order
>>
>>  drivers/iio/adc/Kconfig  |  13 +
>>  drivers/iio/adc/Makefile |   1 +
>>  drivers/iio/adc/ti-ads1015.c | 610 
>> +++
>>  3 files changed, 624 insertions(+)
>>  create mode 100644 drivers/iio/adc/ti-ads1015.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 60673b4..fad7e6a 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -370,6 +370,19 @@ config TI_ADC128S052
>>This driver can also be built as a module. If so, the module will be
>>called ti-adc128s052.
>>  
>> +config TI_ADS1015
>> +tristate "Texas Instruments ADS1015 ADC"
>> +depends on I2C && !SENSORS_ADS1015
>> +select REGMAP_I2C
>> +select IIO_BUFFER
>> +select IIO_TRIGGERED_BUFFER
>> +help
>> +  If you say yes here you get support for Texas Instruments ADS1015
>> +  ADC chip.
>> +
>> +  This driver can also be built as a module. If so, the module will be
>> +  called ti-ads1015.
>> +
>>  config TI_ADS8688
>>  tristate "Texas Instruments ADS8688"
>>  depends on SPI && OF
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index fb57e12..2ff70a3 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
>> new file mode 100644
>> index 000..596335f
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-ads1015.c
>> @@ -0,0 +1,610 @@
>> +/*
>> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
>> + *
>> + * Copyright (c) 2016, Intel Corporation.
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License.  See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
>> + *  * 0x48 - ADDR connected to 

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

[Jonathan Cameron]

On 05/02/16 13:17, 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.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
Hmm. The existing hwmon driver device tree bindings are less than ideal!
(magic numbers left right and centre which always iritates me).
Ah well, perhaps we can later look at deprecating those (whilst maintaining
support) in favour of something a little more refined.  I'm guessing that
binding has been around a while and we've all learnt more about device
tree bindings since then.

You need to be a little more careful around buffer / non buffered mode
state changes.  mlock in the struct iio_dev should be taken whenever
you need to prevent a race in going in an out of buffered mode.
(here you need it round most of the raw_read function)

One trivial bit of english cleaning up in a comment.

Also would be ideal to have a resolution on Michael's issue as well
though it sounds like it is not an issue with this driver from his
debugging efforts.

Jonathan

> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

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

[Jonathan Cameron]

On 05/02/16 21:44, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 11:02 PM, Lucas De Marchi
>  wrote:
>> Hi Daniel,
>>
>> On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  
>> wrote:
>>> +
>>> +static const struct i2c_device_id ads1015_id[] = {
>>> +   {"ads1015", 0},
>>> +   {}
>>> +};
>>
>> Since this module is not 100% compatible with the hwmon version,
>> wouldn't it be better to use another id?
> 
> Hmm, as it is now it should be 100% compatible with the hwmon driver
> for ads1015 device.
> 
> I don't have a strong preference for id here. Do you see any problems using
> this id?
We definitely want to keep the ID if at all possible as otherwise
we end up with a driver choice having to be made at compile time (or possibly
via the device tree).  If there is a compatibility issue, then Lucas,
please highlight it.

In the short term both drivers will exist and we'll rely on the Kconfig tricks
above to prevent them being both built.  Longer term, if this driver supports
all features of the HWMON driver (via the iio-hwmon bridge) then then extra
support in here will make it sensible to drop the HWMON driver (just not for
at least a cycle or two I would guess).

Jonathan
> 
>>
>> Other than that, I tested it on the MinnowBoard Max with a Drone Lure
>> connected and it works fine.
> 
> thanks,
> Daniel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Jonathan Cameron]

On 06/02/16 11:05, Jonathan Cameron wrote:
> On 05/02/16 13:17, 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.
>>
>> Datasheet can be found here:
>>  http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
>>
>> Signed-off-by: Daniel Baluta 
> Hmm. The existing hwmon driver device tree bindings are less than ideal!
> (magic numbers left right and centre which always iritates me).
> Ah well, perhaps we can later look at deprecating those (whilst maintaining
> support) in favour of something a little more refined.  I'm guessing that
> binding has been around a while and we've all learnt more about device
> tree bindings since then.
> 
> You need to be a little more careful around buffer / non buffered mode
> state changes.  mlock in the struct iio_dev should be taken whenever
> you need to prevent a race in going in an out of buffered mode.
> (here you need it round most of the raw_read function)
> 
Ah, just noticed the docs in iio.h mark that lock as for core use only which
is wrong - it's used by both drivers and core.

Oops, patches welcome or I'll clean that up sometime.


> One trivial bit of english cleaning up in a comment.
> 
> Also would be ideal to have a resolution on Michael's issue as well
> though it sounds like it is not an issue with this driver from his
> debugging efforts.
> 
> Jonathan
> 
>> ---
>> Changes since v3:
>>  * fixed type connectd -> connected
>>  * move mutex outside of switch in read_raw to be consistent
>>  with write_raw
>>
>> Changes since v2:
>>  * push locking out of the switch in write_raw
>>  * fix  buf allocation in triggered buffer's handler
>>
>> Changes since v1:
>>  * addressed concerns about replacing the ads1015 hwmon driver
>>  * For the moment the IIO driver is compatible with hwmon
>>driver (dt bindings) the only thing left is to also add
>>support for ads1115.
>>  * DT bindings are described in Documentation/devicetree/
>>bindings/hwmon/ads1015.txt. If needed will copy this file
>>in a later patch to the IIO corresponding location.
>>  * addressed comments from Jonathan
>>  * added proper locking
>>  * added timestamp channel
>>  * removed magic constants
>>  * added some new lines to increase readability
>>  * used regmap_get_device instead of keeping a copy of
>>  i2c_client pointer.
>>  * used non-devm function to correct the cleanup order
>>
>>  drivers/iio/adc/Kconfig  |  13 +
>>  drivers/iio/adc/Makefile |   1 +
>>  drivers/iio/adc/ti-ads1015.c | 610 
>> +++
>>  3 files changed, 624 insertions(+)
>>  create mode 100644 drivers/iio/adc/ti-ads1015.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 60673b4..fad7e6a 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -370,6 +370,19 @@ config TI_ADC128S052
>>This driver can also be built as a module. If so, the module will be
>>called ti-adc128s052.
>>  
>> +config TI_ADS1015
>> +tristate "Texas Instruments ADS1015 ADC"
>> +depends on I2C && !SENSORS_ADS1015
>> +select REGMAP_I2C
>> +select IIO_BUFFER
>> +select IIO_TRIGGERED_BUFFER
>> +help
>> +  If you say yes here you get support for Texas Instruments ADS1015
>> +  ADC chip.
>> +
>> +  This driver can also be built as a module. If so, the module will be
>> +  called ti-ads1015.
>> +
>>  config TI_ADS8688
>>  tristate "Texas Instruments ADS8688"
>>  depends on SPI && OF
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index fb57e12..2ff70a3 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
>> new file mode 100644
>> index 000..596335f
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-ads1015.c
>> @@ -0,0 +1,610 @@
>> +/*
>> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
>> + *
>> + * Copyright (c) 2016, Intel Corporation.
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License.  See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
>> + *  * 

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

[Jonathan Cameron]

On 05/02/16 21:44, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 11:02 PM, Lucas De Marchi
>  wrote:
>> Hi Daniel,
>>
>> On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  
>> wrote:
>>> +
>>> +static const struct i2c_device_id ads1015_id[] = {
>>> +   {"ads1015", 0},
>>> +   {}
>>> +};
>>
>> Since this module is not 100% compatible with the hwmon version,
>> wouldn't it be better to use another id?
> 
> Hmm, as it is now it should be 100% compatible with the hwmon driver
> for ads1015 device.
> 
> I don't have a strong preference for id here. Do you see any problems using
> this id?
We definitely want to keep the ID if at all possible as otherwise
we end up with a driver choice having to be made at compile time (or possibly
via the device tree).  If there is a compatibility issue, then Lucas,
please highlight it.

In the short term both drivers will exist and we'll rely on the Kconfig tricks
above to prevent them being both built.  Longer term, if this driver supports
all features of the HWMON driver (via the iio-hwmon bridge) then then extra
support in here will make it sensible to drop the HWMON driver (just not for
at least a cycle or two I would guess).

Jonathan
> 
>>
>> Other than that, I tested it on the MinnowBoard Max with a Drone Lure
>> connected and it works fine.
> 
> thanks,
> Daniel.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Jonathan Cameron]

On 05/02/16 13:17, 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.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
Hmm. The existing hwmon driver device tree bindings are less than ideal!
(magic numbers left right and centre which always iritates me).
Ah well, perhaps we can later look at deprecating those (whilst maintaining
support) in favour of something a little more refined.  I'm guessing that
binding has been around a while and we've all learnt more about device
tree bindings since then.

You need to be a little more careful around buffer / non buffered mode
state changes.  mlock in the struct iio_dev should be taken whenever
you need to prevent a race in going in an out of buffered mode.
(here you need it round most of the raw_read function)

One trivial bit of english cleaning up in a comment.

Also would be ideal to have a resolution on Michael's issue as well
though it sounds like it is not an issue with this driver from his
debugging efforts.

Jonathan

> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 

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

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan, int *val,
> >> + int *val2, long mask)
> >> +{
> >> + int ret, idx;
> >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> +
> >> + mutex_lock(>lock);
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_RAW:
> >> + if (iio_buffer_enabled(indio_dev)) {
> >> + ret = -EBUSY;
> >> + break;
> >> + }
> >> +
> >> + ret = ads1015_set_power_state(data, true);
> >> + if (ret < 0)
> >> + break;
> >
> > Just tested the driver on a Dragonboard 410C with a robotics mezzanine that 
> > I
> > designed.
> >
> > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> >
> > Any ideas why that would be happening?
> > I think it may be the return from pm_runtime_get_sync?
> 
> Can you confirm that pm_runtime_get_sync fails? Using some printk?
> 
> Also adding printks in suspend/resume function would be helpful. Do
> you have CONFIG_PM enabled?
>

Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

> >
> > When I comment out the break the readings come back but are not updated 
> > continually.
> > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > updated.
> 
> I guess this is normal if set_power_state fails.

The hwmod driver works fine BTW.

My guess is there is an issue with the qup i2c driver seeing as it has worked on
other system without issue.

CC'd some the latest developer on the qup i2c driver.

I2C guys have any ideas on this?

> 
> thanks,
> Daniel.

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

[Daniel Baluta]

On Fri, Feb 5, 2016 at 11:02 PM, Lucas De Marchi
 wrote:
> Hi Daniel,
>
> On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  
> wrote:
>> +
>> +static const struct i2c_device_id ads1015_id[] = {
>> +   {"ads1015", 0},
>> +   {}
>> +};
>
> Since this module is not 100% compatible with the hwmon version,
> wouldn't it be better to use another id?

Hmm, as it is now it should be 100% compatible with the hwmon driver
for ads1015 device.

I don't have a strong preference for id here. Do you see any problems using
this id?

>
> Other than that, I tested it on the MinnowBoard Max with a Drone Lure
> connected and it works fine.

thanks,
Daniel.

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

[Lucas De Marchi]

Hi Daniel,

On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  wrote:
> +
> +static const struct i2c_device_id ads1015_id[] = {
> +   {"ads1015", 0},
> +   {}
> +};

Since this module is not 100% compatible with the hwmon version,
wouldn't it be better to use another id?

Other than that, I tested it on the MinnowBoard Max with a Drone Lure
connected and it works fine.

thanks

Lucas De Marchi

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

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling  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.
> >>
> >> Datasheet can be found here:
> >>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> >>
> >> Signed-off-by: Daniel Baluta 
> >> ---
> >> Changes since v3:
> >>   * fixed type connectd -> connected
> >>   * move mutex outside of switch in read_raw to be consistent
> >>   with write_raw
> >>
> >> Changes since v2:
> >>   * push locking out of the switch in write_raw
> >>   * fix  buf allocation in triggered buffer's handler
> >>
> >> Changes since v1:
> >>   * addressed concerns about replacing the ads1015 hwmon driver
> >>   * For the moment the IIO driver is compatible with hwmon
> >> driver (dt bindings) the only thing left is to also add
> >> support for ads1115.
> >>   * DT bindings are described in Documentation/devicetree/
> >> bindings/hwmon/ads1015.txt. If needed will copy this file
> >> in a later patch to the IIO corresponding location.
> >>   * addressed comments from Jonathan
> >>   * added proper locking
> >>   * added timestamp channel
> >>   * removed magic constants
> >>   * added some new lines to increase readability
> >>   * used regmap_get_device instead of keeping a copy of
> >>   i2c_client pointer.
> >>   * used non-devm function to correct the cleanup order
> >>
> >>  drivers/iio/adc/Kconfig  |  13 +
> >>  drivers/iio/adc/Makefile |   1 +
> >>  drivers/iio/adc/ti-ads1015.c | 610 
> >> +++
> >>  3 files changed, 624 insertions(+)
> >>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> >>
> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >> index 60673b4..fad7e6a 100644
> >> --- a/drivers/iio/adc/Kconfig
> >> +++ b/drivers/iio/adc/Kconfig
> >> @@ -370,6 +370,19 @@ config TI_ADC128S052
> >> This driver can also be built as a module. If so, the module will 
> >> be
> >> called ti-adc128s052.
> >>
> >> +config TI_ADS1015
> >> + tristate "Texas Instruments ADS1015 ADC"
> >> + depends on I2C && !SENSORS_ADS1015
> >> + select REGMAP_I2C
> >> + select IIO_BUFFER
> >> + select IIO_TRIGGERED_BUFFER
> >> + help
> >> +   If you say yes here you get support for Texas Instruments ADS1015
> >> +   ADC chip.
> >> +
> >> +   This driver can also be built as a module. If so, the module will 
> >> be
> >> +   called ti-ads1015.
> >> +
> >>  config TI_ADS8688
> >>   tristate "Texas Instruments ADS8688"
> >>   depends on SPI && OF
> >> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >> index fb57e12..2ff70a3 100644
> >> --- a/drivers/iio/adc/Makefile
> >> +++ b/drivers/iio/adc/Makefile
> >> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> >>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> >>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> >>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> >> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
> >>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> >>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> >> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> >> new file mode 100644
> >> index 000..596335f
> >> --- /dev/null
> >> +++ b/drivers/iio/adc/ti-ads1015.c
> >> @@ -0,0 +1,610 @@
> >> +/*
> >> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> >> + *
> >> + * Copyright (c) 2016, Intel Corporation.
> >> + *
> >> + * This file is subject to the terms and conditions of version 2 of
> >> + * the GNU General Public License.  See the file COPYING in the main
> >> + * directory of this archive for more details.
> >> + *
> >> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> >> + *   * 0x48 - ADDR connected to Ground
> >> + *   * 0x49 - ADDR connected to Vdd
> >> + *   * 0x4A - ADDR connected to SDA
> >> + *   * 0x4B - ADDR connected to SCL
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define ADS1015_DRV_NAME "ads1015"
> >> +
> >> +#define ADS1015_CONV_REG 0x00
> >> +#define ADS1015_CFG_REG  0x01
> >> +
> >> +#define ADS1015_CFG_DR_SHIFT 5
> >> +#define ADS1015_CFG_MOD_SHIFT8
> >> +#define ADS1015_CFG_PGA_SHIFT9
> >> +#define ADS1015_CFG_MUX_SHIFT12
> >> +
> >> +#define 

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

[Daniel Baluta]

On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling  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.
>>
>> Datasheet can be found here:
>>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
>>
>> Signed-off-by: Daniel Baluta 
>> ---
>> Changes since v3:
>>   * fixed type connectd -> connected
>>   * move mutex outside of switch in read_raw to be consistent
>>   with write_raw
>>
>> Changes since v2:
>>   * push locking out of the switch in write_raw
>>   * fix  buf allocation in triggered buffer's handler
>>
>> Changes since v1:
>>   * addressed concerns about replacing the ads1015 hwmon driver
>>   * For the moment the IIO driver is compatible with hwmon
>> driver (dt bindings) the only thing left is to also add
>> support for ads1115.
>>   * DT bindings are described in Documentation/devicetree/
>> bindings/hwmon/ads1015.txt. If needed will copy this file
>> in a later patch to the IIO corresponding location.
>>   * addressed comments from Jonathan
>>   * added proper locking
>>   * added timestamp channel
>>   * removed magic constants
>>   * added some new lines to increase readability
>>   * used regmap_get_device instead of keeping a copy of
>>   i2c_client pointer.
>>   * used non-devm function to correct the cleanup order
>>
>>  drivers/iio/adc/Kconfig  |  13 +
>>  drivers/iio/adc/Makefile |   1 +
>>  drivers/iio/adc/ti-ads1015.c | 610 
>> +++
>>  3 files changed, 624 insertions(+)
>>  create mode 100644 drivers/iio/adc/ti-ads1015.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 60673b4..fad7e6a 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -370,6 +370,19 @@ config TI_ADC128S052
>> This driver can also be built as a module. If so, the module will be
>> called ti-adc128s052.
>>
>> +config TI_ADS1015
>> + tristate "Texas Instruments ADS1015 ADC"
>> + depends on I2C && !SENSORS_ADS1015
>> + select REGMAP_I2C
>> + select IIO_BUFFER
>> + select IIO_TRIGGERED_BUFFER
>> + help
>> +   If you say yes here you get support for Texas Instruments ADS1015
>> +   ADC chip.
>> +
>> +   This driver can also be built as a module. If so, the module will be
>> +   called ti-ads1015.
>> +
>>  config TI_ADS8688
>>   tristate "Texas Instruments ADS8688"
>>   depends on SPI && OF
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index fb57e12..2ff70a3 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
>> new file mode 100644
>> index 000..596335f
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-ads1015.c
>> @@ -0,0 +1,610 @@
>> +/*
>> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
>> + *
>> + * Copyright (c) 2016, Intel Corporation.
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License.  See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
>> + *   * 0x48 - ADDR connected to Ground
>> + *   * 0x49 - ADDR connected to Vdd
>> + *   * 0x4A - ADDR connected to SDA
>> + *   * 0x4B - ADDR connected to SCL
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define ADS1015_DRV_NAME "ads1015"
>> +
>> +#define ADS1015_CONV_REG 0x00
>> +#define ADS1015_CFG_REG  0x01
>> +
>> +#define ADS1015_CFG_DR_SHIFT 5
>> +#define ADS1015_CFG_MOD_SHIFT8
>> +#define ADS1015_CFG_PGA_SHIFT9
>> +#define ADS1015_CFG_MUX_SHIFT12
>> +
>> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
>> +#define ADS1015_CFG_MOD_MASK BIT(8)
>> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
>> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
>> +
>> +/* device operating modes */
>> +#define ADS1015_CONTINUOUS   0
>> +#define ADS1015_SINGLESHOT   1
>> +
>> +#define ADS1015_SLEEP_DELAY_MS   2000
>> +#define 

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

[Michael Welling]

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.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + ADS1015_AIN0_AIN1 = 0,
> + 

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

[Daniel Baluta]

On Fri, Feb 5, 2016 at 11:02 PM, Lucas De Marchi
 wrote:
> Hi Daniel,
>
> On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  
> wrote:
>> +
>> +static const struct i2c_device_id ads1015_id[] = {
>> +   {"ads1015", 0},
>> +   {}
>> +};
>
> Since this module is not 100% compatible with the hwmon version,
> wouldn't it be better to use another id?

Hmm, as it is now it should be 100% compatible with the hwmon driver
for ads1015 device.

I don't have a strong preference for id here. Do you see any problems using
this id?

>
> Other than that, I tested it on the MinnowBoard Max with a Drone Lure
> connected and it works fine.

thanks,
Daniel.

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

[Michael Welling]

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.
> 
> Datasheet can be found here:
>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> 
> Signed-off-by: Daniel Baluta 
> ---
> Changes since v3:
>   * fixed type connectd -> connected
>   * move mutex outside of switch in read_raw to be consistent
>   with write_raw
> 
> Changes since v2:
>   * push locking out of the switch in write_raw
>   * fix  buf allocation in triggered buffer's handler
> 
> Changes since v1:
>   * addressed concerns about replacing the ads1015 hwmon driver
>   * For the moment the IIO driver is compatible with hwmon
> driver (dt bindings) the only thing left is to also add
> support for ads1115.
>   * DT bindings are described in Documentation/devicetree/
> bindings/hwmon/ads1015.txt. If needed will copy this file
> in a later patch to the IIO corresponding location.
>   * addressed comments from Jonathan
>   * added proper locking
>   * added timestamp channel
>   * removed magic constants
>   * added some new lines to increase readability
>   * used regmap_get_device instead of keeping a copy of
>   i2c_client pointer.
>   * used non-devm function to correct the cleanup order
> 
>  drivers/iio/adc/Kconfig  |  13 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/ti-ads1015.c | 610 
> +++
>  3 files changed, 624 insertions(+)
>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60673b4..fad7e6a 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -370,6 +370,19 @@ config TI_ADC128S052
> This driver can also be built as a module. If so, the module will be
> called ti-adc128s052.
>  
> +config TI_ADS1015
> + tristate "Texas Instruments ADS1015 ADC"
> + depends on I2C && !SENSORS_ADS1015
> + select REGMAP_I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   If you say yes here you get support for Texas Instruments ADS1015
> +   ADC chip.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called ti-ads1015.
> +
>  config TI_ADS8688
>   tristate "Texas Instruments ADS8688"
>   depends on SPI && OF
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index fb57e12..2ff70a3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> new file mode 100644
> index 000..596335f
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1015.c
> @@ -0,0 +1,610 @@
> +/*
> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> + *
> + * Copyright (c) 2016, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> + *   * 0x48 - ADDR connected to Ground
> + *   * 0x49 - ADDR connected to Vdd
> + *   * 0x4A - ADDR connected to SDA
> + *   * 0x4B - ADDR connected to SCL
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADS1015_DRV_NAME "ads1015"
> +
> +#define ADS1015_CONV_REG 0x00
> +#define ADS1015_CFG_REG  0x01
> +
> +#define ADS1015_CFG_DR_SHIFT 5
> +#define ADS1015_CFG_MOD_SHIFT8
> +#define ADS1015_CFG_PGA_SHIFT9
> +#define ADS1015_CFG_MUX_SHIFT12
> +
> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
> +#define ADS1015_CFG_MOD_MASK BIT(8)
> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
> +
> +/* device operating modes */
> +#define ADS1015_CONTINUOUS   0
> +#define ADS1015_SINGLESHOT   1
> +
> +#define ADS1015_SLEEP_DELAY_MS   2000
> +#define ADS1015_DEFAULT_PGA  2
> +#define ADS1015_DEFAULT_DATA_RATE4
> +#define ADS1015_DEFAULT_CHAN 0
> +
> +enum ads1015_channels {
> + 

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

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling  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.
> >>
> >> Datasheet can be found here:
> >>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
> >>
> >> Signed-off-by: Daniel Baluta 
> >> ---
> >> Changes since v3:
> >>   * fixed type connectd -> connected
> >>   * move mutex outside of switch in read_raw to be consistent
> >>   with write_raw
> >>
> >> Changes since v2:
> >>   * push locking out of the switch in write_raw
> >>   * fix  buf allocation in triggered buffer's handler
> >>
> >> Changes since v1:
> >>   * addressed concerns about replacing the ads1015 hwmon driver
> >>   * For the moment the IIO driver is compatible with hwmon
> >> driver (dt bindings) the only thing left is to also add
> >> support for ads1115.
> >>   * DT bindings are described in Documentation/devicetree/
> >> bindings/hwmon/ads1015.txt. If needed will copy this file
> >> in a later patch to the IIO corresponding location.
> >>   * addressed comments from Jonathan
> >>   * added proper locking
> >>   * added timestamp channel
> >>   * removed magic constants
> >>   * added some new lines to increase readability
> >>   * used regmap_get_device instead of keeping a copy of
> >>   i2c_client pointer.
> >>   * used non-devm function to correct the cleanup order
> >>
> >>  drivers/iio/adc/Kconfig  |  13 +
> >>  drivers/iio/adc/Makefile |   1 +
> >>  drivers/iio/adc/ti-ads1015.c | 610 
> >> +++
> >>  3 files changed, 624 insertions(+)
> >>  create mode 100644 drivers/iio/adc/ti-ads1015.c
> >>
> >> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >> index 60673b4..fad7e6a 100644
> >> --- a/drivers/iio/adc/Kconfig
> >> +++ b/drivers/iio/adc/Kconfig
> >> @@ -370,6 +370,19 @@ config TI_ADC128S052
> >> This driver can also be built as a module. If so, the module will 
> >> be
> >> called ti-adc128s052.
> >>
> >> +config TI_ADS1015
> >> + tristate "Texas Instruments ADS1015 ADC"
> >> + depends on I2C && !SENSORS_ADS1015
> >> + select REGMAP_I2C
> >> + select IIO_BUFFER
> >> + select IIO_TRIGGERED_BUFFER
> >> + help
> >> +   If you say yes here you get support for Texas Instruments ADS1015
> >> +   ADC chip.
> >> +
> >> +   This driver can also be built as a module. If so, the module will 
> >> be
> >> +   called ti-ads1015.
> >> +
> >>  config TI_ADS8688
> >>   tristate "Texas Instruments ADS8688"
> >>   depends on SPI && OF
> >> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >> index fb57e12..2ff70a3 100644
> >> --- a/drivers/iio/adc/Makefile
> >> +++ b/drivers/iio/adc/Makefile
> >> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
> >>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
> >>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> >>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
> >> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
> >>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> >>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> >> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
> >> new file mode 100644
> >> index 000..596335f
> >> --- /dev/null
> >> +++ b/drivers/iio/adc/ti-ads1015.c
> >> @@ -0,0 +1,610 @@
> >> +/*
> >> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
> >> + *
> >> + * Copyright (c) 2016, Intel Corporation.
> >> + *
> >> + * This file is subject to the terms and conditions of version 2 of
> >> + * the GNU General Public License.  See the file COPYING in the main
> >> + * directory of this archive for more details.
> >> + *
> >> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
> >> + *   * 0x48 - ADDR connected to Ground
> >> + *   * 0x49 - ADDR connected to Vdd
> >> + *   * 0x4A - ADDR connected to SDA
> >> + *   * 0x4B - ADDR connected to SCL
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define ADS1015_DRV_NAME "ads1015"
> >> +
> >> +#define ADS1015_CONV_REG 0x00
> >> +#define ADS1015_CFG_REG  0x01
> >> +
> >> +#define ADS1015_CFG_DR_SHIFT 5
> >> +#define ADS1015_CFG_MOD_SHIFT8
> >> +#define ADS1015_CFG_PGA_SHIFT9
> >> +#define ADS1015_CFG_MUX_SHIFT  

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

[Daniel Baluta]

On Fri, Feb 5, 2016 at 7:25 PM, Michael Welling  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.
>>
>> Datasheet can be found here:
>>   http://www.ti.com.cn/cn/lit/ds/symlink/ads1015.pdf
>>
>> Signed-off-by: Daniel Baluta 
>> ---
>> Changes since v3:
>>   * fixed type connectd -> connected
>>   * move mutex outside of switch in read_raw to be consistent
>>   with write_raw
>>
>> Changes since v2:
>>   * push locking out of the switch in write_raw
>>   * fix  buf allocation in triggered buffer's handler
>>
>> Changes since v1:
>>   * addressed concerns about replacing the ads1015 hwmon driver
>>   * For the moment the IIO driver is compatible with hwmon
>> driver (dt bindings) the only thing left is to also add
>> support for ads1115.
>>   * DT bindings are described in Documentation/devicetree/
>> bindings/hwmon/ads1015.txt. If needed will copy this file
>> in a later patch to the IIO corresponding location.
>>   * addressed comments from Jonathan
>>   * added proper locking
>>   * added timestamp channel
>>   * removed magic constants
>>   * added some new lines to increase readability
>>   * used regmap_get_device instead of keeping a copy of
>>   i2c_client pointer.
>>   * used non-devm function to correct the cleanup order
>>
>>  drivers/iio/adc/Kconfig  |  13 +
>>  drivers/iio/adc/Makefile |   1 +
>>  drivers/iio/adc/ti-ads1015.c | 610 
>> +++
>>  3 files changed, 624 insertions(+)
>>  create mode 100644 drivers/iio/adc/ti-ads1015.c
>>
>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> index 60673b4..fad7e6a 100644
>> --- a/drivers/iio/adc/Kconfig
>> +++ b/drivers/iio/adc/Kconfig
>> @@ -370,6 +370,19 @@ config TI_ADC128S052
>> This driver can also be built as a module. If so, the module will be
>> called ti-adc128s052.
>>
>> +config TI_ADS1015
>> + tristate "Texas Instruments ADS1015 ADC"
>> + depends on I2C && !SENSORS_ADS1015
>> + select REGMAP_I2C
>> + select IIO_BUFFER
>> + select IIO_TRIGGERED_BUFFER
>> + help
>> +   If you say yes here you get support for Texas Instruments ADS1015
>> +   ADC chip.
>> +
>> +   This driver can also be built as a module. If so, the module will be
>> +   called ti-ads1015.
>> +
>>  config TI_ADS8688
>>   tristate "Texas Instruments ADS8688"
>>   depends on SPI && OF
>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> index fb57e12..2ff70a3 100644
>> --- a/drivers/iio/adc/Makefile
>> +++ b/drivers/iio/adc/Makefile
>> @@ -36,6 +36,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>  obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
>> +obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
>>  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
>>  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>>  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>> diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
>> new file mode 100644
>> index 000..596335f
>> --- /dev/null
>> +++ b/drivers/iio/adc/ti-ads1015.c
>> @@ -0,0 +1,610 @@
>> +/*
>> + * ADS1015 - Texas Instruments Analog-to-Digital Converter
>> + *
>> + * Copyright (c) 2016, Intel Corporation.
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License.  See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * IIO driver for ADS1015 ADC 7-bit I2C slave address:
>> + *   * 0x48 - ADDR connected to Ground
>> + *   * 0x49 - ADDR connected to Vdd
>> + *   * 0x4A - ADDR connected to SDA
>> + *   * 0x4B - ADDR connected to SCL
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define ADS1015_DRV_NAME "ads1015"
>> +
>> +#define ADS1015_CONV_REG 0x00
>> +#define ADS1015_CFG_REG  0x01
>> +
>> +#define ADS1015_CFG_DR_SHIFT 5
>> +#define ADS1015_CFG_MOD_SHIFT8
>> +#define ADS1015_CFG_PGA_SHIFT9
>> +#define ADS1015_CFG_MUX_SHIFT12
>> +
>> +#define ADS1015_CFG_DR_MASK  GENMASK(7, 5)
>> +#define ADS1015_CFG_MOD_MASK BIT(8)
>> +#define ADS1015_CFG_PGA_MASK GENMASK(11, 9)
>> +#define ADS1015_CFG_MUX_MASK GENMASK(14, 12)
>> +
>> +/* device operating modes */
>> +#define ADS1015_CONTINUOUS   0
>> +#define ADS1015_SINGLESHOT   1
>> +
>> +#define 

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

[Lucas De Marchi]

Hi Daniel,

On Fri, Feb 5, 2016 at 11:17 AM, Daniel Baluta  wrote:
> +
> +static const struct i2c_device_id ads1015_id[] = {
> +   {"ads1015", 0},
> +   {}
> +};

Since this module is not 100% compatible with the hwmon version,
wouldn't it be better to use another id?

Other than that, I tested it on the MinnowBoard Max with a Drone Lure
connected and it works fine.

thanks

Lucas De Marchi

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

[Michael Welling]

On Fri, Feb 05, 2016 at 09:32:34PM +0200, Daniel Baluta wrote:
> >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan, int *val,
> >> + int *val2, long mask)
> >> +{
> >> + int ret, idx;
> >> + struct ads1015_data *data = iio_priv(indio_dev);
> >> +
> >> + mutex_lock(>lock);
> >> + switch (mask) {
> >> + case IIO_CHAN_INFO_RAW:
> >> + if (iio_buffer_enabled(indio_dev)) {
> >> + ret = -EBUSY;
> >> + break;
> >> + }
> >> +
> >> + ret = ads1015_set_power_state(data, true);
> >> + if (ret < 0)
> >> + break;
> >
> > Just tested the driver on a Dragonboard 410C with a robotics mezzanine that 
> > I
> > designed.
> >
> > The above ads1015_set_power_state(data, true) is always returning -EINVAL.
> >
> > Any ideas why that would be happening?
> > I think it may be the return from pm_runtime_get_sync?
> 
> Can you confirm that pm_runtime_get_sync fails? Using some printk?
> 
> Also adding printks in suspend/resume function would be helpful. Do
> you have CONFIG_PM enabled?
>

Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.

> >
> > When I comment out the break the readings come back but are not updated 
> > continually.
> > If I read in_voltage0-voltage1_raw then in_voltage0_raw the value is 
> > updated.
> 
> I guess this is normal if set_power_state fails.

The hwmod driver works fine BTW.

My guess is there is an issue with the qup i2c driver seeing as it has worked on
other system without issue.

CC'd some the latest developer on the qup i2c driver.

I2C guys have any ideas on this?

> 
> thanks,
> Daniel.