Messages in this thread | | | From | John Stultz <> | Date | Mon, 27 Feb 2017 15:33:16 -0800 | Subject | Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race |
| |
On Sat, Feb 25, 2017 at 11:36 AM, Daniel Vetter <daniel@ffwll.ch> 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
| |