From: Tomi Valkeinen [[email protected]]
Sent: Tuesday, September 29, 2009 9:22 AM
> On Tue, 2009-09-29 at 16:14 +0200, ext Aguirre Rodriguez, Sergio Alberto
> wrote:
> > From: Sergio Aguirre <[email protected]>
> >
> > Acquiring mutex before framebuffer registration doesn't make sense,
> > As there's no danger of external access to the memory related fields.
>
> What problem does this patch solve? It makes the code more complex.
>
Tomi,
Thanks for your time.
The problem was that, during platform driver registration,
this sequence was executed:
-> omapfb_probe
-> omapfb_do_probe
-> planes_init
-> fbinfo_init
-> set_fb_fix
...
-> register_framebuffer
And then, inside that function, an attempt of acquiring a
mutex failed, because it wasn't initialized before trying it:
mutex_lock(&fbi->mm_lock);
It is actually initialized later in omapfb_do_probe in register_framebuffer
call.
So, how is the best to solve this then?
BTW, this problem is found on current Linus tree, and in
current l-o tree aswell, and i saw it on my 3430SDP VG5.0.1.
Regards,
Sergio
> Tomi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
