linux.git/drivers/video, branch v2.6.31

xenfb: connect to backend before registering fb

2009-08-27T19:31:18+00:00

As soon as the framebuffer is registered, our methods may be called by the
kernel. This leads to a crash as xenfb_refresh() gets called before we have
the irq.

Connect to the backend before registering our framebuffer with the kernel.

[ Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14059 ]

Signed-off-by: Michal Schmidt 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Linus Torvalds

sh: skip disabled LCDC channels

2009-08-15T03:58:42+00:00

This patch updates the SuperH Mobile LCDC driver to skip
over disabled channels. Without this patch suspend-to-ram
operation will crash if deferred io is enabled.

Signed-off-by: Magnus Damm 
Signed-off-by: Paul Mundt

i.MX31: fix framebuffer locking regressions

2009-08-07T17:39:56+00:00

Recent framebuffer locking patches first made affected systems unbootable,
then the dead-lock has been fixed but as of 2.6.31-rc4 the framebuffer on
mx3 machines doesn't work. Fix this.

Signed-off-by: Guennadi Liakhovetski 
Cc: Sascha Hauer 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbcon: don't use vc_resize() on initialization

2009-08-07T17:39:56+00:00

Catalin and kmemleak spotted a leak of a VC screen buffer in
vc_allocate() due to the following chain of events:

	vc_allocate()
	  visual_init(init=1)
	    vc->vc_sw->con_init(init=1)
              fbcon_init()
	        vc_resize()
	          vc->screen_buf = kmalloc()
	  vc->screen_buf = kmalloc()

The common way for the VC drivers is to set the screen dimension
parameters manually in the init case and only call vc_resize() for
!init - which allocates a screen buffer according to the new
dimensions.

fbcon instead would do vc_resize() unconditionally and afterwards set
the dimensions manually (again) for !init - i.e. completely upside
down.  The vc_resize() allocated buffer would then get lost by
vc_allocate() allocating a fresh one.

Use vc_resize() only for actual resizing to close the leak.

Set the dimensions manually only in initialization mode to remove the
redundant setting in resize mode.

The kmemleak trace from Catalin:

unreferenced object 0xde158000 (size 12288):
  comm "Xorg", pid 1439, jiffies 4294961016
  hex dump (first 32 bytes):
    20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
    20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
  backtrace:
    [] __save_stack_trace+0x17/0x1c
    [] create_object+0xcd/0x188
    [] kmemleak_alloc+0x1b/0x3c
    [] __kmalloc+0xdb/0xe8
    [] vc_do_resize+0x73/0x1e0
    [] vc_resize+0x15/0x18
    [] fbcon_init+0x1f9/0x2b8
    [] visual_init+0x9f/0xdc
    [] vc_allocate+0x7f/0xfc
    [] con_open+0x17/0x80
    [] tty_open+0x1f7/0x2e4
    [] chrdev_open+0x101/0x118
    [] __dentry_open+0x105/0x1cc
    [] nameidata_to_filp+0x2d/0x38
    [] do_filp_open+0x2c1/0x54c
    [] do_sys_open+0x3b/0xb4

Reported-by: Catalin Marinas 
Signed-off-by: Johannes Weiner 
Tested-by: Catalin Marinas 
Cc: Pekka Enberg 
Cc: Krzysztof Helt 
Tested-by: Dave Young 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

viafb: fix rmmod bug

2009-08-07T17:39:56+00:00

This fixes a bug caused by changing pointers (viafb_mode, viafb_mode1)
assigned by module_param.  It reduces driver complexity by not needlessly
changing these vars as they are only read once and removing now
superfluous code.

On unpatched kernels loading viafb with viafb_mode or viafb_mode1 option
used and afterwards unloading it results in:

