kernel/linux.git/drivers/video/fbdev/core/fbmem.c, branch linux-4.20.y

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

2019-02-12T19:02:26+00:00

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ] 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: Sasha Levin

fbdev: Add FBINFO_HIDE_SMEM_START flag

2018-09-11T12:11:54+00:00

DRM drivers really, really, really don't want random userspace to share buffer behind it's back, bypassing the dma-buf buffer sharing machanism. For that reason we've ruthlessly rejected any IOCTL exposing the physical address of any graphics buffer. Unfortunately fbdev comes with that built-in. We could just set smem_start to 0, but that means we'd have to hand-roll our own fb_mmap implementation. For good reasons many drivers do that, but smem_start/length is still super convenient. Hence instead just stop the leak in the ioctl, to keep fb mmap working as-is. A second patch will set this flag for all drm drivers. Acked-by: Bartlomiej Zolnierkiewicz Cc: Bartlomiej Zolnierkiewicz Cc: Kees Cook Cc: Daniel Vetter Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180822085405.10787-3-daniel.vetter@ffwll.ch

fbdev: fix kerneldoc

2018-09-07T19:49:13+00:00

As noticed by kbuild test robot , remove_conflicting_pci_framebuffers()'s second argument is called res_id not resource_id. Fix this. Signed-off-by: Michał Mirosław Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/38ca9044455a33e398b45e0281643cc24da3c2fc.1536342224.git.mirq-linux@rere.qmqm.pl

fbdev: add remove_conflicting_pci_framebuffers()

2018-09-03T16:15:40+00:00

Almost all PCI drivers using remove_conflicting_framebuffers() wrap it with the same code. v2: add kerneldoc for DRM helper v3: propagate remove_conflicting_framebuffers() return value + move kerneldoc to where function is implemented Signed-off-by: Michał Mirosław Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/7db1c278276de420eb45a1b71d06b5eb6bbd49ef.1535810304.git.mirq-linux@rere.qmqm.pl

fbdev: add kerneldoc do remove_conflicting_framebuffers()

2018-09-03T16:15:26+00:00

Document remove_conflicting_framebuffers() behaviour. Signed-off-by: Michał Mirosław Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/283fef19815b991700b56119d8d5874a2a8da44e.1535810304.git.mirq-linux@rere.qmqm.pl

fbdev: allow apertures == NULL in remove_conflicting_framebuffers()

2018-09-03T16:14:55+00:00

Interpret (otherwise-invalid) NULL apertures argument to mean all-memory range. This will allow to remove several duplicates of this code from drivers in following patches. Signed-off-by: Michał Mirosław Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/b5fed539fe569035139c8594c23effd8c39f12ca.1535810304.git.mirq-linux@rere.qmqm.pl

fbdev: show fbdev number for debugging

2018-09-03T16:14:42+00:00

Signed-off-by: Michał Mirosław Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Daniel Vetter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/ef584ecd8642e8b1a04f28d6d9c1864b5aa507bb.1535810304.git.mirq-linux@rere.qmqm.pl

fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set

2018-07-31T11:06:58+00:00

If the console is unlocked during registration, the console subsystem generates significant amounts of warnings, which obfuscate actual debugging messages. Setting ignore_console_lock_warning while debugging console registration avoid the noise. v3: - manipulate ignore_console_lock_warning with atomic_{inc,dec} v2: - restore ignore_console_lock_warning if lock_fb_info() fails Signed-off-by: Thomas Zimmermann Acked-by: Hans de Goede Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Cc: Steven Rostedt (VMware) Cc: Andrew Morton Signed-off-by: Bartlomiej Zolnierkiewicz

fb: fix lost console when the user unplugs a USB adapter

2018-07-25T13:41:54+00:00

I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board. The reason is this: When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it. This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it. Signed-off-by: Mikulas Patocka Cc: Dave Airlie Cc: Bernie Thompson Cc: Ladislav Michl Cc: stable@vger.kernel.org [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()] Signed-off-by: Bartlomiej Zolnierkiewicz

fbdev: fbmem: mark expected switch fall-through

2018-07-24T17:11:27+00:00

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva Signed-off-by: Bartlomiej Zolnierkiewicz