From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Turquette Subject: Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem Date: Wed, 25 Feb 2015 11:47:15 -0800 Message-ID: <20150225194715.421.87263@quantum> References: <1421419194-1849-1-git-send-email-p.osmialowsk@samsung.com> <54BB9100.7000506@samsung.com> <20150118134124.GC2809@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20150118134124.GC2809@sirena.org.uk> Sender: linux-samsung-soc-owner@vger.kernel.org To: Mark Brown , Krzysztof Kozlowski Cc: Tomasz Figa , Paul Osmialowski , Wolfram Sang , Jonathan Corbet , Greg Kroah-Hartman , Kukjin Kim , "linux-i2c@vger.kernel.org" , "linux-doc@vger.kernel.org" , linux-kernel , "linux-samsung-soc@vger.kernel.org" , Peter De Schrijver , Russell King , Sylwester Nawrocki List-Id: linux-i2c@vger.kernel.org Quoting Mark Brown (2015-01-18 05:41:24) > On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote: > > W dniu 18.01.2015 o 07:30, Tomasz Figa pisze: > > > >So, the question is, do we actually have hardware that _really_ > > >requires _actual_ preparation or all the clk_prepare_enable()s in I2C > > >drivers (at least in i2c-s3c2410) are just to simplify the code? > > > I completely forgot that you already thought about this deadlock in 2014. I > > think we can try the no-prepare way for i2c-s3c2410. However this would be > > only workaround for specific chip. Other buses (like SPI) would require > > similar changes. > > Right, and it's every single driver which would need an update too which > is a bit icky and sad. On the other hand a more detailed fix is going > to involve trying to make the clock API locking more fine grained which > isn't fun. Not fun is right. Please see Stephen's attempt here: http://lkml.kernel.org/r/<1409792466-5092-1-git-send-email-sboyd@codeaurora.org> I'm hoping this approach will be revisited soon. Regards, Mike > > > I wondered why this was not observed (at least not observed by me with > > lockdep) on Gear 2 (Rinato) board. This is quite similar case: the S2MPS14 > > PMIC provides regulators and 32kHz clocks. I think it is exactly the same > > pattern as for max77686... but somehow lockdep never reported that deadlock > > there. > > Mostly the clocks on PMICs never get changed at runtime which helps a > lot here.