RE: [RFC][PATCH] omapfb: Condition mutex acquisition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Tomi Valkeinen [tomi.valkeinen@xxxxxxxxx]
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 <saaguirre@xxxxxx>
> >
> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux