lkml.org 
[lkml]   [2016]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
    From
    <snap headers>

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

    \
     
     \ /
      Last update: 2016-02-10 14:21    [W:3.523 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site