summaryrefslogtreecommitdiffstats
path: root/drivers/video/fbdev/core
Commit message (Collapse)AuthorAgeFilesLines
* fb_ddc: Allow I2C adapters without SCL read capabilityOndrej Zary2015-09-301-10/+18
| | | | | | | | | | i2c-algo-bit allows I2C adapters without SCL read capability to work but fb_ddc_read fails to work on them. Fix fb_ddc_read to work with I2C adapters not capable of reading SCL. Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: fix snprintf() limit in show_bl_curve()Dan Carpenter2015-09-011-1/+1
| | | | | | | | | | | | The limit should be "PAGE_SIZE - len" instead of PAGE_SIZE. Also let's use scnprintf() because snprintf() returns the number of bytes which would have been printed if there were space and scnprintf() returns the number of bytes actually printed. I don't think we are ever going to actually hit this limit in real life. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: fix cea_modes array sizeTomi Valkeinen2015-08-202-3/+3
| | | | | | | | | | | | | | | | | | | | | CEA defines 64 modes, indexed from 1 to 64. modedb has cea_modes arrays, which contains 64 entries. However, the code uses the CEA indices directly, i.e. the first mode is at cea_modes[1]. This means the array is one too short. This does not cause references to uninitialized memory as the code in fbmon only allows indexes up to 63, and the cea_modes does not contain an entry for the mode 64 so it could not be used in any case. However, the code contains a check 'if (idx > ARRAY_SIZE(cea_modes)', and while that check is a no-op as at that point idx cannot be >= 63, it upsets static checkers. Fix this by increasing the cea_array size to be 65, and change the code to allow mode 64. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
* fbdev: propagate result of fb_videomode_from_videomode()Vladimir Murzin2015-06-161-1/+3
| | | | | | | | | fb_videomode_from_videomode() may fail, but of_get_fb_videomode() silently covers this fact. Instead, trow the error code to the caller. Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* framebuffer: don't link fb_devio into kernel image unconditionallyHarald Geyer2015-05-072-3/+1
| | | | | | | | | | | | CONFIG_FB_DEFERRED_IO is defined as bool while CONFIG_FB is defined as tristate. Currently fb_defio.o is linked into the kernel image even if CONFIG_FB=m. I fix this by updating the Makefile to link fb_defio.o into fb.o and thus go into one place with the other core framebuffer code. Signed-off-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: remove the unnecessary includes of ppc specific header filesKevin Hao2015-03-171-4/+0
| | | | | | | | | | In the current kernel, we don't need to include these arch specific header files for ppc. Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
* video: fbdev: fix possible null dereferenceSudip Mukherjee2015-02-261-3/+3
| | | | | | | | | we were dereferencing edid first and the NULL check was after accessing that. now we are using edid only if we know that it is not NULL. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: fix sys_copyareaMans Rullgard2015-01-301-72/+65
| | | | | | | | | | | | | | | The sys_copyarea() function performs the same operation as cfb_copyarea() but using normal memory access instead of I/O accessors. Since the introduction of sys_copyarea(), there have been two fixes to cfb_copyarea(): - 00a9d699 ("framebuffer: fix cfb_copyarea") - 5b789da8 ("framebuffer: fix screen corruption when copying") This patch incorporates the fixes into sys_copyarea() as well. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: fix CVT vertical front and back porch valuesTomi Valkeinen2015-01-271-3/+3
| | | | | | | | | | | | | | | | | | CVT v1.1 spec says: "the vertical front porch shall in all cases be fixed to 3 lines". The code in fbcvt.c instead sets the _back_ porch to 3 (plus margin). After swapping cvt.v_front_porch and cvt.v_back_porch the resulting timings were in line with CVT timings in VESA DMT spec. The bug seems to be more than 9 years old, but I presume it has not been noticed as usually the video timings come from the EDID or from the timing tables in fbdev, and probably swapped values for vfp and vbp work fine for most of the displays. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: David Ung <davidu@nvidia.com> Cc: Antonino A. Daplas <adaplas@gmail.com>
* video: fbdev: Fix sparse warning messagesDavid Ung2015-01-191-37/+37
| | | | | | | | Use NULL instead of 0 for the last entry of dmt_modes struct. Supresses "sparse: Using plain integer as NULL pointer" warning. Signed-off-by: David Ung <davidu@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: Validate mode timing against monspecDavid Ung2015-01-151-9/+18
| | | | | | | | | | | | | | fbmon may generate mode timings that are out of spec of the monitor. eg DELL U2410 has a max clock 170mhz but advertises a resolutions of 1920x1200@60 in its Standard Timings using 2byte code of D1 00. When this is looked up in the DMT table it gives it a 193mhz clock. Although the DELL monitor supports 1920x1200@60, it can only run with reduced timings at 154mhz or DMT id 0x44 which has no STD 2byte code. This patch checks to see if the mode can be supported by the monitor by comparing against monspecs.dclkmax. Signed-off-by: David Ung <davidu@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: Check Standard Timing against DMTDavid Ung2015-01-152-34/+126
| | | | | | | | | | | Add the VESA Display Monitor Timing (DMT) table. During parsing of Standard Timings, it compare the 2 byte STD code with DMT to see what the VESA mode should be. If there is no entry in the vesa_modes table or no match found, it fallsback to the GTF timings. Signed-off-by: David Ung <davidu@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: fbdev: Add additional vesa modesDavid Ung2015-01-151-0/+27
| | | | | | | Add high resolution modes to vesa_modes struct. Signed-off-by: David Ung <davidu@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video/fbdev: fix defio's fsyncTomi Valkeinen2014-12-301-2/+3
| | | | | | | | | | | 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> Cc: stable@vger.kernel.org
* Merge tag 'fbdev-3.18' of ↵Linus Torvalds2014-10-182-15/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux Pull fbdev updates from Tomi Valkeinen: - new 6x10 font - various small fixes and cleanups * tag 'fbdev-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (30 commits) fonts: Add 6x10 font videomode: provide dummy inline functions for !CONFIG_OF video/atmel_lcdfb: Introduce regulator support fbdev: sh_mobile_hdmi: Re-init regs before irq re-enable on resume framebuffer: fix screen corruption when copying framebuffer: fix border color arm, fbdev, omap2, LLVMLinux: Remove nested function from omapfb arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss video: fbdev: valkyriefb.c: use container_of to resolve fb_info_valkyrie from fb_info video: fbdev: pxafb.c: use container_of to resolve pxafb_info/layer from fb_info video: fbdev: cyber2000fb.c: use container_of to resolve cfb_info from fb_info video: fbdev: controlfb.c: use container_of to resolve fb_info_control from fb_info video: fbdev: sa1100fb.c: use container_of to resolve sa1100fb_info from fb_info video: fbdev: stifb.c: use container_of to resolve stifb_info from fb_info video: fbdev: sis: sis_main.c: Cleaning up missing null-terminate in conjunction with strncpy video: valkyriefb: Fix unused variable warning in set_valkyrie_clock() video: fbdev: use %*ph specifier to dump small buffers video: mx3fb: always enable BACKLIGHT_LCD_SUPPORT video: fbdev: au1200fb: delete double assignment video: fbdev: sis: delete double assignment ...
| * framebuffer: fix screen corruption when copyingMikulas Patocka2014-09-301-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * video: fbdev: use %*ph specifier to dump small buffersAndy Shevchenko2014-09-091-10/+2
| | | | | | | | | | | | | | | | Instead of dereference each byte let's use %*ph specifier in the printk() calls. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | video/fbdev: Always built-in video= cmdline parsingDaniel Vetter2014-08-064-95/+111
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract these 2 functions and always build them in. Whiel at it fix the checkpatch fail in this code. v2: Also move fb_mode_option. Spotted by the kbuild. v3: Review from Geert: - Keep the old copyright notice from fb_mem.c, although I have no idea what exactly applies. - Only compile this when needed. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> -- I prefer if we can merge this through drm-next since we'll use it there in follow-up patches. -Daniel
* fbdev: fbmem: remove positive test on unsigned valuesFabian Frederick2014-05-091-3/+3
| | | | | | | | | | fb_image.dx, fb_image.dy and fbconf2bmap.framebuffer are __u32 Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: export fb_prepare_logoArnd Bergmann2014-05-091-0/+1
| | | | | | | | | | | | | Some drivers that may be loadable modules use the fb_prepare_logo function, so we have to export it. Found during randconfig builds with mmpfb. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* video: Check EDID for HDMI connectionDavid Ung2014-04-221-1/+8
| | | | | | | | | Check EDID Vendor Specific Data Block bytes to see if the connection is HDMI and set FB_MISC_HDMI. Signed-off-by: David Ung <davidu@nvidia.com> Signed-off-by: Christopher Freeman <cfreeman@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* fbdev: move fbdev core files to separate directoryTomi Valkeinen2014-04-1719-0/+9565
Instead of having fbdev framework core files at the root fbdev directory, mixed with random fbdev device drivers, move the fbdev core files to a separate core directory. This makes it much clearer which of the files are actually part of the fbdev framework, and which are part of device drivers. 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>
OpenPOWER on IntegriCloud