Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753312AbbBYTrf (ORCPT ); Wed, 25 Feb 2015 14:47:35 -0500 Received: from mail-oi0-f52.google.com ([209.85.218.52]:45606 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752748AbbBYTrc convert rfc822-to-8bit (ORCPT ); Wed, 25 Feb 2015 14:47:32 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Mark Brown , "Krzysztof Kozlowski" From: Mike Turquette In-Reply-To: <20150118134124.GC2809@sirena.org.uk> 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" References: <1421419194-1849-1-git-send-email-p.osmialowsk@samsung.com> <54BB9100.7000506@samsung.com> <20150118134124.GC2809@sirena.org.uk> Message-ID: <20150225194715.421.87263@quantum> User-Agent: alot/0.3.5 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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1736 Lines: 41 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/