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>
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>
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>
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>
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>
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
* new 6x10 font
* various small fixes and cleanups
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUPlVtAAoJEPo9qoy8lh71kCQP/RvzQ2/7H7N/P6HsCZvBAwvM
02bp8Wx679MGhzcngv6wGVeUwcE4MyhjIbOFim4ZDduti68N4Q+eIpsqPIeef+JU
emcXe9qpcsviS41kTuRc555M9wBBHeSYB7qLubHcsUprez/UTXZZBrWbXkLBn9oD
JfP/n82NLOQdjflSrfYciPy3q4x8o3h7uycUxDwrEHI77XsitVCe/M7yJifSOmxn
LiBgn983N5YQJdM2Dorgi0cFnKCNlpUVraYlbDAiHokaGNevUowCnTp2EkwwzRpQ
QAycfaI7iTd4WniP9x4GBMieHPDoqxoqD397WnvdGCh5VBBZXVRLkQnePPSC7s1l
yK6V3UBJB6AmnM4Jxd00aC2dfTjCS6NbaS5yoav0YuH6l7HE/rXgu1APXakV40jh
vwKhy+3P/Bu47gPfuXB8LlQAZ/3oQ7dlCAH0P84waHJSlYE72RqYXH4Hr4kLQnDG
a+TYYJwFl6mkieiPFEMs+5UlOhyZJ/yQKJHp0Q0ROF0zv86kJQh3P4ozfV8V9Vq7
cDn1RHa6/5e4BKVe0NGCuKAxgpF2InFZKqS81QmtRCSIrs9kjNPTXBMci2XZw9qn
UnRvKSrUdtIxlaBKGam+lhOGGN/pzVFJbGfoDBh1SsknwHdrlHzZ1J1rwWJu7a/3
7p+9ferk4UPFNu+UUhNB
=f13d
-----END PGP SIGNATURE-----
Merge tag 'fbdev-3.18' of 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
...
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>
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>
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
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>
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>
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>
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>
Mans Rullgard