lkml.org 
[lkml]   [2015]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-01-18 15:01    [W:0.083 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site