From: linux-omap-owner@xxxxxxxxxxxxxxx [linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Aguirre Rodriguez, Sergio Alberto [saaguirre@xxxxxx] Sent: Tuesday, September 29, 2009 9:34 AM > 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 Forgot to mark that the attempt to use the mutex its done here in set_fb_fix function > ... > -> 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. BTW #2. This makes framebuffer work on my board. I can see Tux during bootup, and also i was able to run some basic framebuffer tests on my board without apparent issues. > > 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
