linux-stable.git/drivers/video/fbdev, branch linux-3.16.y

x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping

2020-06-11T18:05:55+00:00

commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream.

x86_mask is a confusing name which is hard to associate with the
processor's stepping.

Additionally, correct an indent issue in lib/cpu.c.

Signed-off-by: Jia Zhang 
[ Updated it to more recent kernels. ]
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: bp@alien8.de
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16:
 - Drop changes in arch/x86/lib/cpu.c
 - Adjust filenames, context]
Signed-off-by: Ben Hutchings

pxa168fb: Fix the function used to release some memory in an error handling path

2020-05-22T20:19:22+00:00

commit 3c911fe799d1c338d94b78e7182ad452c37af897 upstream.

In the probe function, some resources are allocated using 'dma_alloc_wc()',
they should be released with 'dma_free_wc()', not 'dma_free_coherent()'.

We already use 'dma_free_wc()' in the remove function, but not in the
error handling path of the probe function.

Also, remove a useless 'PAGE_ALIGN()'. 'info->fix.smem_len' is already
PAGE_ALIGNed.

Fixes: 638772c7553f ("fb: add support of LCD display controller on pxa168/910 (base layer)")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Lubomir Rintel 
CC: YueHaibing 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190831100024.3248-1-christophe.jaillet@wanadoo.fr
[bwh: Backported to 3.16: Use dma_free_writecombine().]
Signed-off-by: Ben Hutchings

video: fbdev: Set pixclock = 0 in goldfishfb

2020-01-11T02:04:56+00:00

commit ace6033ec5c356615eaa3582fb1946e9eaff6662 upstream.

User space Android code identifies pixclock == 0 as a sign for emulation
and will set the frame rate to 60 fps when reading this value, which is
the desired outcome.

Signed-off-by: Christoffer Dall 
Signed-off-by: Peter Maydell 
Signed-off-by: Roman Kiryanov 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Ben Hutchings

drm/omap: fix max fclk divider for omap36xx

2019-12-19T15:57:57+00:00

commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream.

The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.

There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.

Signed-off-by: Tomi Valkeinen 
Cc: Adam Ford 
Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com
Tested-by: Adam Ford 
Reviewed-by: Jyri Sarha 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

video: ssd1307fb: Start page range at page_offset

2019-12-10T18:01:09+00:00

commit dd9782834dd9dde3624ff1acea8859f3d3e792d4 upstream.

The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range display
expected.

Fixes: 301bc0675b67 ("video: ssd1307fb: Make use of horizontal addressing mode")
Signed-off-by: Marko Kohtala 
Cc: Mark Rutland 
Cc: Rob Herring 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Michal Vokáč 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Link: https://patchwork.freedesktop.org/patch/msgid/20190618074111.9309-4-marko.kohtala@okoko.fi
Signed-off-by: Ben Hutchings

fbdev: ssd1307fb: return proper error code if write command fails

2019-12-10T18:01:09+00:00

commit 5b72ae9a901cbfbe632570f278486142b037fe51 upstream.

this patch fixes ssd1307fb_ssd1306_init() function to return
proper error codes in case of failures.

Signed-off-by: Lad, Prabhakar 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Ben Hutchings

omap2fb: Fix stack memory disclosure

2019-05-02T20:41:19+00:00

commit a01421e4484327fe44f8e126793ed5a48a221e24 upstream.

Using [1] for static analysis I found that the OMAPFB_QUERY_PLANE,
OMAPFB_GET_COLOR_KEY, OMAPFB_GET_DISPLAY_INFO, and OMAPFB_GET_VRAM_INFO
cases could all leak uninitialized stack memory--either due to
uninitialized padding or 'reserved' fields.

Fix them by clearing the shared union used to store copied out data.

[1] https://github.com/vlad902/kernel-uninitialized-memory-checker

Signed-off-by: Vlad Tsyrklevich 
Reviewed-by: Kees Cook 
Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
Cc: security@kernel.org
[b.zolnierkie: prefix patch subject with "omap2fb: "]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

fbdev: fbmem: behave better with small rotated displays and many CPUs

2019-04-04T15:14:02+00:00

commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 upstream.

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

mach64: fix image corruption due to reading accelerator registers

2019-02-11T17:53:28+00:00

commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.

Reading the registers without waiting for engine idle returns
unpredictable values. These unpredictable values result in display
corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
never ever clear the bit, resulting in display corruption.

We don't want to wait for idle because it would degrade performance, so
this patch modifies the driver so that it never reads accelerator
registers.

HOST_CNTL doesn't have to be read, we can just write it with
HOST_BYTE_ALIGN because no other part of the driver cares if
HOST_BYTE_ALIGN is set.

DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
with the default value and in atyfb_imageblit with the value set according
to the source image data.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings

mach64: fix display corruption on big endian machines

2019-02-11T17:53:28+00:00

commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.

The code for manual bit triple is not endian-clean. It builds the variable
"hostdword" using byte accesses, therefore we must read the variable with
"le32_to_cpu".

The patch also enables (hardware or software) bit triple only if the image
is monochrome (image->depth). If we want to blit full-color image, we
shouldn't use the triple code.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Ben Hutchings