On Mon, Feb 8, 2016 at 12:25 PM, Wolfram Sang <w...@the-dreams.de> 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.