* Jan Blunck [off-list ref] [090922 07:59]:
On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren [off-list ref] wrote:
quoted
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.
Also, let's let Tomi Valkeinen deal with queueing up the omap fb code.
I can then merge Tomi's branck into linux-omap master branch as needed.
Regards,
Tony
From: Tony Lindgren [tony@atomide.com]
Sent: Tuesday, September 22, 2009 11:28 AM
* Jan Blunck [off-list ref] [090922 07:59]:
quoted
On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren [off-list ref] wrote:
quoted
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.
quoted
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.
Just people worried about booting properly.
Anyways, thanks for your time! I appreciate it.
Regards,
Sergio
Also, let's let Tomi Valkeinen deal with queueing up the omap fb code.
I can then merge Tomi's branck into linux-omap master branch as needed.
Regards,
Tony
On Tue, Sep 22, 2009 at 6:57 PM, Aguirre Rodriguez, Sergio Alberto
[off-list ref] wrote:
From: Tony Lindgren [tony@atomide.com]
Sent: Tuesday, September 22, 2009 11:28 AM
quoted
* Jan Blunck [off-list ref] [090922 07:59]:
quoted
On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren [off-list ref] wrote:
quoted
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.
quoted
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.
Cheers,
Jan
Jan Blunck schrieb:
On Tue, Sep 22, 2009 at 6:57 PM, Aguirre Rodriguez, Sergio Alberto
[off-list ref] wrote:
quoted
From: Tony Lindgren [tony@atomide.com]
Sent: Tuesday, September 22, 2009 11:28 AM
quoted
* Jan Blunck [off-list ref] [090922 07:59]:
quoted
On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren [off-list ref] wrote:
quoted
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.
quoted
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