> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Aguirre Rodriguez, Sergio > Alberto > Sent: Tuesday, September 29, 2009 8:27 PM > To: tomi.valkeinen@xxxxxxxxx > Cc: Deak Imre (Nokia-D/Helsinki); linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [RFC][PATCH] omapfb: Condition mutex acquisition > > From: Tomi Valkeinen [tomi.valkeinen@xxxxxxxxx] > Sent: Tuesday, September 29, 2009 9:53 AM > > On Tue, 2009-09-29 at 16:34 +0200, ext Aguirre Rodriguez, Sergio > Alberto > > wrote: > > > 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? > > > > Oh, I wasn't implying that there's something wrong with the fix, I > just > > didn't know what it was fixing =). > > Ok, no prob :) Should I improve the patch description? > Any suggestion coming from an expert ;) ? > > > > > Looks like a valid fix to me. > > Great! :) Once you're ok with the description, I can add your > "Acked-by:" and > send to linux-fb-devel ML. Would that be ok? > [Hiremath, Vaibhav] Hi Sergio, I also think this is valid fix. Tomi, Don't you think we should also make use of mm_lock in new OMAP2 Fbdev driver, to be more specific and safer side? Thanks, Vaibhav > 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 -- 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
