- Jun 26, 2019
-
-
Bartlomiej Zolnierkiewicz authored
Merge tag 'topic/remove-fbcon-notifiers-2019-06-26' of git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next topic/remove-fbcon-notifiers: - Export fbcon_update_vcs to fix sh_mobile_lcdcfb.c compilation. - Rely on fbcon being builtin when vgaswitcheroo is builtin.
-
Daniel Vetter authored
Fixes linking fail when fbcon/fbdev is modular and vgaswitcheroo is enabled: x86_64-linux-gnu-ld: drivers/gpu/vga/vga_switcheroo.o: in function `vga_switchto_stage2': vga_switcheroo.c:(.text+0x997): undefined reference to `fbcon_remap_all' Unfortunately this means that in a default allmodconfig we will disable vgaswitcheroo. v2: I first tried to fix this with an EXPORT_SYMBOL, but vga_switcheroo is never a module, so this doesn't work. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 1cd51b5d ("vgaswitcheroo: call fbcon_remap_all directly") Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Lukas Wunner <lukas@wunner.de> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: linux-fbdev@vger.kernel.org Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190624092153.23375-1-daniel.vetter@ffwll.ch
-
- Jun 21, 2019
-
-
Bartlomiej Zolnierkiewicz authored
Equivalent of drm's commit aa61321d ("drm/omap: remove rfbi"). The RFBI driver has been marked as BROKEN and has not been included in the kernel build for many years. Just remove it (it can be trivially brought back from git repository if ever needed). Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
-
Colin Ian King authored
Currently variable ret is being initialized with -ENOENT however that value is never read and ret is being re-assigned later on. Hence this assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = devm_kzalloc(dev, size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Shobhit Kukreti authored
Fix warnings aboout comparing pointer to 0 reported by coccicheck: drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 Also while at it change return value to -ENOMEM on kzalloc() failure. Signed-off-by:
Shobhit Kukreti <shobhitkukreti@gmail.com> Reviewed-by:
Mathieu Malaterre <malat@debian.org> [b.zolnierkie: minor fixups] Signed-off-by:
-
Hans de Goede authored
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed. The efifb code does not support rotating the image before copying it to the screen. This commit adds a check for these new bits and if they are set leaves the fb contents as is instead of trying to use the un-rotated BGRT image. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Peter Jones <pjones@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
Virtual addresses return from dma(m)_alloc_coherent are opaque in what backs then, and drivers must not poke into them. Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Manuel Lauss <manuel.lauss@gmail.com> [b.zolnierkie: patch description fixup] Signed-off-by:
-
Arnd Bergmann authored
When the driver is built-in for PCI, we reference the exit function after discarding it: `pvr2fb_pci_exit' referenced in section `.ref.data' of drivers/video/fbdev/pvr2fb.o: defined in discarded section `.exit.text' of drivers/video/fbdev/pvr2fb.o Just remove the __exit annotation as the easiest workaround. Also apply the same workaround for pvr2fb_dc_exit(). Fixes: 0f5a5712 ("video: fbdev: pvr2fb: add COMPILE_TEST support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: YueHaibing <yuehaibing@huawei.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> [b.zolnierkie: remove __exit annotation also from pvr2fb_dc_exit()] Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Add COMPILE_TEST support to s3c-fb driver for better compile testing coverage. Acked-by:
Jingoo Han <jingoohan1@gmail.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
Use ->screen_buffer instead of ->screen_base to fix sparse warnings. [ Please see commit 17a7b0b4 ("fb.h: Provide alternate screen_base pointer") for details. ] Reported-by:
-
Bartlomiej Zolnierkiewicz authored
Add missing #ifndef MODULE around pvr2_get_param_val(). Fixes: 0f5a5712 ("video: fbdev: pvr2fb: add COMPILE_TEST support") Reported-by:
-
- Jun 19, 2019
-
-
Bartlomiej Zolnierkiewicz authored
Merge branch 'topic/remove-fbcon-notifiers' of git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next Trivial buildfix (export fbcon_update_vcs symbol) from Daniel Vetter.
-
Bartlomiej Zolnierkiewicz authored
Merge tag 'topic/remove-fbcon-notifiers-2019-06-14-1' of git://anongit.freedesktop.org/drm/drm-misc into fbdev-for-next topic/remove-fbcon-notifiers: - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking - assorted locking checks in vt/console code - assorted notifier and cleanups in fbdev and backlight code One trivial merge conflict fixed. Signed-off-by:
-
Daniel Vetter authored
I failed to spot this while compile-testing. Oops. Reported-by:
-
- Jun 13, 2019
-
-
Daniel Vetter authored
With all the work I've done on replacing fb notifier calls with direct calls into fbcon the backlight/lcd notifier is the only user left. It will only receive events now that it cares about, hence we can remove this check. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-34-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
this driver is pretty horrible from a design pov, and needs a complete overhaul. Concrete thing that annoys me is that it looks at registered_fb, which is an internal thing to fbmem.c and fbcon.c. And ofc it gets the lifetime rules all wrong (it should at least use get/put_fb_info). Looking at the history, there's been an attempt at dropping this from staging in 2016, but that had to be reverted. Since then not real effort except the usual stream of trivial patches, and fbdev has been formally closed for any new hw support. Time to try again and drop this? Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
Daniel Vetter authored
It's not pretty. Signed-off-by:
-
Daniel Vetter authored
These are actually fbcon ioctls which just happen to be exposed through /dev/fb*. They completely ignore which fb_info they're called on, and I think the userspace tool even hardcodes to /dev/fb0. Hence just forward the entire thing to fbcon.c wholesale. Note that this patch drops the fb_lock/unlock on the set side. Since the ioctl can operate on any fb (as passed in through con2fb.framebuffer) this is bogus. Also note that fbcon.c in general never calls fb_lock on anything, so this has been badly broken already. With this the last user of the fbcon notifier callback is gone, and we can garbage collect that too. v2: add missing uaccess.h include (alpha fails to compile otherwise), reported by kbuild. v3: Remember to also drop the #defines (Maarten) v4: Add the static inline to dummy functions. Signed-off-by:
-
Daniel Vetter authored
While at it, clean up the interface a bit and push the console locking into fbcon.c. v2: Remove now outdated comment (Lukas). v3: Forgot to add static inline to the dummy function. Acked-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Daniel Vetter authored
Create a new wrapper function for this, feels like there's some refactoring room here between the two modes. v2: backlight notifier is also interested in the mode change event, it calls lcd->set_mode, of which there are 3 implementations. Thanks to Maarten for spotting this. So we keep that. We can ditch the differentiation between mode change and all mode changes (because backlight notifier doesn't care), and we can drop the FBINFO_MISC_USEREVENT stuff too, because that's just to prevent recursion between fbmem.c and fbcon.c. While at it flatten the control flow a bit. v3: Need to add a static inline to the dummy function. v4: Add missing #include <fbcon.h> to sh_mob (Sam). Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Daniel Vetter authored
Instead of wiring almost everything down to the very last line using goto soup (but not consistently, where would the fun be otherwise) drop out early when checks fail. This allows us to flatten the huge indent levels to just 1. Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW does nothing. This bug exists ever since this code was extracted as a common helper in 2002, hence I decided against fixing it. Everyone just better have a fb_check_var to make sure things work correctly. Signed-off-by:
-
Daniel Vetter authored
With the recursion broken in the previous patch we can drop the FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion prevention was it's only job. Signed-off-by:
-
Daniel Vetter authored
There's a callchain of: fbcon_fb_blanked -> do_(un)blank_screen -> consw->con_blank -> fbcon_blank -> fb_blank Things don't go horribly wrong because the BKL console_lock safes the day, but that's about it. And the seeming recursion is broken in 2 ways: - Starting from the fbdev ioctl we set FBINFO_MISC_USEREVENT, which tells the fbcon_blank code to not call fb_blank. This was required to not deadlock when recursing on the fb_notifier_chain mutex. - Starting from the con_blank hook we're getting saved by the console_blanked checks in do_blank/unblank_screen. Or at least that's my theory. Anyway, recursion isn't awesome, so let's stop it. Breaking the recursion avoids the need to be in the FBINFO_MISC_USEREVENT critical section, so lets move it out of that too. The astute reader will notice that fb_blank seems to require lock_fb_info(), which the fbcon code seems to ignore. I have no idea how to fix that problem, so let's keep ignoring it. v2: I forgot the sysfs blanking code. v3: Fix typo in callchain in the commmit message (Sam). Signed-off-by:
-
Daniel Vetter authored
This reverts commit 994efacd . The justification is that if hw blanking fails (i.e. fbops->fb_blank) fails, then we still want to shut down the backlight. Which is exactly _not_ what fb_blank() does and so rather inconsistent if we end up with different behaviour between fbcon and direct fbdev usage. Given that the entire notifier maze is getting in the way anyway I figured it's simplest to revert this not well justified commit. v2: Add static inline to the dummy version. Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by:
-
Daniel Vetter authored
Pretty simple case really. v2: Forgot to remove a break; v3: Add static inline to the dummy versions. Signed-off-by:
-
Daniel Vetter authored
I'm not entirely clear on what new_modelist actually does, it seems exclusively for a sysfs interface. Which in the end does amount to a normal fb_set_par to check the mode, but then takes a different path in both fbmem.c and fbcon.c. I have no idea why these 2 paths are different, but then I also don't really want to find out. So just do the simple conversion to a direct function call. v2: static inline for the dummy versions, I forgot. Signed-off-by:
-
Daniel Vetter authored
With the sh_mobile notifier removed we can just directly call the fbcon code here. v2: Remove now unused local variable. v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild Signed-off-by:
-
Daniel Vetter authored
This seems to be entirely defunct: - The FB_EVEN_SUSPEND/RESUME events are only sent out by fb_set_suspend. Which is supposed to be called by drivers in their suspend/resume hooks, and not itself call into drivers. Luckily sh_mob doesn't call fb_set_suspend, so this seems to do nothing useful. - The notify hook calls sh_mobile_fb_reconfig() which in turn can call into the fb notifier. Or attempt too, since that would deadlock. So looks like leftover hacks from when this was originally introduced in commit 6011bdea Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Date: Wed Jul 21 10:13:21 2010 +0000 fbdev: sh-mobile: HDMI support for SH-Mobile SoCs So let's just remove it. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
-
Daniel Vetter authored
For some reasons the pm_vt_switch_unregister call was missing from the direct unregister_framebuffer path. Fix this. v2: fbinfo->dev is used to decided whether unlink_framebuffer has been called already. I botched that in v1. Make this all clearer by inlining __unlink_framebuffer. v3: Fix typoe in subject (Maarten). Signed-off-by:
-
Daniel Vetter authored
Except for driver bugs (which we'll catch with a WARN_ON) this is only to report failures of the new driver taking over the console. There's nothing the outgoing driver can do about that, and no one ever bothered to actually look at these return values. So remove them all. v2: fixup unregister_framebuffer in savagefb, fbtft, ivtvfb, and neofb drivers, reported by kbuild. Signed-off-by:
-
Daniel Vetter authored
Also remove the error return value. That's all errors for either driver bugs (trying to unbind something that isn't bound), or errors of the new driver that will take over. There's nothing the outgoing driver can do about this anyway, so switch over to void. Signed-off-by:
-
Daniel Vetter authored
Ever since commit c47747fd Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed May 11 14:58:34 2011 -0700 fbmem: make read/write/ioctl use the frame buffer at open time fbdev has gained proper refcounting for the fbinfo attached to any open files, which means that the backing driver (stored in fb_info->fbops) cannot untimely disappear anymore. The only thing that can happen is that the entire device just outright disappears and gets unregistered, but file_fb_info does check for that. Except that it's racy - it only checks once at the start of a file_ops, there's no guarantee that the underlying fbdev won't untimely disappear. Aside: A proper way to fix that race is probably to replicate the srcu trickery we've rolled out in drm. But given that this race has existed since forever it's probably not one we need to fix right away. do_unregister_framebuffer also nowhere clears fb_info->fbops, hence the check in lock_fb_info can't possible catch a disappearing fbdev later on. Long story short: Ever since the above commit the fb_info->fbops checks have essentially become dead code. Remove this all. Aside from the file_ops callbacks, and stuff called from there there's only register/unregister code left. If that goes wrong a driver managed to register/unregister a device instance twice or in the wrong order. That's just a driver bug. v2: - fb_mmap had an open-coded version of the fbinfo->fops check, because it doesn't need the fbinfo->lock. Delete that too. - Use the wrapper function in fb_open/release now, since no difference anymore. Signed-off-by:
-
Daniel Vetter authored
It's properly protected by reboot_lock. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Daniel Vetter authored
Simply because olpc never unregisters the damn thing. It also registers the framebuffer directly by poking around in fbdev core internals, so it's all around rather broken. Signed-off-by:
-
Daniel Vetter authored
Which means lock_fb_info can never fail. Remove the error handling. Signed-off-by:
-
Daniel Vetter authored
Which means lock_fb_info can never fail. Remove the error handling. Signed-off-by:
-
Daniel Vetter authored
It's dead code, and removing it avoids me having to understand what it's doing with lock_fb_info. v2: Also remove sh_mobile_lcdc_must_reconfigure, now unused (Sam). Signed-off-by:
-
Daniel Vetter authored
With commit 6104c370 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev we have a static dependency between fbcon and fbdev, and we can replace the indirection through the notifier chain with a function call. v2: Sam Ravnborg noticed that mach-pxa/am200epd.c has a notifier too, and listens to this. ... Looking at the code it seems to wait for some fb to show up, so that it can get the framebuffer base address from the fb_info struct. I suspect his is some firmware fbdev. Then it uses that information to let the real fbdev driver (metronomefb.c by the looks) get at the framebuffer memory. This doesn't looke like it's easy to fix (except by deleting the entire thing, seems untouched since 2008, we might be able to get away with that), so let's just stuff a few #ifdef into fb.h and fbmem.c and cry over them for a bit. Signed-off-by: Daniel...
-
Daniel Vetter authored
This is unused code since commit 6104c370 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev when fbcon was made a compile-time static dependency of fbdev. We can't exit fbcon anymore without exiting fbdev first, which only works if all fbdev drivers have unloaded already. Hence this is all dead code. v2: I missed that fbcon_exit is also called from con_deinit stuff, and there fbcon_has_exited prevents double-cleanup. But we can fix that by properly resetting con2fb_map[] to all -1, which is used everywhere else to indicate "no fb_info allocate to this console". With that change the double-cleanup (which resulted in a module refcount underflow, among other things) is prevented. Aside: con2fb_map is a signed char, so don't register more than 128 fb_info or hilarity will ensue. v3: CI showed me that I still didn't fully understand what's going on here. The leaked references in con2fb_map have been used upon rebinding the fb console in fbcon_init. It worked because fbdev unregistering still cleaned out con2fb_map, and reset it to info_idx. If the last fbdev driver unregistered, then it also reset info_idx, and unregistered the fbcon driver. Imo that's all a bit fragile, so let's keep the con2fb_map reset to -1, and in fbcon_init pick info_idx if we're starting fresh. That means unbinding and rebinding will cleanse the mapping, but why are you doing that if you want to retain the mapping, so should be fine. Also, I think info_idx == -1 is impossible in fbcon_init - we unregister the fbcon in that case. So catch&warn about that. v4: Drop unecessary assignment - I forgot to delete the first assignment of info in fbcon_init. Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
