linux-stable.git/drivers/video, branch v3.8.2

fbcon: fix locking harder

2013-02-28T13:38:39+00:00

commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream.

Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.

In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,

this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.

This should fix the efifb regression seen by Maarten.

Tested-by: Maarten Lankhorst 
Tested-by: Lu Hua 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

fb: Yet another band-aid for fixing lockdep mess

2013-02-28T13:38:39+00:00

commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream.

I've still got lockdep warnings even after Alan's patch, and it seems that
yet more band aids are required to paper over similar paths for
unbind_con_driver() and unregister_con_driver().  After this hack, lockdep
warnings are finally gone.

Signed-off-by: Takashi Iwai 
Cc: Alan Cox 
Cc: Florian Tobias Schandinat 
Cc: Jiri Kosina 
Tested-by: Sedat Dilek 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

fb: rework locking to fix lock ordering on takeover

2013-02-28T13:38:39+00:00

commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
[akpm@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: Alan Cox 
Cc: Florian Tobias Schandinat 
Cc: Stephen Rothwell 
Cc: Jiri Kosina 
Tested-by: Sedat Dilek 
Reviewed-by: Daniel Vetter 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

fbcon: don't lose the console font across generic->chip driver switch

2013-02-28T13:38:39+00:00

commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream.

If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.

The thing is the generic code is doing the right thing, it frees the font
because otherwise it would leak memory. However we can assume that if you
are removing the generic firmware driver (vesa/efi/offb), that a new driver
*should* be loading soon after, so we effectively leak the font.

However the old code left a dangling pointer in vc->vc_font.data and we
can now reuse that dangling pointer to load the font into the new
driver, now that we aren't freeing it.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340

Signed-off-by: Dave Airlie 
Cc: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

drivers/video: fsl-diu-fb: fix bugs in interrupt handling

2013-02-28T13:38:39+00:00

commit b2639b5f1d01f218dc95537a1c352b3a551c4dd5 upstream.

Since commit f74de500 "drivers/video: fsl-diu-fb: streamline
enabling of interrupts" the interrupt handling in the driver
is broken. Enabling diu interrupt causes an interrupt storm and
results in system lockup.

The cookie for the interrupt handler function passed to request_irq()
is wrong (it must be a pointer to the diu struct, and not the address
of the pointer to the diu struct). As a result the interrupt handler
can not read diu registers and acknowledge the interrupt. Fix cookie
arguments for request_irq() and free_irq().

Registering the diu interrupt handler in probe() must happen before
install_fb() calls since this function registers framebuffer devices
and if fbcon tries to take over framebuffer after registering a frame
buffer device, it will call fb_open of the diu driver and enable the
interrupts. At this time the diu interrupt handler must be registered
already.

Disabling the interrupts in fsl_diu_release() must happen only if all
other AOIs are closed. Otherwise closing an overlay plane will disable
the interrupts even if the primary frame buffer plane is opened. Add
an appropriate check in the release function.

Signed-off-by: Anatolij Gustschin 
Cc: Timur Tabi 
Signed-off-by: Greg Kroah-Hartman

drivers/video: fsl-diu-fb: fix pixel formats for 24 and 16 bpp

2013-02-28T13:38:39+00:00

commit 5d3cc311a76073f6e0a27c0752f7e41f69e95ea7 upstream.

Framebuffer colors for 24 and 16 bpp are currently wrong. The order
of the color component arguments in the MAKE_PF() is not natural
and causes some confusion. The generated pixel format values for 24
and 16 bpp depths do not much the values in the comments.

Fix the macro arguments to be in the natural RGB order and adjust
the arguments for all depths to generate correct pixel format values
(equal to the values mentioned in the comments).

Signed-off-by: Anatolij Gustschin 
Cc: Timur Tabi 
Acked-by: Timur Tabi 
Signed-off-by: Greg Kroah-Hartman

vgacon/vt: clear buffer attributes when we load a 512 character font (v2)

2013-02-28T13:38:34+00:00

commit 2a2483072393b27f4336ab068a1f48ca19ff1c1e upstream.

When we switch from 256->512 byte font rendering mode, it means the
current contents of the screen is being reinterpreted. The bit that holds
the high bit of the 9-bit font, may have been previously set, and thus
the new font misrenders.

The problem case we see is grub2 writes spaces with the bit set, so it
ends up with data like 0x820, which gets reinterpreted into 0x120 char
which the font translates into G with a circumflex. This flashes up on
screen at boot and is quite ugly.

A current side effect of this patch though is that any rendering on the
screen changes color to a slightly darker color, but at least the screen
no longer corrupts.

v2: as suggested by hpa, always clear the attribute space, whether we
are are going to or from 512 chars.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drivers/video/backlight/adp88?0_bl.c: fix resume

2013-02-28T13:38:31+00:00

commit 5eb02c01bd1f3ef195989ab05e835e2b0711b5a9 upstream.

Clearing the NSTBY bit in the control register also automatically clears
the BLEN bit.  So we need to make sure to set it again during resume,
otherwise the backlight will stay off.

Signed-off-by: Lars-Peter Clausen 
Acked-by: Michael Hennerich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list

2013-02-14T11:06:46+00:00

commit 195e672a76056478cc79f5c48343164c9237852e
   OMAPDSS: DPI: Remove cpu_is_xxxx checks

made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().

So on an omap3630, code that was previously enabled by
  if (cpu_is_omap34xx())
is now disabled as
  dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.

So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.

Cc: Chandrabhanu Mahapatra 
Cc: Tomi Valkeinen 
Signed-off-by: NeilBrown 
Signed-off-by: Tomi Valkeinen

Merge tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes

2013-01-24T04:35:02+00:00

From Shawn Guo:

This is yet another critical imxfb fixes held off by absence of FB
maintainer for some time.

* tag 'imx-fixes-3.8-3' of git://git.linaro.org/people/shawnguo/linux-2.6:
  video: imxfb: Do not crash on reboot