summaryrefslogtreecommitdiff
path: root/drivers/video/fbdev
AgeCommit message (Collapse)AuthorFilesLines
2017-08-26fbdev: sti: don't select CONFIG_VTArnd Bergmann1-2/+0
commit 34bf129a7f068e3108dbb051b4b05674e2a270e7 upstream. While working on another build error, I ran into several variations of this dependency loop: subsection "Kconfig recursive dependency limitations" drivers/input/Kconfig:8: symbol INPUT is selected by VT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/tty/Kconfig:12: symbol VT is selected by FB_STI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:677: symbol FB_STI depends on FB For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/Kconfig:137: symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/arm/Kconfig:6: symbol DRM_HDLCD depends on OF For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/of/Kconfig:4: symbol OF is selected by X86_INTEL_CE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:523: symbol X86_INTEL_CE depends on X86_IO_APIC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:1011: symbol X86_IO_APIC depends on X86_LOCAL_APIC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:1005: symbol X86_LOCAL_APIC depends on X86_UP_APIC For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" arch/x86/Kconfig:980: symbol X86_UP_APIC depends on PCI_MSI For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/pci/Kconfig:11: symbol PCI_MSI is selected by AMD_IOMMU For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/iommu/Kconfig:106: symbol AMD_IOMMU depends on IOMMU_SUPPORT For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/iommu/Kconfig:5: symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/acpi/Kconfig:183: symbol ACPI_VIDEO is selected by INPUT This doesn't currently show up as I fixed the 'THERMAL' part of it, but I noticed that the FB_STI dependency should not be there but was introduced by slightly incorrect bug-fix patch that tried to fix a link error. Instead of selecting 'VT' to make us enter the drivers/video/console directory at compile-time, it's sufficient to build the drivers/video/console/sticore.c file by adding its directory to when CONFIG_FB_STI is enabled. Alternatively, we could move the sticore code to another directory that is always built when we have at STI_CONSOLE or FB_STI enabled. Fixes: 17085a934592 ("parisc: stifb: should depend on STI_CONSOLE") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-07-18xen, fbfront: fix connecting to backendJuergen Gross1-2/+2
commit 9121b15b5628b38b4695282dc18c553440e0f79b upstream. Connecting to the backend isn't working reliably in xen-fbfront: in case XenbusStateInitWait of the backend has been missed the backend transition to XenbusStateConnected will trigger the connected state only without doing the actions required when the backend has connected. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-02-23fbdev: color map copying bounds checkingKees Cook1-12/+14
commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream. Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps. CVE-2016-8405 Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Peter Pi (@heisecode) of Trend Micro Cc: Min Chong <mchong@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-02-23fbdev/efifb: Fix 16 color palette entry calculationMax Staudt1-3/+3
commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream. When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green (#50bc50) and neighboring pixels have slightly different values (such as #50bc78). The reason is that fbcon loads its 16 color palette through efifb_setcolreg(), which in turn calculates a 32-bit value to write into memory for each palette index. Until now, this code could only handle 8-bit visuals and didn't mask overlapping values when ORing them. With this patch, fbcon displays the correct colors when a qemu VM is booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16"). Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver") # v2.6.24+ Signed-off-by: Max Staudt <mstaudt@suse.de> Acked-By: Peter Jones <pjones@redhat.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2016-05-01xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"Arnd Bergmann1-1/+0
commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 upstream. The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: David Vrabel <david.vrabel@citrix.com> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2016-05-01fbdev: da8xx-fb: fix videomodes of lcd panelsSushaanth Srirangapathi1-4/+3
commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad upstream. Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but forgot to update known_lcd_panels[] which had sync values according to old logic. This breaks LCD at least on DA850 EVM. This patch fixes this issue and I have tested this for panel "Sharp_LK043T1DG01" using DA850 EVM board. Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2016-01-25video: fbdev: fsl: Fix kernel crash when diu_ops is not implementedWang Dongsheng1-1/+12
commit acfc1cc13fe5bc6d7a10afa624f1e560850ddad3 upstream. If diu_ops is not implemented on platform, kernel will access a NULL pointer. We need to check this pointer in DIU initialization. Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com> Acked-by: Timur Tabi <timur@tabi.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-01-16video/fbdev: fix defio's fsyncTomi Valkeinen1-2/+3
commit 30ea9c5218651bc11cbdba7820be78f04e2d83bc upstream. fb_deferred_io_fsync() returns the value of schedule_delayed_work() as an error code, but schedule_delayed_work() does not return an error. It returns true/false depending on whether the work was already queued. Fix this by ignoring the return value of schedule_delayed_work(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2014-11-17framebuffer: fix screen corruption when copyingMikulas Patocka1-5/+8
commit 5b789da8a7fc357661fc61faaf853e9161cc9700 upstream. The function bitcpy_rev has a bug that may result in screen corruption. The bug happens under these conditions: * the end of the destination area of a copy operation is aligned on a long word boundary * the end of the source area is not aligned on a long word boundary * we are copying more than one long word In this case, the variable shift is non-zero and the variable first is zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads the last long word of the destination and writes it back unchanged (because first is zero). Correctly, we should write the variable d0 to the last word of the destination in this case. This patch fixes the bug by introducing and extra test if first is zero. The patch also removes the references to fb_memmove in the code that is commented out because fb_memmove was removed from framebuffer subsystem. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2014-10-09x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()Bruno Prémont1-39/+0
commit 20cde694027e7477cc532833e38ab9fcaa83fb64 upstream. Commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") added efifb vga_default_device() so EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such as MacBookAir2,1. Xorg detects the GPU and finds the DRI device but then bails out with "no devices detected". Note: When vga_default_device() is set boot_vga PCI sysfs attribute reflects its state. When unset this attribute is 1 whenever IORESOURCE_ROM_SHADOW flag is set. With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete while having native drivers for the GPU also makes selecting sysfb/efifb optional. Remove the efifb implementation of vga_default_device() and initialize vgaarb's vga_default_device() with the PCI GPU that matches boot screen_info in pci_fixup_video(). [bhelgaas: remove unused "dev" in efifb_setup()] Fixes: b4aa0163056b ("efifb: Implement vga_default_device() (v2)") Tested-by: Anibal Francisco Martinez Cortina <linuxkid.zeuz@gmail.com> Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-01fb: adv7393: add missing semicolonScott Jiang1-1/+1
Commit f8bd493456c3da372ae81ed8f6b903f6207b9d98 by Jingoo Han introduced this problem. This makes bfin_adv7393fb.c failed to compile. Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-06-26video: omapdss: Fix potential null pointer dereferenceSachin Kamat1-3/+5
kmalloc can return null. Add a check to avoid potential null pointer dereference error when the pointer is accessed later. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-06-26video: vt8500lcdfb: Remove kfree call since devm_kzalloc() is usedEmil Goode1-2/+0
We use devm_kzalloc() to allocate memory for the struct vt8500lcd_info pointer fbi, so there is no need to free it in vt8500lcd_remove(). Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-06-23drivers:video:fbdev atmel_lcdfb.c power GPIO registration bugMichael Welling1-0/+2
A list that was intended for storing power control GPIOs was never initialized correctly or filled. Without these lines of added code the kernel hangs when trying to access an uninitialized list when a power control GPIO is registered with the device tree. Signed-off-by: Michael Welling <mwelling@ieee.org> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-06-16Revert "offb: Add palette hack for little endian"Benjamin Herrenschmidt1-10/+1
This reverts commit e1edf18b20076da83dd231dbd2146cbbc31c0b14. This patch was a misguided attempt at fixing offb for LE ppc64 kernels on BE qemu but is just wrong ... it breaks real LE/LE setups, LE with real HW, and existing mixed endian systems that did the fight thing with the appropriate device-tree property. Bad reviewing on my part, sorry. The right fix is to either make qemu change its endian when the guest changes endian (working on that) or to use the existing foreign endian support. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> [v3.13+] ---
2014-06-12Merge tag 'modules-next-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module updates from Rusty Russell: "Most of this is cleaning up various driver sysfs permissions so we can re-add the perm check (we unified the module param and sysfs checks, but the module ones were stronger so we weakened them temporarily). Param parsing gets documented, and also "--" now forces args to be handed to init (and ignored by the kernel). Module NX/RO protections get tightened: we now set them before calling parse_args()" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: module: set nx before marking module MODULE_STATE_COMING. samples/kobject/: avoid world-writable sysfs files. drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files. drivers/staging/speakup/: avoid world-writable sysfs files. drivers/regulator/virtual: avoid world-writable sysfs files. drivers/scsi/pm8001/pm8001_ctl.c: avoid world-writable sysfs files. drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files. drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files. drivers/mtd/devices/docg3.c: avoid world-writable sysfs files. speakup: fix incorrect perms on speakup_acntsa.c cpumask.h: silence warning with -Wsign-compare Documentation: Update kernel-parameters.tx param: hand arguments after -- straight to init modpost: Fix resource leak in read_dump()
2014-06-04Merge tag 'fbdev-omap-3.16' of ↵Linus Torvalds29-513/+3310
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into next Pull omap fbdev changes from Tomi Valkeinen: - DT support for the panel drivers that were still missing it - TI AM43xx support - TI OMAP5 support * tag 'fbdev-omap-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (46 commits) OMAPDSS: move 'compatible' converter to omapdss driver OMAPDSS: HDMI: fix devm_ioremap_resource error checks OMAPDSS: HDMI: remove unused defines OMAPDSS: HDMI: cleanup WP ioremaps OMAPDSS: panel NEC-NL8048HL11 DT support Doc/DT: Add DT binding documentation for TPO td043mtea1 panel OMAPDSS: Panel TPO-TD043MTEA1 DT support Doc/DT: Add DT binding documentation for SHARP LS037V7DW01 OMAPDSS: panel sharp-ls037v7dw01 DT support OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiod Doc/DT: Add binding doc for lgphilips,lb035q02.txt OMAPDSS: panel-lgphilips-lb035q02: Add DT support OMAPDSS: panel-lgphilips-lb035q02: use gpiod for enable gpio OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO OMAPDSS: panel-dpi: enable-gpio OMAPDSS: Fix writes to DISPC_POL_FREQ Doc/DT: Add OMAP5 DSS DT bindings OMAPDSS: HDMI: cleanup ioremaps OMAPDSS: HDMI: Add OMAP5 HDMI support OMAPDSS: HDMI: PLL changes for OMAP5 ...
2014-06-04Merge tag 'fbdev-main-3.16' of ↵Linus Torvalds25-144/+162
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into next Pull main fbdev changes from Tomi Valkeinen: "Mainly fixes and small improvements. The biggest change seems to be backlight control support for mx3fb" * tag 'fbdev-main-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (31 commits) drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmap video: fbdev: s3fb.c: Fix for possible null pointer dereference video: fbdev: grvga.c: Fix for possible null pointer dereference matroxfb: perform a dummy read of M_STATUS video: of: display_timing: fix default native-mode setting video: delete unneeded call to platform_get_drvdata video: mx3fb: Add backlight control support video: omap: delete support for early fbmem allocation video: of: display_timing: remove two unsafe error messages fbdev: fbmem: remove positive test on unsigned values fbcon: Fix memory leak in con2fb_release_oldinfo() video: Kconfig: Add a dependency to the Goldfish framebuffer driver video: exynos: Add a dependency to the menu video: mx3fb: Use devm_kzalloc video/nuc900: allow modular build video: atmel needs FB_BACKLIGHT video: export fb_prepare_logo video/mbx: fix building debugfs support video/omap: fix modular build video: clarify I2C dependencies ...
2014-05-28OMAPDSS: move 'compatible' converter to omapdss driverTomi Valkeinen4-1/+235
Move the panel/encoder driver compatible-string converter from arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical place for it, as it's really an omapdss internal hack. The code is rewritten to follow the video node graph, starting from omapdss. This removes the need to have the device compatible-string database. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-27m68k/atari - atafb: convert allocation of fb ram to new interfaceMichael Schmitz1-23/+26
The new atari_stram_alloc interface returns kernel virtual addresses even if the kernel runs in FastRAM. These addresses are not guaranteed to be identical with the physical addresses. Since ST-RAM mappings have not been set up by mem_init, virt_to_phys() and its cousin do not work and the atari_stram_to_phys() etc. helpers must be used to determine physical addresses. fb.fix->smem_start needs physical addresses, fb.par->screen_base needs virtual addresses. Take care of the virt-to-phys conversion both on fb init and par changes. Signed-off-by: Michael Schmitz <schmitz@debian.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2014-05-23OMAPDSS: HDMI: fix devm_ioremap_resource error checksTomi Valkeinen5-10/+10
devm_ioremap_resource returns ERR_PTR on error, not NULL. Fix the error checks in the driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23OMAPDSS: HDMI: remove unused definesTomi Valkeinen4-11/+0
Remove some unused defines from the HDMI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23OMAPDSS: HDMI: cleanup WP ioremapsTomi Valkeinen1-18/+3
Commit 59b3d38a3691396783df108e6afbba30656edccb missed cleaning up the hdmi_wp.c file. Clean up hdmi_wp.c the same way as the others. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23drivers/video/fbdev/fb-puv3.c: Add header files for function unifb_mmapZhichuang SUN1-0/+2
Function unifb_mmap calls functions which are defined in linux/mm.h and asm/pgtable.h The related error (for unicore32 with unicore32_defconfig): CC drivers/video/fbdev/fb-puv3.o drivers/video/fbdev/fb-puv3.c: In function 'unifb_mmap': drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of function 'vm_iomap_memory' drivers/video/fbdev/fb-puv3.c:646: error: implicit declaration of function 'pgprot_noncached' Signed-off-by: Zhichuang Sun <sunzc522@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joe Perches <joe@perches.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-fbdev@vger.kernel.org Acked-by: Xuetao Guan <gxt@mprc.pku.edu.cn> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23video: fbdev: s3fb.c: Fix for possible null pointer dereferenceRickard Strandqvist1-1/+2
There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23video: fbdev: grvga.c: Fix for possible null pointer dereferenceRickard Strandqvist1-1/+2
There is otherwise a risk of a possible null pointer dereference. Was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-23matroxfb: perform a dummy read of M_STATUSMikulas Patocka1-1/+1
I had occasional screen corruption with the matrox framebuffer driver and I found out that the reason for the corruption is that the hardware blitter accesses the videoram while it is being written to. The matrox driver has a macro WaitTillIdle() that should wait until the blitter is idle, but it sometimes doesn't work. I added a dummy read mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read will flush the write buffer in the PCI chipset, and the next read of M_STATUS will return the hardware status. Since applying this patch, I had no screen corruption at all. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-20OMAPDSS: panel NEC-NL8048HL11 DT supportTomi Valkeinen1-1/+44
We don't have any working boards using this panel right now, and the panel driver looks odd compared to the panel specs. For example, the panel spec does not mention any QVGA pin. So, while this patch adds DT support to the driver, it's not really supported and there are not bindings documentation for the panel until someone can verify how the panel actually works. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Erik Gilling <konkers@android.com>
2014-05-20OMAPDSS: Panel TPO-TD043MTEA1 DT supportTomi Valkeinen1-1/+41
Add DT support for panel TPO-TD043MTEA1. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Grazvydas Ignotas <notasas@gmail.com>
2014-05-20OMAPDSS: panel sharp-ls037v7dw01 DT supportTony Lindgren1-3/+99
Add DT support for sharp-ls037v7dw01. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-20OMAPDSS: panel-sharp-ls037v7dw01: update to use gpiodTony Lindgren1-54/+54
Using gpiod will make it easier to add device tree support for this panel in the following patches. Note that all the GPIOs for this panel are optional, any of the the GPIOs could be configured with external pulls instead of GPIOs, so let's not error out if GPIOs are not found to make the panel more generic. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-20OMAPDSS: panel-lgphilips-lb035q02: Add DT supportTomi Valkeinen1-1/+44
Add DT support for panel-lgphilips-lb035q02. We disable the use of the backlight_gpio as it should be handled via backlight framework with DT boots. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Florian Vaussard <florian.vaussard@epfl.ch>
2014-05-20OMAPDSS: panel-lgphilips-lb035q02: use gpiod for enable gpioTomi Valkeinen1-14/+18
The new gpiod API supports automatic handling of active-high/active-low with DT. To make it possible to use that when booting with DT, change the driver's handling of the enable GPIO to use gpiod. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-19OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIOJyri Sarha1-1/+1
Use correct variable name for base address. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-19OMAPDSS: panel-dpi: enable-gpioTomi Valkeinen1-3/+7
The enable gpio should be optional, but the driver returns an error if it doesn't get the gpio. So change the driver to accept -ENOENT error. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Joachim Eastwood <manabian@gmail.com>
2014-05-19video: delete unneeded call to platform_get_drvdataJulia Lawall1-2/+0
Platform_get_drvdata is an accessor function, and has no purpose if its result is not used. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier x; type T; @@ - T x = platform_get_drvdata(...); ... when != x // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-16video: mx3fb: Add backlight control supportAlexander Stein2-0/+82
This patch add backlight control support to allow dimming the backlight using the internal PWM. Currently the brightness is set fixed to a maximum of 255. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-16video: omap: delete support for early fbmem allocationAaro Koskinen1-65/+2
Commit 1e434f9318efc3dddc0c0b8d2071712668154c2b (OMAPFB: remove early mem alloc from old omapfb) deleted the support for early fbmem allocation from the platform code, but some code still remains in the driver side. Delete this code now, as it repotedly causes build issues on !MMU. The patch was tested on Amstrad E3 and Nokia 770 and framebuffer functionality is not affected. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-14drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files.Rusty Russell1-1/+1
In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Vincent Sanders <vince@simtec.co.uk> Cc: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2014-05-09OMAPDSS: Fix writes to DISPC_POL_FREQTomi Valkeinen1-7/+7
When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits with the current contents of the register, never clearing the old ones, causing wrong signal polarity settings. As we write all the bits in DISPC_POL_FREQ, we don't need to care about the current contents of the register. So fix the issue by constructing new register value from scratch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: cleanup ioremapsTomi Valkeinen4-55/+10
Now that all the boards using OMAP HDMI are using DT boot, we can remove the hacks for getting the ioresources with non-DT boot. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: Add OMAP5 HDMI supportTomi Valkeinen9-2/+2082
This adds a new driver to omapdss for OMAP5 HDMI. However, the new driver uses common HDMI files which are shared with OMAP4 HDMI driver. OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very similar PLL and PHY IPs which can be handled with common code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: PLL changes for OMAP5Archit Taneja1-2/+79
Add a features struct to differentiate between the HDMI PLLs on OMAP4 and OMAP5. The OMAP5 PLL is more sensitive when it comes to locking. We need to ensure that the DCO freq isn't too low for lower pixel clocks. Modify the PLL computation slightly to ensure the HDMI PLL locks for lower frequencies. This will be later replaced by a more complex computation which makes sure all the PLL constraints are met. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: PHY changes for OMAP5Archit Taneja2-2/+94
OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This patch creates a features struct which help the driver configure the PHY based on what SoC it is. Some of the features aren't currenlty used, but will come in use later. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI coreArchit Taneja1-2/+2
The HDMI core IP on OMAP5 has a wider address range for registers. The offsets for the later registers can't fit into the u16 type currently used for hdmi register read and write functions. Use u32 for offsets instead. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: move irq & phy pwr handlingTomi Valkeinen3-80/+71
HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI driver. While this worked fine, it's not correct. The HDMI IRQ handling should be either in the hdmi_wp, or in the main hdmi driver. This patch moves the handling to the main hdmi driver, as I feel it's a more appropriate choice. This move also requires changing the handling of the PHY power, as that was partly handled in the IRQ handler. The PHY power is handled via the WP module. An option would be to give HDMI PHY driver function pointers that it could use to manage the PHY power, but as the PHY power is not needed to access the PHY registers, the handling was also moved to the main HDMI driver. This could be changed later if need be. Note that there's slightly similar power issue with the PLL: the HDMI PLLs power is also handled via the WP module. For now, the PLL power handling is still done inside the PLL driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: HDMI: improve MakefileTomi Valkeinen2-5/+9
We'll soon add support for OMAP5 HDMI, which uses some of the same files as OMAP4 HDMI does. This patch adds a new config entry "OMAP2_DSS_HDMI_COMMON", which both OMAP4 and OMAP5 HDMI config entries can select. OMAP2_DSS_HDMI_COMMON will cause the common HDMI files to be compiled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: DSI: Add OMAP5 DSI module IDsTomi Valkeinen1-0/+7
Add OMAP5 DSI module ID support to the OMAP DSI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: DPI: fix LCD3 DSI sourceTomi Valkeinen1-0/+2
At the moment the dpi driver does not handle LCD3 clock source at all. LCD3 channel gets the DSI PLL clock from DSI2 instance. Add support for LCD3's clock source in the dpi driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2014-05-09OMAPDSS: features: fix OMAP5 featuresTomi Valkeinen1-1/+2
OMAP5 has LCD3 overlay manager, and total 4 overlay managers. These are not correctly defined in the dss features. Fix them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-18 09:04:49 +0300