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.
Attachment:
signature.asc
Description: Digital signature
