Device probe order (i2c regulator vs. platform device)

Andy Green andy at warmcat.com
Thu Mar 25 06:52:06 EDT 2010


On 03/25/10 10:22, Somebody in the thread at some point said:
> On Wed, Mar 24, 2010 at 02:38:31PM +0000, Andy Green wrote:
>> On 03/24/10 14:01, Somebody in the thread at some point said:
>
>>> I really am very sure that nobody has ever reported any issues here -
>
>> There's plenty of out-of-tree code.  I'm not trying to blame you for
>
> I'm really wary of trusting out of tree reports since a high proportion
> of the time they turn out to be due to people not being aware of some
> existing support or things like API misuse.  New issues do crop up, but
> anecdotes about issues that have been diagnosed but not reported need to
> be taken with a grain of salt.

I can see your point of view, but you sound...

> Like I say, the regulator drivers just don't do anything in suspend
> in mainline which means that ordering issues from them seem a bit
> suspicious.

The I2C bus goes down at some point in suspend, then you can't talk to 
the PMU or other I2C device any more.

If there are other drivers that are trying to do something themselves 
their power when they go down, or indeed ask for anything else from 
another driver who is on a separate bus and they don't have any formal 
relationship with it hierarchy-wise, then it's racing with the other 
driver or the bus going down.

In that case, those drivers who want to ask for things in suspend or 
resume, or who trigger indirectly those requests at that time, need to 
mark themselves as being dependencies of the thing they're reliant on 
talking to.  Then everything is taken care of.

GTA02 had a bunch of these kind of relationships... it's possible they 
were all evil and could be eliminated but actually framebuffer vs LCM 
controller vs PMU vs backlight driver race I dunno what else you're 
meant to do except make the relationship explicit and everything is 
cool.  Backlight really is dependent on PMU being there if it wants to 
change state while it goes down (eg, fade down itself), correct thing 
really does seem to be make the dependency explicit via the device 
parent stuff.

If you have a better way, I am standing by ready to learn something.

-Andy



More information about the linux-arm-kernel mailing list