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

    > -----Original Message-----
    > From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-
    > owner@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-iio@vger.kernel.org; 'Lucas De Marchi'; 'Andy Gross'; 'Pramod
    Gurav';
    > 'Bjorn Andersson'; 'Guenter Roeck'; eibach@gdsys.de; linux-arm-
    > msm@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:mwelling79@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-iio@vger.kernel.org;
    > > > Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
    > > > Roeck; eibach@gdsys.de; Sricharan R; linux-arm-msm@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(&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

    Regards,
    Sricharan

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