user/sven/linux.git/drivers/video, branch v3.2.79

video: fbdev: fsl: Fix kernel crash when diu_ops is not implemented

2016-01-22T21:40:03Z

commit acfc1cc13fe5bc6d7a10afa624f1e560850ddad3 upstream. If diu_ops is not implemented on platform, kernel will access a NULL pointer. We need to check this pointer in DIU initialization. Signed-off-by: Wang Dongsheng Acked-by: Timur Tabi Signed-off-by: Tomi Valkeinen [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings

video/fbdev: fix defio's fsync

2015-02-20T00:49:33Z

commit 30ea9c5218651bc11cbdba7820be78f04e2d83bc upstream. fb_deferred_io_fsync() returns the value of schedule_delayed_work() as an error code, but schedule_delayed_work() does not return an error. It returns true/false depending on whether the work was already queued. Fix this by ignoring the return value of schedule_delayed_work(). Signed-off-by: Tomi Valkeinen [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings

video/logo: prevent use of logos after they have been freed

2015-02-20T00:49:33Z

commit 92b004d1aa9f367c372511ca0330f58216b25703 upstream. If the probe of an fb driver has been deferred due to missing dependencies, and the probe is later ran when a module is loaded, the fbdev framework will try to find a logo to use. However, the logos are __initdata, and have already been freed. This causes sometimes page faults, if the logo memory is not mapped, sometimes other random crashes as the logo data is invalid, and sometimes nothing, if the fbdev decides to reject the logo (e.g. the random value depicting the logo's height is too big). This patch adds a late_initcall function to mark the logos as freed. In reality the logos are freed later, and fbdev probe may be ran between this late_initcall and the freeing of the logos. In that case we will miss drawing the logo, even if it would be possible. Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings

framebuffer: fix screen corruption when copying

2014-12-14T16:23:46Z

commit 5b789da8a7fc357661fc61faaf853e9161cc9700 upstream. The function bitcpy_rev has a bug that may result in screen corruption. The bug happens under these conditions: * the end of the destination area of a copy operation is aligned on a long word boundary * the end of the source area is not aligned on a long word boundary * we are copying more than one long word In this case, the variable shift is non-zero and the variable first is zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads the last long word of the destination and writes it back unchanged (because first is zero). Correctly, we should write the variable d0 to the last word of the destination in this case. This patch fixes the bug by introducing and extra test if first is zero. The patch also removes the references to fb_memmove in the code that is commented out because fb_memmove was removed from framebuffer subsystem. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

framebuffer: fix border color

2014-12-14T16:23:45Z

commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream. The framebuffer code uses the current background color to fill the border when switching consoles, however, this results in inconsistent behavior. For example: - start Midnigh Commander - the border is black - switch to another console and switch back - the border is cyan - type something into the command line in mc - the border is cyan - switch to another console and switch back - the border is black - press F9 to go to menu - the border is black - switch to another console and switch back - the border is dark blue When switching to a console with Midnight Commander, the border is random color that was left selected by the slang subsystem. This patch fixes this inconsistency by always using black as the background color when switching consoles. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings

matroxfb: perform a dummy read of M_STATUS

2014-07-11T12:33:36Z

commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream. I had occasional screen corruption with the matrox framebuffer driver and I found out that the reason for the corruption is that the hardware blitter accesses the videoram while it is being written to. The matrox driver has a macro WaitTillIdle() that should wait until the blitter is idle, but it sometimes doesn't work. I added a dummy read mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read will flush the write buffer in the PCI chipset, and the next read of M_STATUS will return the hardware status. Since applying this patch, I had no screen corruption at all. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings

tgafb: fix mode setting with fbset

2014-06-09T12:28:54Z

commit 624966589041deb32a2626ee2e176e8274581101 upstream. Mode setting in the TGA driver is broken for these reasons: - info->fix.line_length is set just once in tgafb_init_fix function. If we change videomode, info->fix.line_length is not recalculated - so the video mode is changed but the screen is corrupted because of wrong info->fix.line_length. - info->fix.smem_len is set in tgafb_init_fix to the size of the default video mode (640x480). If we set a higher resolution, info->fix.smem_len is smaller than the current screen size, preventing the userspace program from mapping the framebuffer. This patch fixes it: - info->fix.line_length initialization is moved to tgafb_set_par so that it is recalculated with each mode change. - info->fix.smem_len is set to a fixed value representing the real amount of video ram (the values are taken from xfree86 driver). - add a check to tgafb_check_var to prevent us from setting a videomode that doesn't fit into videoram. - in tgafb_register, tgafb_init_fix is moved upwards, to be called before fb_find_mode (because fb_find_mode already needs the videoram size set in tgafb_init_fix). Signed-off-by: Mikulas Patocka Cc: stable@vga.kernel.org Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings

tgafb: fix data copying

2014-04-30T15:23:20Z

commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream. The functions for data copying copyarea_foreward_8bpp and copyarea_backward_8bpp are buggy, they produce screen corruption. This patch fixes the functions and moves the logic to one function "copyarea_8bpp". For simplicity, the function only handles copying that is aligned on 8 pixes. If we copy an unaligned area, generic function cfb_copyarea is used. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings

mach64: fix cursor when character width is not a multiple of 8 pixels

2014-04-30T15:23:19Z

commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream. This patch fixes the hardware cursor on mach64 when font width is not a multiple of 8 pixels. If you load such a font, the cursor is expanded to the next 8-byte boundary and a part of the next character after the cursor is not visible. For example, when you load a font with 12-pixel width, the cursor width is 16 pixels and when the cursor is displayed, 4 pixels of the next character are not visible. The reason is this: atyfb_cursor is called with proper parameters to load an image that is 12-pixel wide. However, the number is aligned on the next 8-pixel boundary on the line "unsigned int width = (cursor->image.width + 7) >> 3;" and the whole function acts as it is was loading a 16-pixel image. This patch fixes it so that the value written to the framebuffer is padded with 0xaaaa (the transparent pattern) when the image size it not a multiple of 8 pixels. The transparent pattern causes that the cursor will not interfere with the next character. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings

mach64: use unaligned access

2014-04-30T15:23:19Z

commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream. This patch fixes mach64 to use unaligned access to the font bitmap. This fixes unaligned access warning on sparc64 when 14x8 font is loaded. On x86(64), unaligned access is handled in hardware, so both functions le32_to_cpup and get_unaligned_le32 perform the same operation. On RISC machines, unaligned access is not handled in hardware, so we better use get_unaligned_le32 to avoid the unaligned trap and warning. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Ben Hutchings