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(&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.
> >
> > > >
> > > > 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.
