Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbcCGL7f (ORCPT ); Mon, 7 Mar 2016 06:59:35 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:33419 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146AbcCGL70 (ORCPT ); Mon, 7 Mar 2016 06:59:26 -0500 Date: Mon, 7 Mar 2016 12:59:22 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Sebastian Reichel Cc: Peter Ujfalusi , Jarkko Nikula , Lars-Peter Clausen , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Pavel Machek , Aaro Koskinen , Tony Lindgren , Nishanth Menon , Ivaylo Dimitrov , 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 List-ID: X-Mailing-List: linux-kernel@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