lkml.org 
[lkml]   [2015]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem
Date
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.


\
 
 \ /
  Last update: 2015-02-25 21:01    [W:0.044 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site