summaryrefslogtreecommitdiff
path: root/drivers/video/fbdev/vt8623fb.c
AgeCommit message (Collapse)Author
2020-09-08fbdev: vt8623fb: use generic power managementVaibhav Gupta
Drivers should do only device-specific jobs. But in general, drivers using legacy PCI PM framework for .suspend()/.resume() have to manage many PCI PM-related tasks themselves which can be done by PCI Core itself. This brings extra load on the driver and it directly calls PCI helper functions to handle them. Switch to the new generic framework by updating function signatures and define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove unnecessary calls to the PCI Helper functions along with the legacy .suspend & .resume bindings. The vt8623_pci_suspend() is not designed to function in the case of Freeze. Thus, the code checked for "if (state.event == PM_EVENT_FREEZE....)". This is because, in the legacy framework, this callback was invoked even in the event of Freeze. Hence, added the load of unnecessary function-call. The goal can be achieved by binding the callback with only ".suspend" and ".poweroff" in the "vt8623_pci_pm_ops" const variable. This also avoids the step of checking "state.event == PM_EVENT_FREEZE" every time the callback is invoked. Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Bjorn Helgaas <bjorn@helgaas.com> Cc: Vaibhav Gupta <vaibhav.varodek@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Andres Salomon <dilinger@queued.net> CC: Antonino Daplas <adaplas@gmail.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200819185654.151170-11-vaibhavgupta40@gmail.com
2020-07-10video: fbdev: vt8623fb: Constify static vga_regsetsRikard Falkeborn
These are not modified so make them const to allow the compiler to put them in read-only memory. Before: text data bss dec hex filename 25509 7928 64 33501 82dd drivers/video/fbdev/vt8623fb.o After: text data bss dec hex filename 26533 6904 64 33501 82dd drivers/video/fbdev/vt8623fb.o Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200701210248.64893-1-rikard.falkeborn@gmail.com
2019-12-05video: constify fb ops across all driversJani Nikula
Now that the fbops member of struct fb_info is const, we can start making the ops const as well. This does not cover all drivers; some actually modify the fbops struct, for example to adjust for different configurations, and others do more involved things that I'd rather not touch in practically obsolete drivers. Mostly this is the low hanging fruit where we can add "const" and be done with it. v3: - un-constify atyfb, mb862xx, nvidia and uvesabf (0day) v2: - fix typo (Christophe de Dinechin) - use "static const" instead of "const static" in mx3fb.c - also constify smscufx.c Cc: linux-fbdev@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com
2019-06-28video: fbdev: don't print error message on framebuffer_alloc() failureBartlomiej Zolnierkiewicz
framebuffer_alloc() can fail only on kzalloc() memory allocation failure and since kzalloc() will print error message in such case we can omit printing extra error message in drivers (which BTW is what the majority of framebuffer_alloc() users is doing already). Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-18video: fbdev: vt8623fb: constify vt8623_timing_regsJulia Lawall
vt8623_timing_regs is only passed as the first argument to svga_check_timings and as the second argument to svga_set_timings, both of which are const. So make vt8623_timing_regs const also. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-01video: fbdev: vt8623fb: constify pci_device_id.Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 11790 1913 0 13703 3587 drivers/video/fbdev/vt8623fb.o File size after adding 'const': text data bss dec hex filename 11854 1849 0 13703 3587 drivers/video/fbdev/vt8623fb.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Maik Broemme <mbroemme@libmpq.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2015-08-25drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc()Luis R. Rodriguez
This driver uses the same area for MTRR as for the ioremap(). Convert the driver from using the x86-specific MTRR code to the architecture-agnostic arch_phys_wc_add(). It will avoid MTRRs if write-combining is available. In order to take advantage of that also ensure the ioremapped area is requested as write-combining. There are a few motivations for this: a) Take advantage of PAT when available. b) Help bury MTRR code away, MTRR is architecture-specific and on x86 it is being replaced by PAT. c) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit de33c442e titled "x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()"). The conversion done is expressed by the following Coccinelle SmPL patch, it additionally required manual intervention to address all the ifdeffery and removal of redundant things which arch_phys_wc_add() already addresses such as verbose message about when MTRR fails and doing nothing when we didn't get an MTRR. @ mtrr_found @ expression index, base, size; @@ -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1); +index = arch_phys_wc_add(base, size); @ mtrr_rm depends on mtrr_found @ expression mtrr_found.index, mtrr_found.base, mtrr_found.size; @@ -mtrr_del(index, base, size); +arch_phys_wc_del(index); @ mtrr_rm_zero_arg depends on mtrr_found @ expression mtrr_found.index; @@ -mtrr_del(index, 0, 0); +arch_phys_wc_del(index); @ mtrr_rm_fb_info depends on mtrr_found @ struct fb_info *info; expression mtrr_found.index; @@ -mtrr_del(index, info->fix.smem_start, info->fix.smem_len); +arch_phys_wc_del(index); @ ioremap_replace_nocache depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap_nocache(base, size); +info->screen_base = ioremap_wc(base, size); @ ioremap_replace_default depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap(base, size); +info->screen_base = ioremap_wc(base, size); Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Juergen Gross <jgross@suse.com> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: airlied@linux.ie Cc: benh@kernel.crashing.org Cc: bhelgaas@google.com Cc: dan.j.williams@intel.com Cc: konrad.wilk@oracle.com Cc: linux-fbdev@vger.kernel.org Cc: linux-pci@vger.kernel.org Cc: mst@redhat.com Cc: toshi.kani@hp.com Cc: vinod.koul@intel.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/1440443613-13696-9-git-send-email-mcgrof@do-not-panic.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-06-23module: add per-module param_lockDan Streetman
Add a "param_lock" mutex to each module, and update params.c to use the correct built-in or module mutex while locking kernel params. Remove the kparam_block_sysfs_r/w() macros, replace them with direct calls to kernel_param_[un]lock(module). The kernel param code currently uses a single mutex to protect modification of any and all kernel params. While this generally works, there is one specific problem with it; a module callback function cannot safely load another module, i.e. with request_module() or even with indirect calls such as crypto_has_alg(). If the module to be loaded has any of its params configured (e.g. with a /etc/modprobe.d/* config file), then the attempt will result in a deadlock between the first module param callback waiting for modprobe, and modprobe trying to lock the single kernel param mutex to set the new module's param. This fixes that by using per-module mutexes, so that each individual module is protected against concurrent changes in its own kernel params, but is not blocked by changes to other module params. All built-in modules continue to use the built-in mutex, since they will always be loaded at runtime and references (e.g. request_module(), crypto_has_alg()) to them will never cause load-time param changing. This also simplifies the interface used by modules to block sysfs access to their params; while there are currently functions to block and unblock sysfs param access which are split up by read and write and expect a single kernel param to be passed, their actual operation is identical and applies to all params, not just the one passed to them; they simply lock and unlock the global param mutex. They are replaced with direct calls to kernel_param_[un]lock(THIS_MODULE), which locks THIS_MODULE's param_lock, or if the module is built-in, it locks the built-in mutex. Suggested-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2014-12-04video: fbdev: vt8623fb: suppress build warningLad, Prabhakar
this patch fixes following build warning: drivers/video/fbdev/vt8623fb.c: In function ‘vt8623_pci_probe’: drivers/video/fbdev/vt8623fb.c:734:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] par->state.vgabase = (void __iomem *) vga_res.start; ^ Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-04-17video: move fbdev to drivers/video/fbdevTomi Valkeinen
The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>