Re: [Linux-fbdev-devel] [APPLIED] [PATCH] omapfb: Reorder Register_framebuffer call

[Florian Tobias Schandinat <FlorianSchandinat@gmx.de>]

Jan Blunck schrieb:
> On Tue, Sep 22, 2009 at 6:57 PM, Aguirre Rodriguez, Sergio Alberto
> <saaguirre@ti.com> wrote:
>> From: Tony Lindgren [tony@atomide.com]
>> Sent: Tuesday, September 22, 2009 11:28 AM
>>> * Jan Blunck <jblunck@infradead.org> [090922 07:59]:
>>>> On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren <tony@atomide.com> wrote:
>>>>> This patch has been applied to the linux-omap
>>>>> by youw fwiendly patch wobot.
>>>>>
>>>>> Branch in linux-omap: omap-fixes
>>>>>
>>>>> Initial commit ID (Likely to change): 9aef1066fb5ca8506068eaab1c552ecca4c85475
>>>>>
>>>>> PatchWorks
>>>>> http://patchwork.kernel.org/patch/47089/
>>>>>
>>> Added back the original Cc's that were dropped from the linux-omap
>>> commit message.
>>>
>>>> Is it actually safe to do this? The framebuffer can be used directly
>>>> after it is registered. In this case it would mean it is used before
>>>> it is even fully initialized (set_fb_var(), set_fb_fix(), ... are
>>>> being called).
>>> Good point, dropping the patch.
>> Hmm, ok. I guess i'll rework this patch considering that..
>>
>> I ran some framebuffer tests with this patch applied, and they worked fine for me.
>>
>> The only thing is that i didn't saw Tux on bootup...
>>
>> Actually, nobody ever gave this kind of feedback, which was the initial idea.
>>
> 
> Sorry, I didn't look into it earlier.
> 
> BTW, I actually wonder if it's really necessary to initialize the
> mutex in register_framebuffer() or why it couldn't be done during
> allocation.

This small discussion between Linus and Krzysztof might explain it:
http://marc.info/?l=linux-kernel&m=124703449332064&w=2
or to summarize:
It is done the way it is done to keep drivers working that use 
statically declared fb_info.

Although I agree, that it would be cleaner the other way around.


Regards,

Florian Tobias Schandinat