On Sat, Feb 25, 2017 at 11:36 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Feb 24, 2017 at 05:25:16PM -0800, John Stultz wrote: >> In some cases I've been seeing a race where two framebuffers >> would be initialized, as kirin_fbdev_output_poll_changed() >> might get called quickly in succession, resulting in the >> initialization happening twice. This could cause the system >> to boot up with a blank screen. >> >> This patch adds a simple mutex to serialize it and seems to >> avoid the race. >> >> Suggestions or feedback would be greatly appreciated! > > I feel a bit like a broken record, but: > > Instead of reinventing broken delayed fbdev setup everywhere, can we > polish Thierry's patches to move that into the fbdev helpers in the core? > hisilicon isn't the only driver the (re)invents this weel, it'd be really > awesome if we could fix this bug just once ... > > For reference, the patches: > > http://markmail.org/message/d3jc4vebkndtvlkf#query:+page:1+mid:d3jc4vebkndtvlkf+state:results Thanks for the pointer here, and apologies, I really am not very deep into or do that much following DRM development. I just am chasing bugs on my board and trying to fix them up, so I wasn't aware this was something brought up before. > I guess Thierry got sidetracked on these, but except for a bit of locking > scheme polish I think they've been mostly ready. Shouldn't be much work to > refresh them, hunt for other new drivers reinventing this wheel, do the > locking polish maybe and then get them landed. I'll take a look at it and see what I can sort out. thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
