From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sricharan" Subject: RE: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support Date: Wed, 10 Feb 2016 20:39:04 +0530 Message-ID: <003201d16415$0eb1a8f0$2c14fad0$@codeaurora.org> References: <1454678238-16313-1-git-send-email-daniel.baluta@intel.com> <20160205172457.GA16778@deathstar> <20160206003245.GA1329@deathstar> <20160208102459.GC2220@tetsubishi> <20160208163632.GA3630@deathstar> <01fd01d162a4$8e28c450$aa7a4cf0$@codeaurora.org> <20160208191658.GA23145@deathstar> <001b01d163fd$bfb15280$3f13f780$@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Content-Language: en-us Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: 'Daniel Baluta' Cc: 'Michael Welling' , 'Wolfram Sang' , 'Jonathan Cameron' , 'Hartmut Knaack' , 'Lars-Peter Clausen' , 'Peter Meerwald-Stadler' , 'Linux Kernel Mailing List' , linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 'Lucas De Marchi' , 'Andy Gross' , 'Pramod Gurav' , 'Bjorn Andersson' , 'Guenter Roeck' , eibach-dJ+jgKLZIg4@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-arm-msm@vger.kernel.org ... > >> > > > > > >> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EI= NVAL. > >> > > > > > >> > > > > > > > >> > > > > > > When I comment out the break the readings come back bu= t > >> > > > > > > are not > >> > > updated continually. > >> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_ra= w > >> > > > > > > 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 seei= ng > >> > > > > 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 b= e > >> > > > 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 =3D "LS-I2C0"; > >> status =3D "okay"; > >> > >> pca: pca@40 { > >> compatible =3D "nxp,pca9685-pwm"; > >> #pwm-cells =3D <2>; > >> reg =3D <0x40>; > >> }; > >> > >> adc: adc@48 { > >> compatible =3D "ti,ads1015"; > >> reg =3D <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 >=20 > Hi Sricharan, >=20 > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c > right? > Yes. =20 > I'm asking this because this driver doesn't seem to support runtime p= m and > there is no check for regmap_write/regmap_write return code in the pr= obe > function. Hmm to be clear, so it=E2=80=99s the pm_runtime_getsync from i2c-qup= which fails right ? I was tracking that when there are i2c_xfers from pwm. I did not see= any failures there. So wanted to know the correct sequence to reproduce. =20 Regards, Sricharan =20