Thread (9 messages) 9 messages, 2 authors, 2013-01-09

Re: [PATCH] fb: Rework locking to fix lock ordering on takeover

From: Alan Cox <hidden>
Date: 2013-01-04 13:19:44
Also in: lkml

On Fri, 04 Jan 2013 13:50:37 +0100
Alexander Holler [off-list ref] wrote:
Am 28.12.2012 13:40, schrieb Borislav Petkov:
quoted
On Fri, Dec 28, 2012 at 07:50:27PM +0800, Shawn Guo wrote:
quoted
+1

http://thread.gmane.org/gmane.linux.kernel/1413953/focus15070
Cool, works fine here too. Is Linus on CC? (/me checks.. ) Yes he is,
good.

Linus, Alan's patch works at least in 2 cases, you might consider
picking it up directly since the fb maintainer is absent, reportedly.

Btw. I think all the usb-fb's (udlfb, smscufx and udl) are broken, at 
least on ARM(v5). When I have linked in udlfb the following happens on 
boot (with an attached USB-LCD and with or without the "Rework locking 
patch):
They are broken if used as the system console (has been known for years).
Perhaps your x86 test has the system console still on another device ?

For the udl layer it shouldn't matter as Dave Airlie wrote a DRM driver
for udl which obsoletes the old fb layer one and works much better
(although the error handling is still totally broken and leaks like a
sieve if it fails)

Fixing the console isn't that difficult - you just need to make your
device queue the console I/O to a worker thread of some kind. We don't
want to do that by default because we want to get the messages out
reliably and immediately on saner hardware. Given there are several
such cases a general helper and a console "I am crap" flag might be better
than hacking each driver.

Alan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help