kernel BUG at mm/slub.c:2926!
invalid opcode: 0000 [#1] PREEMPT
last sysfs file: /sys/devices/virtual/block/loop0/removable
Modules linked in: snd_hda_codec_realtek snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm rtl8187 snd_timer eeprom_93cx6 mmc_block snd soundcore
via_sdmmc fb snd_page_alloc i2c_algo_bit i2c_viapro ehci_hcd uhci_hcd
cfbcopyarea mmc_core cfbimgblt cfbfillrect video output [last unloaded:
viafb]

  Pid: 3355, comm: rmmod Not tainted (2.6.31-rc1 #0)
  EIP: 0060:[] EFLAGS: 00010246 CPU: 0
  EIP is at kfree+0x80/0xda
  EAX: c17c2da0 EBX: dc7edbdc ECX: 0000010f EDX: 00000000
  ESI: c102c700 EDI: dc7ed8fa EBP: d703ff2c ESP: d703ff20
   DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
  Process rmmod (pid: 3355, ti=d703e000 task=db1412c0 task.ti=d703e000)
  Stack:
   dc7edbdc 00000014 00000016 d703ff40 c102c700 dc7f45d4 dc7f45d4 00000880
   d703ff4c c103e571 00000000 d703ffac c103e751 66616976 da140062 db89ba80
   00000328 d702edf8 db89ba80 d703ff9c c105d0f0 00000200 da14f898 00000014
  Call Trace:
   [] ? destroy_params+0x1e/0x2b
   [] ? free_module+0xa2/0xd7
   [] ? sys_delete_module+0x1ab/0x1da
   [] ? do_munmap+0x20a/0x225
   [] ? sysenter_do_call+0x12/0x26
  Code: 10 76 7a 8d 87 00 00 00 40 c1 e8 0c c1 e0 05 03 05 1c 87 41 c1 66 83 38 00 79 03 8b 40 0c 8b 10 84 d2 78 12 66 f7 c2 00 c0 75 04 <0f> 0b eb fe e8 6f 5a fe ff eb 47 8b 55 04 8b 58 0c 9c 5e fa 3b
  EIP: [] kfree+0x80/0xda SS:ESP 0068:d703ff20

This is caused by the current code changing the pointers assigned by
module_param.  During unload it tries to free the memory the pointers
point at which is now part of an internal structure.

The patch simply avoids changing the pointers.  This is okay as they are
read only once during the initialization process.

Signed-off-by: Florian Tobias Schandinat 
Cc: Scott Fang 
Cc: Joseph Chan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbcon: fix rotate upside down crash

2009-08-07T17:39:55+00:00

Fix the rotate_ud() function not to crash in case of a font which has not
a width of multiple by 8: The inner loop of the font pixel copy should not
access a bit outside the font memory area.  Subtract the shift offset from
the font width will prevent this.

Signed-off-by: Stefani Seibold 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

parisc: sticore.c - check return values

2009-08-02T13:26:51+00:00

Signed-off-by: Helge Deller

drivers/video/backlight/jornada720_bl.c: fix build

2009-07-30T02:10:35+00:00

Signed-off-by: Kristoffer Ericson 
Cc: Richard Purdie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

s3c-fb: fix off-by-one bug in loop indexes

2009-07-30T02:10:34+00:00

Fixed off-by-one bug in loop indexes - some elements beyond windows' array
were accessed, which might result in memory access violations when
removing/suspending the device.

Signed-off-by: Pawel Osciak 
Reviewed-by: Kyungmin Park 
Signed-off-by: Marek Szyprowski 
Cc: Krzysztof Helt 
Cc: Ben Dooks 
Cc: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbmon: work around compiler bug in gcc-2.4.2

2009-07-22T15:49:22+00:00

There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.

The compiler will incorrectly decide that a trivial loop like this:

	unsigned char i, ...

	for (i = 0; i < 128; i++) {
		..

is endless, and will compile it to a single instruction that just
branches to itself.

This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.

Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.

Reported-and-tested-by: Krzysztof Oledzki 
Found-by: Troy Moure 
Gcc-bug-acked-by: Ian Lance Taylor 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds