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@xxxxxxxxxxxxxx> 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-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
