linux-toradex.git/drivers/video, branch v3.2.48

vm: convert fb_mmap to vm_iomap_memory() helper

2013-05-13T14:02:34+00:00

commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream.

This is my example conversion of a few existing mmap users.  The
fb_mmap() case is a good example because it is a bit more complicated
than some: fb_mmap() mmaps one of two different memory areas depending
on the page offset of the mmap (but happily there is never any mixing of
the two, so the helper function still works).

Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2: fold in the relevant part of commit 314e51b9851b
 'mm: kill vma flag VM_RESERVED and mm->reserved_vm counter']
Signed-off-by: Ben Hutchings

fbcon: when font is freed, clear also vc_font.data

2013-05-13T14:02:24+00:00

commit e6637d5427d2af9f3f33b95447bfc5347e5ccd85 upstream.

commit ae1287865f5361fa138d4d3b1b6277908b54eac9
Author: Dave Airlie 
Date:   Thu Jan 24 16:12:41 2013 +1000

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

uses a pointer in vc->vc_font.data to load font into the new driver.
However if the font is actually freed, we need to clear the data
so that we don't reload font from dangling pointer.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Signed-off-by: Mika Kuoppala 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

fbcon: fix locking harder

2013-04-25T19:25:49+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: Ben Hutchings

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

2013-03-06T03:24:10+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: Ben Hutchings

fb: Yet another band-aid for fixing lockdep mess

2013-03-06T03:23:52+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: Ben Hutchings

fb: rework locking to fix lock ordering on takeover

2013-03-06T03:23:52+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: Ben Hutchings

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

2013-03-06T03:23:51+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

Cc: Kay Sievers 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

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

2013-03-06T03:23:50+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: Ben Hutchings

video: mxsfb: fix crash when unblanking the display

2013-01-16T01:13:18+00:00

commit 6c1ecba8d84841277d68140ef485335d5be28485 upstream.

The VDCTRL4 register does not provide the MXS SET/CLR/TOGGLE feature.
The write in mxsfb_disable_controller() sets the data_cnt for the LCD
DMA to 0 which obviously means the max. count for the LCD DMA and
leads to overwriting arbitrary memory when the display is unblanked.

Signed-off-by: Lothar Waßmann 
Acked-by: Juergen Beisert 
Tested-by: Lauri Hintsala 
Signed-off-by: Shawn Guo 
Signed-off-by: Ben Hutchings

video/udlfb: fix line counting in fb_write

2012-10-30T23:26:40+00:00

commit b8c4321f3d194469007f5f5f2b34ec278c264a04 upstream.

Line 0 and 1 were both written to line 0 (on the display) and all subsequent
lines had an offset of -1. The result was that the last line on the display
was never overwritten by writes to /dev/fbN.

Signed-off-by: Alexander Holler 
Acked-by: Bernie Thompson 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Ben Hutchings