kernel.git/drivers/video/fbdev/aty, branch linux-4.19.y

fbdev: atyfb: only use ioremap_uc() on i386 and ia64

2023-11-08T10:22:20Z

[ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

video: fbdev: radeon: Fix memleak in radeonfb_pci_register

2020-10-29T08:55:09Z

[ Upstream commit fe6c6a4af2be8c15bac77f7ea160f947c04840d1 ] When radeon_kick_out_firmware_fb() fails, info should be freed just like the subsequent error paths. Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac") Signed-off-by: Dinghao Liu Reviewed-by: Mathieu Malaterre Cc: Kangjie Lu Cc: Benjamin Herrenschmidt Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200825062900.11210-1-dinghao.liu@zju.edu.cn Signed-off-by: Sasha Levin

mach64: fix image corruption due to reading accelerator registers

2018-11-21T08:19:17Z

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ä Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

mach64: fix display corruption on big endian machines

2018-11-21T08:19:17Z

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ä Cc: stable@vger.kernel.org Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Greg Kroah-Hartman

mach64: detect the dot clock divider correctly on sparc

2018-10-08T05:41:05Z

On Sun Ultra 5, it happens that the dot clock is not set up properly for some videomodes. For example, if we set the videomode "r1024x768x60" in the firmware, Linux would incorrectly set a videomode with refresh rate 180Hz when booting (suprisingly, my LCD monitor can display it, although display quality is very low). The reason is this: Older mach64 cards set the divider in the register VCLK_POST_DIV. The register has four 2-bit fields (the field that is actually used is specified in the lowest two bits of the register CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards, there's another bit added - the top four bits of PLL_EXT_CNTL extend the divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12". The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets them, so it can work regardless if the card supports them. However, the sparc64 firmware may set these extended dividers during boot - and the mach64 driver detects incorrect dot clock in this case. This patch makes the driver read the additional divider bit from PLL_EXT_CNTL and calculate the initial refresh rate properly. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Acked-by: David S. Miller Reviewed-by: Ville Syrjälä Signed-off-by: David S. Miller

video: fbdev: aty: radeon_pm: Replace mdelay with msleep in radeonfb_pci_suspend

2018-04-24T16:11:21Z

radeonfb_pci_suspend() is never called in atomic context. radeonfb_pci_suspend() is only set as ".suspend" in struct pci_driver. This function is not called in atomic context. Despite never getting called from atomic context, radeonfb_pci_suspend() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() and usleep_range() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai Cc: Benjamin Herrenschmidt Signed-off-by: Bartlomiej Zolnierkiewicz

video: fbdev: aty: aty128fb: Replace mdelay with msleep in aty128_set_suspend

2018-04-24T16:11:21Z

aty128_set_suspend() is never called in atomic context. The call chains ending up at aty128_set_suspend() are: [1] aty128_set_suspend() <- aty128_pci_suspend() [2] aty128_set_suspend() <- aty128_do_resume() <- aty128_pci_resume() [3] aty128_set_suspend() <- aty128_do_resume() <- aty128_early_resume() aty128_pci_suspend() is set as ".suspend" in struct pci_driver. aty128_pci_resume() is set as ".resume" in struct pci_driver. aty128_early_resume() is never called. These functions are not called in atomic context. Despite never getting called from atomic context, aty128_set_suspend() calls mdelay() to busily wait. This is not necessary and can be replaced with msleep() to avoid busy waiting. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai Cc: Paul Mackerras Signed-off-by: Bartlomiej Zolnierkiewicz

video: fbdev: aty128fb: use true and false for boolean values

2018-03-28T14:34:27Z

Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva Cc: Paul Mackerras Signed-off-by: Bartlomiej Zolnierkiewicz

fbdev: aty: fix missing indentation in if statement

2018-03-28T14:34:27Z

There is a missing indentation following an if statement, fix this. Detected by Coccinelle: drivers/video/fbdev/aty/mach64_ct.c:183:2-15: code aligned with following code on line 184 Signed-off-by: Colin Ian King Cc: Philippe Ombredanne Cc: Thomas Gleixner Signed-off-by: Bartlomiej Zolnierkiewicz

fbdev: Fix loading of module radeonfb on PowerMac

2018-03-12T16:06:54Z

When the linux kernel is build with (typical kernel ship with Debian installer): CONFIG_FB=y CONFIG_FB_OF=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_FB_RADEON=m The offb driver takes precedence over module radeonfb. It is then impossible to load the module, error reported is: [ 96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007) [ 96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0x98000000-0x9fffffff pref] [ 96.551531] radeonfb (0000:00:10.0): cannot request region 0. [ 96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16 This patch reproduce the behavior of the module radeon, so as to make it possible to load radeonfb when offb is first loaded, see commit a56f7428d753 ("drm/radeon: Add early unregister of firmware fb's"). Signed-off-by: Mathieu Malaterre Link: https://bugs.debian.org/826629#57 Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741 Suggested-by: Lennart Sorensen Cc: Benjamin Herrenschmidt Cc: Tomi Valkeinen Signed-off-by: Bartlomiej Zolnierkiewicz