Date: Mon, 7 Mar 2016 12:59:22 +0100
From: Pali =?utf-8?B?Um9ow6Fy?= <pali.rohar@gmail.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
        Jarkko Nikula <jarkko.nikula@bitmer.com>,
        Lars-Peter Clausen <lars@metafoo.de>, linux-kernel@vger.kernel.org,
        linux-omap@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
        Aaro Koskinen <aaro.koskinen@iki.fi>, Tony Lindgren <tony@atomide.com>,
        Nishanth Menon <nm@ti.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>, merlijn@wizzup.org
Subject: Re: Nokia N900 - audio TPA6130A2 problems
Message-ID: <20160307115922.GC20264@pali>
References: <201507251228.27128@pali>
 <55BFB77C.6000208@bitmer.com>
 <55C0638F.30000@ti.com>
 <201601050034.12810@pali>
 <20160306152339.GA428@earth>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160306152339.GA428@earth>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2797
Lines: 66

On Sunday 06 March 2016 16:23:39 Sebastian Reichel wrote:
> Hi Pali,
> 
> On Tue, Jan 05, 2016 at 12:34:12AM +0100, Pali Rohár wrote:
> > On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote:
> > > On 08/03/2015 09:48 PM, Jarkko Nikula wrote:
> > > > It is well possible that some regression got introduced to
> > > > TPA6130A2 I2C communication over the years without nobody than you
> > > > now notices. We used to do QA back in Meego N900 days but that was
> > > > pre 3.x kernels.
> > > 
> > > No major changes has been done to the tpa driver during the past
> > > years... I wanted to do some updates, like moving it to regmap, but
> > > as you said, n900 is the only user (and n9) and I do not feel
> > > comfortable to hack on a device where I do not have serial
> > > console... And I'm using the n900 time to time also.
> > > 
> > > >> So maybe something similar? Kernel expects that some PM or
> > > >> regulator parts are initialized, but they are only sometimes?
> > > >> Just speculation...
> > > > 
> > > > I'm thinking the same. I could figure SCL could be stuck low if TPA
> > > > or some other chip connected to the same I2C bus is without power
> > > > and is pulling I2C signals down.
> > > 
> > > What would happen with the SCL stuck on i2c.2 bus if you remove the
> > > tpa driver from the kernel? If you remove the other drivers for the
> > > devices on i2c.2?
> > 
> > Hi Peter and Jarkko! Do you have some code samples for testing? Or 
> > something else which I can test? This problem is still reproducible on 
> > more N900 devices and I would like to see it fixed.
> 
> I have not seen your error with N900, but while working on N950 I
> noticed similar problems when I added lp5523. I think the lp5523
> reset routine locks up the omap i2c controller, since the lp5523
> will stop responding in the middle of an ongoing communication:
> 
> static void lp55xx_reset_device(struct lp55xx_chip *chip)
> {
> 	struct lp55xx_device_config *cfg = chip->cfg;
> 	u8 addr = cfg->reset.addr;
> 	u8 val  = cfg->reset.val;
> 
> 	/* no error checking here because no ACK from the device after reset */
> 	lp55xx_write(chip, addr, val);
> }
> 
> Since tpa6130a2 is on the same i2c bus, it would be affected by
> this. You can check this by just commenting out the call to
> lp55xx_reset_device() in the probe function, since it's not
> needed on N900 (chip reset is done via enable gpio anyways).
> 
> I'm pretty sure, there were no bus lock problems when I added
> lp5523 to N900 dts, so this having problems with this is probably
> a regression in the omap-i2c driver.
> 
> -- Sebastian

Hi Sebastian! Thank you for info. That error occurs randomly, not
always. When I see it next time, I will try to comment that function if
it happens...

-- 
Pali Rohár
pali.rohar@gmail.com