From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem Date: Sun, 18 Jan 2015 13:41:24 +0000 Message-ID: <20150118134124.GC2809@sirena.org.uk> References: <1421419194-1849-1-git-send-email-p.osmialowsk@samsung.com> <54BB9100.7000506@samsung.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Return-path: Content-Disposition: inline In-Reply-To: <54BB9100.7000506@samsung.com> Sender: linux-doc-owner@vger.kernel.org To: 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" , Michael Turquette , Peter De Schrijver , Russell King , Sylwester Nawrocki List-Id: linux-i2c@vger.kernel.org --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. > 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. --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUu7gDAAoJECTWi3JdVIfQPmMH/3afYEY4WeiR+Sf1FQumwTFo ed0ITCeLzT0D1WSSg75AL1WMOdkwRILhNkFWN9KKwOI2gAbWFJhF4Eg8fsyHGjuu u17mnrg8okxJjbWRP7fykFhXMhjNy5etUghTwVxgUYsM6UW982F91HrHFUgv9Fkd BgfnfBE9Md4nbIhD8b1K5BECpD61dteSjzWAGd7BXQ4UpJhdDhpUEnccykjvy5jC s9AJQEQIU7ttsiNF+mBUktT4TjXqiJFj7j3lI1MIFwK4NMqHGCeZooRlmo441hEO zKJszwMdFNjKVR87rUMSn4m9IwySIWQEhLbBL859X+rLl2XBQfECf72ednVpB+U= =Hh0i -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy--