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/<[email protected]>
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.