Re: [RFC][PATCH v2] drm: kirin: Add a mutex to avoid fb initialization race

[John Stultz]

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