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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> 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(&data->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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux