[lkml]   [2010]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/3] omap: add hwspinlock device
On Wed, Oct 20, 2010 at 1:12 AM, Grant Likely <> wrote:
> On Tue, Oct 19, 2010 at 3:02 PM, Ohad Ben-Cohen <> wrote:
>> i2c-omap, which is subsys_initcall (the I2C bus is shared between the
>> A9 and the M3 on some OMAP4 boards).
> Man. this is getting ugly.  I think we need to discuss how to solve
> this at the Plumbers micro-conference. It kind of fits in with the
> whole embedded (ab)use of the device model topic anyway. Actually,
> this particular case isn't bad, but the moving of i2c and spi busses
> to an earlier initcall is just band-aiding the real problem of driver
> probe order dependencies.


On Wed, Oct 20, 2010 at 1:53 AM, Kevin Hilman
<> wrote:
> Rather than moving towards having more drivers have to be built in (and
> depend on their probe order) we need to be moving towards building all
> these drivers as modules, including omap-i2c.


This whole thing is a mess, and today it's being solved in the wrong,
non-scalable and error-prone way.

The question is whether we want to gate hwspinlock until this issue is solved ?

On Wed, Oct 20, 2010 at 3:20 AM, Ryan Mallon <> wrote:
> The issue of probe order still needs to be resolved for those of us who
> do want all the drivers built into the kernel.

What about doing something similar to the way suspend/resume and the
device hierarchy interact ?

device_resume waits for its parent to be resumed before waking up the
device - this sounds similar to what ->probe() should do: wait for its
device dependency to probe first (so in this case, i2c-omap should
wait for hwspinlock).

Conversely, device_suspend waits for all its children to be suspended
before continuing, which sounds just like what ->remove() should do
(so again, in this case, the hwspinlock device should wait for all its
users to be removed before bailing).

This is just a quick thought, I haven't even began to think of all the
use cases and requirements.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-10-20 16:13    [W:0.106 / U:1.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site