* [PATCH 1/10] matroxfb: set FBINFO_READS_FAST
From: Mikulas Patocka @ 2014-01-23 19:38 UTC (permalink / raw)
To: linux-fbdev
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
A time to do ls -la /usr/bin:
original patched
32bpp 5.4 3.6
24bpp 5.1 3.0
16bpp 4.9 2.5
8bpp 4.9 2.0
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/matrox/matroxfb_base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-3.12.1/drivers/video/matrox/matroxfb_base.c
=================================--- linux-3.12.1.orig/drivers/video/matrox/matroxfb_base.c 2013-11-18 18:14:25.000000000 +0100
+++ linux-3.12.1/drivers/video/matrox/matroxfb_base.c 2013-11-23 17:58:47.000000000 +0100
@@ -1773,7 +1773,8 @@ static int initMatrox2(struct matrox_fb_
FBINFO_HWACCEL_FILLRECT | /* And fillrect */
FBINFO_HWACCEL_IMAGEBLIT | /* And imageblit */
FBINFO_HWACCEL_XPAN | /* And we support both horizontal */
- FBINFO_HWACCEL_YPAN; /* And vertical panning */
+ FBINFO_HWACCEL_YPAN | /* And vertical panning */
+ FBINFO_READS_FAST;
minfo->video.len_usable &= PAGE_MASK;
fb_alloc_cmap(&minfo->fbcon.cmap, 256, 1);
^ permalink raw reply
* [PATCH 2/10] matroxfb: restore the registers M_ACCESS and M_PITCH
From: Mikulas Patocka @ 2014-01-23 19:39 UTC (permalink / raw)
To: linux-fbdev
When X11 is running and the user switches back to console, the card
modifies the content of registers M_MACCESS and M_PITCH in periodic
intervals.
This patch fixes it by restoring the content of these registers before
issuing any accelerator command.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/matrox/matroxfb_accel.c | 38 +++++++++++++++++++++++++---------
drivers/video/matrox/matroxfb_base.h | 2 +
2 files changed, 30 insertions(+), 10 deletions(-)
Index: linux-3.12.5/drivers/video/matrox/matroxfb_accel.c
=================================--- linux-3.12.5.orig/drivers/video/matrox/matroxfb_accel.c 2013-12-15 16:32:04.056383894 +0100
+++ linux-3.12.5/drivers/video/matrox/matroxfb_accel.c 2013-12-15 16:33:10.271706929 +0100
@@ -192,10 +192,18 @@ void matrox_cfbX_init(struct matrox_fb_i
minfo->accel.m_dwg_rect = M_DWG_TRAP | M_DWG_SOLID | M_DWG_ARZERO | M_DWG_SGNZERO | M_DWG_SHIFTZERO;
if (isMilleniumII(minfo)) minfo->accel.m_dwg_rect |= M_DWG_TRANSC;
minfo->accel.m_opmode = mopmode;
+ minfo->accel.m_access = maccess;
+ minfo->accel.m_pitch = mpitch;
}
EXPORT_SYMBOL(matrox_cfbX_init);
+static void matrox_accel_restore_maccess(struct matrox_fb_info *minfo)
+{
+ mga_outl(M_MACCESS, minfo->accel.m_access);
+ mga_outl(M_PITCH, minfo->accel.m_pitch);
+}
+
static void matrox_accel_bmove(struct matrox_fb_info *minfo, int vxres, int sy,
int sx, int dy, int dx, int height, int width)
{
@@ -207,7 +215,8 @@ static void matrox_accel_bmove(struct ma
CRITBEGIN
if ((dy < sy) || ((dy = sy) && (dx <= sx))) {
- mga_fifo(2);
+ mga_fifo(4);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, M_DWG_BITBLT | M_DWG_SHIFTZERO | M_DWG_SGNZERO |
M_DWG_BFCOL | M_DWG_REPLACE);
mga_outl(M_AR5, vxres);
@@ -215,7 +224,8 @@ static void matrox_accel_bmove(struct ma
start = sy*vxres+sx+curr_ydstorg(minfo);
end = start+width;
} else {
- mga_fifo(3);
+ mga_fifo(5);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, M_DWG_BITBLT | M_DWG_SHIFTZERO | M_DWG_BFCOL | M_DWG_REPLACE);
mga_outl(M_SGN, 5);
mga_outl(M_AR5, -vxres);
@@ -224,7 +234,8 @@ static void matrox_accel_bmove(struct ma
start = end+width;
dy += height-1;
}
- mga_fifo(4);
+ mga_fifo(6);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_AR0, end);
mga_outl(M_AR3, start);
mga_outl(M_FXBNDRY, ((dx+width)<<16) | dx);
@@ -246,7 +257,8 @@ static void matrox_accel_bmove_lin(struc
CRITBEGIN
if ((dy < sy) || ((dy = sy) && (dx <= sx))) {
- mga_fifo(2);
+ mga_fifo(4);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, M_DWG_BITBLT | M_DWG_SHIFTZERO | M_DWG_SGNZERO |
M_DWG_BFCOL | M_DWG_REPLACE);
mga_outl(M_AR5, vxres);
@@ -254,7 +266,8 @@ static void matrox_accel_bmove_lin(struc
start = sy*vxres+sx+curr_ydstorg(minfo);
end = start+width;
} else {
- mga_fifo(3);
+ mga_fifo(5);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, M_DWG_BITBLT | M_DWG_SHIFTZERO | M_DWG_BFCOL | M_DWG_REPLACE);
mga_outl(M_SGN, 5);
mga_outl(M_AR5, -vxres);
@@ -263,7 +276,8 @@ static void matrox_accel_bmove_lin(struc
start = end+width;
dy += height-1;
}
- mga_fifo(5);
+ mga_fifo(7);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_AR0, end);
mga_outl(M_AR3, start);
mga_outl(M_FXBNDRY, ((dx+width)<<16) | dx);
@@ -298,7 +312,8 @@ static void matroxfb_accel_clear(struct
CRITBEGIN
- mga_fifo(5);
+ mga_fifo(7);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, minfo->accel.m_dwg_rect | M_DWG_REPLACE);
mga_outl(M_FCOL, color);
mga_outl(M_FXBNDRY, ((sx + width) << 16) | sx);
@@ -341,7 +356,8 @@ static void matroxfb_cfb4_clear(struct m
width >>= 1;
sx >>= 1;
if (width) {
- mga_fifo(5);
+ mga_fifo(7);
+ matrox_accel_restore_maccess(minfo);
mga_outl(M_DWGCTL, minfo->accel.m_dwg_rect | M_DWG_REPLACE2);
mga_outl(M_FCOL, bgx);
mga_outl(M_FXBNDRY, ((sx + width) << 16) | sx);
@@ -415,7 +431,8 @@ static void matroxfb_1bpp_imageblit(stru
CRITBEGIN
- mga_fifo(3);
+ mga_fifo(5);
+ matrox_accel_restore_maccess(minfo);
if (easy)
mga_outl(M_DWGCTL, M_DWG_ILOAD | M_DWG_SGNZERO | M_DWG_SHIFTZERO | M_DWG_BMONOWF | M_DWG_LINEAR | M_DWG_REPLACE);
else
@@ -425,7 +442,8 @@ static void matroxfb_1bpp_imageblit(stru
fxbndry = ((xx + width - 1) << 16) | xx;
mmio = minfo->mmio.vbase;
- mga_fifo(6);
+ mga_fifo(8);
+ matrox_accel_restore_maccess(minfo);
mga_writel(mmio, M_FXBNDRY, fxbndry);
mga_writel(mmio, M_AR0, ar0);
mga_writel(mmio, M_AR3, 0);
Index: linux-3.12.5/drivers/video/matrox/matroxfb_base.h
=================================--- linux-3.12.5.orig/drivers/video/matrox/matroxfb_base.h 2013-12-15 16:31:56.823877143 +0100
+++ linux-3.12.5/drivers/video/matrox/matroxfb_base.h 2013-12-15 16:33:10.275039841 +0100
@@ -307,6 +307,8 @@ struct matrox_accel_data {
#endif
u_int32_t m_dwg_rect;
u_int32_t m_opmode;
+ u_int32_t m_access;
+ u_int32_t m_pitch;
};
struct v4l2_queryctrl;
^ permalink raw reply
* [PATCH 3/10] framebuffer: fix cfb_copyarea
From: Mikulas Patocka @ 2014-01-23 19:39 UTC (permalink / raw)
To: linux-fbdev
The function cfb_copyarea is buggy when the copy operation is not aligned on
long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines).
How to reproduce:
- use x86-64 machine
- use a framebuffer driver without acceleration (for example uvesafb)
- set the framebuffer to 8-bit depth
(for example fbset -a 1024x768-60 -depth 8)
- load a font with character width that is not a multiple of 8 pixels
note: the console-tools package cannot load a font that has
width different from 8 pixels. You need to install the packages
"kbd" and "console-terminus" and use the program "setfont" to
set font width (for example: setfont Uni2-Terminus20x10)
- move some text left and right on the bash command line and you get a
screen corruption
To expose more bugs, put this line to the end of uvesafb_init_info:
info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST;
- Now framebuffer console will use cfb_copyarea for console scrolling.
You get a screen corruption when console is scrolled.
This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this
patch, console scrolling in 8-bit depth with a font width that is not a
multiple of 8 pixels works fine.
The cfb_copyarea code was very buggy and it looks like it was written
and never tried with non-8-pixel font.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/cfbcopyarea.c | 153 ++++++++++++++++++++++----------------------
1 file changed, 78 insertions(+), 75 deletions(-)
Index: linux-3.4.3-fast/drivers/video/cfbcopyarea.c
=================================--- linux-3.4.3-fast.orig/drivers/video/cfbcopyarea.c 2012-07-02 02:02:08.000000000 +0200
+++ linux-3.4.3-fast/drivers/video/cfbcopyarea.c 2012-07-02 02:03:33.000000000 +0200
@@ -43,13 +43,22 @@
*/
static void
-bitcpy(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
- const unsigned long __iomem *src, int src_idx, int bits,
+bitcpy(struct fb_info *p, unsigned long __iomem *dst, unsigned dst_idx,
+ const unsigned long __iomem *src, unsigned src_idx, int bits,
unsigned n, u32 bswapmask)
{
unsigned long first, last;
int const shift = dst_idx-src_idx;
- int left, right;
+
+#if 0
+ /*
+ * If you suspect bug in this function, compare it with this simple
+ * memmove implementation.
+ */
+ fb_memmove((char *)dst + ((dst_idx & (bits - 1))) / 8,
+ (char *)src + ((src_idx & (bits - 1))) / 8, n / 8);
+ return;
+#endif
first = fb_shifted_pixels_mask_long(p, dst_idx, bswapmask);
last = ~fb_shifted_pixels_mask_long(p, (dst_idx+n) % bits, bswapmask);
@@ -98,9 +107,8 @@ bitcpy(struct fb_info *p, unsigned long
unsigned long d0, d1;
int m;
- right = shift & (bits - 1);
- left = -shift & (bits - 1);
- bswapmask &= shift;
+ int const left = shift & (bits - 1);
+ int const right = -shift & (bits - 1);
if (dst_idx+n <= bits) {
// Single destination word
@@ -110,15 +118,15 @@ bitcpy(struct fb_info *p, unsigned long
d0 = fb_rev_pixels_in_long(d0, bswapmask);
if (shift > 0) {
// Single source word
- d0 >>= right;
+ d0 <<= left;
} else if (src_idx+n <= bits) {
// Single source word
- d0 <<= left;
+ d0 >>= right;
} else {
// 2 source words
d1 = FB_READL(src + 1);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0<<left | d1>>right;
+ d0 = d0 >> right | d1 << left;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(comp(d0, FB_READL(dst), first), dst);
@@ -135,60 +143,59 @@ bitcpy(struct fb_info *p, unsigned long
if (shift > 0) {
// Single source word
d1 = d0;
- d0 >>= right;
- dst++;
+ d0 <<= left;
n -= bits - dst_idx;
} else {
// 2 source words
d1 = FB_READL(src++);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0<<left | d1>>right;
- dst++;
+ d0 = d0 >> right | d1 << left;
n -= bits - dst_idx;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(comp(d0, FB_READL(dst), first), dst);
d0 = d1;
+ dst++;
// Main chunk
m = n % bits;
n /= bits;
while ((n >= 4) && !bswapmask) {
d1 = FB_READL(src++);
- FB_WRITEL(d0 << left | d1 >> right, dst++);
+ FB_WRITEL(d0 >> right | d1 << left, dst++);
d0 = d1;
d1 = FB_READL(src++);
- FB_WRITEL(d0 << left | d1 >> right, dst++);
+ FB_WRITEL(d0 >> right | d1 << left, dst++);
d0 = d1;
d1 = FB_READL(src++);
- FB_WRITEL(d0 << left | d1 >> right, dst++);
+ FB_WRITEL(d0 >> right | d1 << left, dst++);
d0 = d1;
d1 = FB_READL(src++);
- FB_WRITEL(d0 << left | d1 >> right, dst++);
+ FB_WRITEL(d0 >> right | d1 << left, dst++);
d0 = d1;
n -= 4;
}
while (n--) {
d1 = FB_READL(src++);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0 << left | d1 >> right;
+ d0 = d0 >> right | d1 << left;
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(d0, dst++);
d0 = d1;
}
// Trailing bits
- if (last) {
- if (m <= right) {
+ if (m) {
+ if (m <= bits - right) {
// Single source word
- d0 <<= left;
+ d0 >>= right;
} else {
// 2 source words
d1 = FB_READL(src);
d1 = fb_rev_pixels_in_long(d1,
bswapmask);
- d0 = d0<<left | d1>>right;
+ d0 = d0 >> right | d1 << left;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(comp(d0, FB_READL(dst), last), dst);
@@ -202,43 +209,46 @@ bitcpy(struct fb_info *p, unsigned long
*/
static void
-bitcpy_rev(struct fb_info *p, unsigned long __iomem *dst, int dst_idx,
- const unsigned long __iomem *src, int src_idx, int bits,
+bitcpy_rev(struct fb_info *p, unsigned long __iomem *dst, unsigned dst_idx,
+ const unsigned long __iomem *src, unsigned src_idx, int bits,
unsigned n, u32 bswapmask)
{
unsigned long first, last;
int shift;
- dst += (n-1)/bits;
- src += (n-1)/bits;
- if ((n-1) % bits) {
- dst_idx += (n-1) % bits;
- dst += dst_idx >> (ffs(bits) - 1);
- dst_idx &= bits - 1;
- src_idx += (n-1) % bits;
- src += src_idx >> (ffs(bits) - 1);
- src_idx &= bits - 1;
- }
+#if 0
+ /*
+ * If you suspect bug in this function, compare it with this simple
+ * memmove implementation.
+ */
+ fb_memmove((char *)dst + ((dst_idx & (bits - 1))) / 8,
+ (char *)src + ((src_idx & (bits - 1))) / 8, n / 8);
+ return;
+#endif
+
+ dst += (dst_idx + n - 1) / bits;
+ src += (src_idx + n - 1) / bits;
+ dst_idx = (dst_idx + n - 1) % bits;
+ src_idx = (src_idx + n - 1) % bits;
shift = dst_idx-src_idx;
- first = fb_shifted_pixels_mask_long(p, bits - 1 - dst_idx, bswapmask);
- last = ~fb_shifted_pixels_mask_long(p, bits - 1 - ((dst_idx-n) % bits),
- bswapmask);
+ first = ~fb_shifted_pixels_mask_long(p, (dst_idx + 1) % bits, bswapmask);
+ last = fb_shifted_pixels_mask_long(p, (bits + dst_idx + 1 - n) % bits, bswapmask);
if (!shift) {
// Same alignment for source and dest
if ((unsigned long)dst_idx+1 >= n) {
// Single word
- if (last)
- first &= last;
- FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst);
+ if (first)
+ last &= first;
+ FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst);
} else {
// Multiple destination words
// Leading bits
- if (first != ~0UL) {
+ if (first) {
FB_WRITEL( comp( FB_READL(src), FB_READL(dst), first), dst);
dst--;
src--;
@@ -262,7 +272,7 @@ bitcpy_rev(struct fb_info *p, unsigned l
FB_WRITEL(FB_READL(src--), dst--);
// Trailing bits
- if (last)
+ if (last != -1UL)
FB_WRITEL( comp( FB_READL(src), FB_READL(dst), last), dst);
}
} else {
@@ -270,29 +280,28 @@ bitcpy_rev(struct fb_info *p, unsigned l
unsigned long d0, d1;
int m;
- int const left = -shift & (bits-1);
- int const right = shift & (bits-1);
- bswapmask &= shift;
+ int const left = shift & (bits-1);
+ int const right = -shift & (bits-1);
if ((unsigned long)dst_idx+1 >= n) {
// Single destination word
- if (last)
- first &= last;
+ if (first)
+ last &= first;
d0 = FB_READL(src);
if (shift < 0) {
// Single source word
- d0 <<= left;
+ d0 >>= right;
} else if (1+(unsigned long)src_idx >= n) {
// Single source word
- d0 >>= right;
+ d0 <<= left;
} else {
// 2 source words
d1 = FB_READL(src - 1);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0>>right | d1<<left;
+ d0 = d0 << left | d1 >> right;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
- FB_WRITEL(comp(d0, FB_READL(dst), first), dst);
+ FB_WRITEL(comp(d0, FB_READL(dst), last), dst);
} else {
// Multiple destination words
/** We must always remember the last value read, because in case
@@ -307,12 +316,12 @@ bitcpy_rev(struct fb_info *p, unsigned l
if (shift < 0) {
// Single source word
d1 = d0;
- d0 <<= left;
+ d0 >>= right;
} else {
// 2 source words
d1 = FB_READL(src--);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0>>right | d1<<left;
+ d0 = d0 << left | d1 >> right;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(comp(d0, FB_READL(dst), first), dst);
@@ -325,39 +334,39 @@ bitcpy_rev(struct fb_info *p, unsigned l
n /= bits;
while ((n >= 4) && !bswapmask) {
d1 = FB_READL(src--);
- FB_WRITEL(d0 >> right | d1 << left, dst--);
+ FB_WRITEL(d0 << left | d1 >> right, dst--);
d0 = d1;
d1 = FB_READL(src--);
- FB_WRITEL(d0 >> right | d1 << left, dst--);
+ FB_WRITEL(d0 << left | d1 >> right, dst--);
d0 = d1;
d1 = FB_READL(src--);
- FB_WRITEL(d0 >> right | d1 << left, dst--);
+ FB_WRITEL(d0 << left | d1 >> right, dst--);
d0 = d1;
d1 = FB_READL(src--);
- FB_WRITEL(d0 >> right | d1 << left, dst--);
+ FB_WRITEL(d0 << left | d1 >> right, dst--);
d0 = d1;
n -= 4;
}
while (n--) {
d1 = FB_READL(src--);
d1 = fb_rev_pixels_in_long(d1, bswapmask);
- d0 = d0 >> right | d1 << left;
+ d0 = d0 << left | d1 >> right;
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(d0, dst--);
d0 = d1;
}
// Trailing bits
- if (last) {
- if (m <= left) {
+ if (m) {
+ if (m <= bits - left) {
// Single source word
- d0 >>= right;
+ d0 <<= left;
} else {
// 2 source words
d1 = FB_READL(src);
d1 = fb_rev_pixels_in_long(d1,
bswapmask);
- d0 = d0>>right | d1<<left;
+ d0 = d0 << left | d1 >> right;
}
d0 = fb_rev_pixels_in_long(d0, bswapmask);
FB_WRITEL(comp(d0, FB_READL(dst), last), dst);
@@ -371,9 +380,9 @@ void cfb_copyarea(struct fb_info *p, con
u32 dx = area->dx, dy = area->dy, sx = area->sx, sy = area->sy;
u32 height = area->height, width = area->width;
unsigned long const bits_per_line = p->fix.line_length*8u;
- unsigned long __iomem *dst = NULL, *src = NULL;
+ unsigned long __iomem *base = NULL;
int bits = BITS_PER_LONG, bytes = bits >> 3;
- int dst_idx = 0, src_idx = 0, rev_copy = 0;
+ unsigned dst_idx = 0, src_idx = 0, rev_copy = 0;
u32 bswapmask = fb_compute_bswapmask(p);
if (p->state != FBINFO_STATE_RUNNING)
@@ -389,7 +398,7 @@ void cfb_copyarea(struct fb_info *p, con
// split the base of the framebuffer into a long-aligned address and the
// index of the first bit
- dst = src = (unsigned long __iomem *)((unsigned long)p->screen_base & ~(bytes-1));
+ base = (unsigned long __iomem *)((unsigned long)p->screen_base & ~(bytes-1));
dst_idx = src_idx = 8*((unsigned long)p->screen_base & (bytes-1));
// add offset of source and target area
dst_idx += dy*bits_per_line + dx*p->var.bits_per_pixel;
@@ -402,20 +411,14 @@ void cfb_copyarea(struct fb_info *p, con
while (height--) {
dst_idx -= bits_per_line;
src_idx -= bits_per_line;
- dst += dst_idx >> (ffs(bits) - 1);
- dst_idx &= (bytes - 1);
- src += src_idx >> (ffs(bits) - 1);
- src_idx &= (bytes - 1);
- bitcpy_rev(p, dst, dst_idx, src, src_idx, bits,
+ bitcpy_rev(p, base + (dst_idx / bits), dst_idx % bits,
+ base + (src_idx / bits), src_idx % bits, bits,
width*p->var.bits_per_pixel, bswapmask);
}
} else {
while (height--) {
- dst += dst_idx >> (ffs(bits) - 1);
- dst_idx &= (bytes - 1);
- src += src_idx >> (ffs(bits) - 1);
- src_idx &= (bytes - 1);
- bitcpy(p, dst, dst_idx, src, src_idx, bits,
+ bitcpy(p, base + (dst_idx / bits), dst_idx % bits,
+ base + (src_idx / bits), src_idx % bits, bits,
width*p->var.bits_per_pixel, bswapmask);
dst_idx += bits_per_line;
src_idx += bits_per_line;
^ permalink raw reply
* [PATCH 4/10] atyfb: set FBINFO_READS_FAST
From: Mikulas Patocka @ 2014-01-23 19:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CA+55aFxPfHmpcMH-bmRcTPUQeq5=67cKVmra6+SvT26ybvQaug@mail.gmail.com>
Set FBINFO_READS_FAST so that the console code uses scrolling instead of
rewriting. This improves scrolling speed.
A time to do ls -la /usr/bin:
original patched
32bpp 4.9 3.6
24bpp 4.9 2.9
16bpp 4.9 2.1
8bpp 4.9 1.7
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/aty/atyfb_base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-3.13-rc1/drivers/video/aty/atyfb_base.c
=================================--- linux-3.13-rc1.orig/drivers/video/aty/atyfb_base.c 2013-11-27 00:25:42.000000000 +0100
+++ linux-3.13-rc1/drivers/video/aty/atyfb_base.c 2013-11-27 00:25:55.000000000 +0100
@@ -2653,7 +2653,8 @@ static int aty_init(struct fb_info *info
FBINFO_HWACCEL_IMAGEBLIT |
FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_COPYAREA |
- FBINFO_HWACCEL_YPAN;
+ FBINFO_HWACCEL_YPAN |
+ FBINFO_READS_FAST;
#ifdef CONFIG_PMAC_BACKLIGHT
if (M64_HAS(G3_PB_1_1) && of_machine_is_compatible("PowerBook1,1")) {
^ permalink raw reply
* [PATCH 5/10] atyfb: remove resolution limit 1600
From: Mikulas Patocka @ 2014-01-23 19:40 UTC (permalink / raw)
To: linux-fbdev
The card works fine in 1980x1080 resolution. Therefore, there is no need
to limit the resolution to 1600 pixels.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/aty/atyfb_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-3.11-rc7-fast/drivers/video/aty/atyfb_base.c
=================================--- linux-3.11-rc7-fast.orig/drivers/video/aty/atyfb_base.c 2013-09-02 18:50:52.000000000 +0200
+++ linux-3.11-rc7-fast/drivers/video/aty/atyfb_base.c 2013-09-02 18:50:58.000000000 +0200
@@ -862,8 +862,8 @@ static int aty_var_to_crtc(const struct
h_sync_pol = sync & FB_SYNC_HOR_HIGH_ACT ? 0 : 1;
v_sync_pol = sync & FB_SYNC_VERT_HIGH_ACT ? 0 : 1;
- if ((xres > 1600) || (yres > 1200)) {
- FAIL("MACH64 chips are designed for max 1600x1200\n"
+ if ((xres > 1920) || (yres > 1200)) {
+ FAIL("MACH64 chips are designed for max 1920x1200\n"
"select another resolution.");
}
h_sync_strt = h_disp + var->right_margin;
^ permalink raw reply
* [PATCH 6/10] mach64: use unaligned access
From: Mikulas Patocka @ 2014-01-23 19:41 UTC (permalink / raw)
To: linux-fbdev
This patch fixes mach64 to use unaligned access to the font bitmap.
This fixes unaligned access warning on sparc64 when 14x8 font is loaded.
On x86(64), unaligned access is handled in hardware, so both functions
le32_to_cpup and get_unaligned_le32 perform the same operation.
On RISC machines, unaligned access is not handled in hardware, so we
better use get_unaligned_le32 to avoid the unaligned trap and warning.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/aty/mach64_accel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-3.4.3-fast/drivers/video/aty/mach64_accel.c
=================================--- linux-3.4.3-fast.orig/drivers/video/aty/mach64_accel.c 2012-07-02 00:10:56.000000000 +0200
+++ linux-3.4.3-fast/drivers/video/aty/mach64_accel.c 2012-07-02 00:13:29.000000000 +0200
@@ -4,6 +4,7 @@
*/
#include <linux/delay.h>
+#include <asm/unaligned.h>
#include <linux/fb.h>
#include <video/mach64.h>
#include "atyfb.h"
@@ -419,7 +420,7 @@ void atyfb_imageblit(struct fb_info *inf
u32 *pbitmap, dwords = (src_bytes + 3) / 4;
for (pbitmap = (u32*)(image->data); dwords; dwords--, pbitmap++) {
wait_for_fifo(1, par);
- aty_st_le32(HOST_DATA0, le32_to_cpup(pbitmap), par);
+ aty_st_le32(HOST_DATA0, get_unaligned_le32(pbitmap), par);
}
}
^ permalink raw reply
* [PATCH 7/10] mach64: fix cursor when character width is not a multiple of 8 pixels
From: Mikulas Patocka @ 2014-01-23 19:41 UTC (permalink / raw)
To: linux-fbdev
This patch fixes the hardware cursor on mach64 when font width is not a
multiple of 8 pixels.
If you load such a font, the cursor is expanded to the next 8-byte
boundary and a part of the next character after the cursor is not
visible.
For example, when you load a font with 12-pixel width, the cursor width
is 16 pixels and when the cursor is displayed, 4 pixels of the next
character are not visible.
The reason is this: atyfb_cursor is called with proper parameters to
load an image that is 12-pixel wide. However, the number is aligned on
the next 8-pixel boundary on the line
"unsigned int width = (cursor->image.width + 7) >> 3;" and the whole
function acts as it is was loading a 16-pixel image.
This patch fixes it so that the value written to the framebuffer is
padded with 0xaaaa (the transparent pattern) when the image size it not
a multiple of 8 pixels. The transparent pattern causes that the cursor
will not interfere with the next character.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/aty/mach64_cursor.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
Index: linux-3.4.3-fast/drivers/video/aty/mach64_cursor.c
=================================--- linux-3.4.3-fast.orig/drivers/video/aty/mach64_cursor.c 2012-07-02 01:15:38.000000000 +0200
+++ linux-3.4.3-fast/drivers/video/aty/mach64_cursor.c 2012-07-02 01:54:10.000000000 +0200
@@ -5,6 +5,7 @@
#include <linux/fb.h>
#include <linux/init.h>
#include <linux/string.h>
+#include "../fb_draw.h"
#include <asm/io.h>
@@ -157,24 +158,33 @@ static int atyfb_cursor(struct fb_info *
for (i = 0; i < height; i++) {
for (j = 0; j < width; j++) {
+ u16 l = 0xaaaa;
b = *src++;
m = *msk++;
switch (cursor->rop) {
case ROP_XOR:
// Upper 4 bits of mask data
- fb_writeb(cursor_bits_lookup[(b ^ m) >> 4], dst++);
+ l = cursor_bits_lookup[(b ^ m) >> 4] |
// Lower 4 bits of mask
- fb_writeb(cursor_bits_lookup[(b ^ m) & 0x0f],
- dst++);
+ (cursor_bits_lookup[(b ^ m) & 0x0f] << 8);
break;
case ROP_COPY:
// Upper 4 bits of mask data
- fb_writeb(cursor_bits_lookup[(b & m) >> 4], dst++);
+ l = cursor_bits_lookup[(b & m) >> 4] |
// Lower 4 bits of mask
- fb_writeb(cursor_bits_lookup[(b & m) & 0x0f],
- dst++);
+ (cursor_bits_lookup[(b & m) & 0x0f] << 8);
break;
}
+ /*
+ * If cursor size is not a multiple of 8 characters
+ * we must pad it with transparent pattern (0xaaaa).
+ */
+ if ((j + 1) * 8 > cursor->image.width) {
+ l = comp(l, 0xaaaa,
+ (1 << ((cursor->image.width & 7) * 2)) - 1);
+ }
+ fb_writeb(l & 0xff, dst++);
+ fb_writeb(l >> 8, dst++);
}
dst += offset;
}
^ permalink raw reply
* [PATCH 8/10] tgafb: fix mode setting with fbset
From: Mikulas Patocka @ 2014-01-23 19:42 UTC (permalink / raw)
To: linux-fbdev
Mode setting in the TGA driver is broken for these reasons:
- info->fix.line_length is set just once in tgafb_init_fix function. If
we change videomode, info->fix.line_length is not recalculated - so
the video mode is changed but the screen is corrupted because of wrong
info->fix.line_length.
- info->fix.smem_len is set in tgafb_init_fix to the size of the default
video mode (640x480). If we set a higher resolution,
info->fix.smem_len is smaller than the current screen size, preventing
the userspace program from mapping the framebuffer.
This patch fixes it:
- info->fix.line_length initialization is moved to tgafb_set_par so that
it is recalculated with each mode change.
- info->fix.smem_len is set to a fixed value representing the real
amount of video ram (the values are taken from xfree86 driver).
- add a check to tgafb_check_var to prevent us from setting a videomode
that doesn't fit into videoram.
- in tgafb_register, tgafb_init_fix is moved upwards, to be called
before fb_find_mode (because fb_find_mode already needs the videoram
size set in tgafb_init_fix).
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vga.kernel.org
---
drivers/video/tgafb.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
Index: linux-3.8-rc3-fast/drivers/video/tgafb.c
=================================--- linux-3.8-rc3-fast.orig/drivers/video/tgafb.c 2013-01-10 23:42:12.000000000 +0100
+++ linux-3.8-rc3-fast/drivers/video/tgafb.c 2013-01-10 23:43:16.000000000 +0100
@@ -188,6 +188,8 @@ tgafb_check_var(struct fb_var_screeninfo
if (var->xres_virtual != var->xres || var->yres_virtual != var->yres)
return -EINVAL;
+ if (var->xres * var->yres * (var->bits_per_pixel >> 3) > info->fix.smem_len)
+ return -EINVAL;
if (var->nonstd)
return -EINVAL;
if (1000000000 / var->pixclock > TGA_PLL_MAX_FREQ)
@@ -268,6 +270,7 @@ tgafb_set_par(struct fb_info *info)
par->yres = info->var.yres;
par->pll_freq = pll_freq = 1000000000 / info->var.pixclock;
par->bits_per_pixel = info->var.bits_per_pixel;
+ info->fix.line_length = par->xres * (par->bits_per_pixel >> 3);
tga_type = par->tga_type;
@@ -1476,6 +1479,7 @@ tgafb_init_fix(struct fb_info *info)
int tga_bus_tc = TGA_BUS_TC(par->dev);
u8 tga_type = par->tga_type;
const char *tga_type_name = NULL;
+ unsigned memory_size;
switch (tga_type) {
case TGA_TYPE_8PLANE:
@@ -1483,21 +1487,25 @@ tgafb_init_fix(struct fb_info *info)
tga_type_name = "Digital ZLXp-E1";
if (tga_bus_tc)
tga_type_name = "Digital ZLX-E1";
+ memory_size = 2097152;
break;
case TGA_TYPE_24PLANE:
if (tga_bus_pci)
tga_type_name = "Digital ZLXp-E2";
if (tga_bus_tc)
tga_type_name = "Digital ZLX-E2";
+ memory_size = 8388608;
break;
case TGA_TYPE_24PLUSZ:
if (tga_bus_pci)
tga_type_name = "Digital ZLXp-E3";
if (tga_bus_tc)
tga_type_name = "Digital ZLX-E3";
+ memory_size = 16777216;
break;
default:
tga_type_name = "Unknown";
+ memory_size = 16777216;
break;
}
@@ -1509,9 +1517,8 @@ tgafb_init_fix(struct fb_info *info)
? FB_VISUAL_PSEUDOCOLOR
: FB_VISUAL_DIRECTCOLOR);
- info->fix.line_length = par->xres * (par->bits_per_pixel >> 3);
info->fix.smem_start = (size_t) par->tga_fb_base;
- info->fix.smem_len = info->fix.line_length * par->yres;
+ info->fix.smem_len = memory_size;
info->fix.mmio_start = (size_t) par->tga_regs_base;
info->fix.mmio_len = 512;
@@ -1635,6 +1642,9 @@ static int tgafb_register(struct device
modedb_tga = &modedb_tc;
modedbsize_tga = 1;
}
+
+ tgafb_init_fix(info);
+
ret = fb_find_mode(&info->var, info,
mode_option ? mode_option : mode_option_tga,
modedb_tga, modedbsize_tga, NULL,
@@ -1652,7 +1662,6 @@ static int tgafb_register(struct device
}
tgafb_set_par(info);
- tgafb_init_fix(info);
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "tgafb: Could not register framebuffer\n");
^ permalink raw reply
* [PATCH 9/10] tgafb: fix data copying
From: Mikulas Patocka @ 2014-01-23 19:43 UTC (permalink / raw)
To: linux-fbdev
The functions for data copying copyarea_foreward_8bpp and
copyarea_backward_8bpp are buggy, they produce screen corruption.
This patch fixes the functions and moves the logic to one function
"copyarea_8bpp". For simplicity, the function only handles copying that
is aligned on 8 pixes. If we copy an unaligned area, generic function
cfb_copyarea is used.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/video/tgafb.c | 264 +++++++++-----------------------------------------
1 file changed, 51 insertions(+), 213 deletions(-)
Index: linux-3.8-rc3-fast/drivers/video/tgafb.c
=================================--- linux-3.8-rc3-fast.orig/drivers/video/tgafb.c 2013-01-10 23:43:16.000000000 +0100
+++ linux-3.8-rc3-fast/drivers/video/tgafb.c 2013-01-10 23:43:44.000000000 +0100
@@ -1145,222 +1145,57 @@ copyarea_line_32bpp(struct fb_info *info
__raw_writel(TGA_MODE_SBM_24BPP|TGA_MODE_SIMPLE, tga_regs+TGA_MODE_REG);
}
-/* The general case of forward copy in 8bpp mode. */
+/* The (almost) general case of backward copy in 8bpp mode. */
static inline void
-copyarea_foreward_8bpp(struct fb_info *info, u32 dx, u32 dy, u32 sx, u32 sy,
- u32 height, u32 width, u32 line_length)
+copyarea_8bpp(struct fb_info *info, u32 dx, u32 dy, u32 sx, u32 sy,
+ u32 height, u32 width, u32 line_length,
+ const struct fb_copyarea *area)
{
struct tga_par *par = (struct tga_par *) info->par;
- unsigned long i, copied, left;
- unsigned long dpos, spos, dalign, salign, yincr;
- u32 smask_first, dmask_first, dmask_last;
- int pixel_shift, need_prime, need_second;
- unsigned long n64, n32, xincr_first;
+ unsigned i, yincr;
+ int depos, sepos, backward, last_step, step;
+ u32 mask_last;
+ unsigned n32;
void __iomem *tga_regs;
void __iomem *tga_fb;
- yincr = line_length;
- if (dy > sy) {
- dy += height - 1;
- sy += height - 1;
- yincr = -yincr;
- }
-
- /* Compute the offsets and alignments in the frame buffer.
- More than anything else, these control how we do copies. */
- dpos = dy * line_length + dx;
- spos = sy * line_length + sx;
- dalign = dpos & 7;
- salign = spos & 7;
- dpos &= -8;
- spos &= -8;
-
- /* Compute the value for the PIXELSHIFT register. This controls
- both non-co-aligned source and destination and copy direction. */
- if (dalign >= salign)
- pixel_shift = dalign - salign;
- else
- pixel_shift = 8 - (salign - dalign);
-
- /* Figure out if we need an additional priming step for the
- residue register. */
- need_prime = (salign > dalign);
- if (need_prime)
- dpos -= 8;
-
- /* Begin by copying the leading unaligned destination. Copy enough
- to make the next destination address 32-byte aligned. */
- copied = 32 - (dalign + (dpos & 31));
- if (copied = 32)
- copied = 0;
- xincr_first = (copied + 7) & -8;
- smask_first = dmask_first = (1ul << copied) - 1;
- smask_first <<= salign;
- dmask_first <<= dalign + need_prime*8;
- if (need_prime && copied > 24)
- copied -= 8;
- left = width - copied;
-
- /* Care for small copies. */
- if (copied > width) {
- u32 t;
- t = (1ul << width) - 1;
- t <<= dalign + need_prime*8;
- dmask_first &= t;
- left = 0;
- }
-
- /* Attempt to use 64-byte copies. This is only possible if the
- source and destination are co-aligned at 64 bytes. */
- n64 = need_second = 0;
- if ((dpos & 63) = (spos & 63)
- && (height = 1 || line_length % 64 = 0)) {
- /* We may need a 32-byte copy to ensure 64 byte alignment. */
- need_second = (dpos + xincr_first) & 63;
- if ((need_second & 32) != need_second)
- printk(KERN_ERR "tgafb: need_second wrong\n");
- if (left >= need_second + 64) {
- left -= need_second;
- n64 = left / 64;
- left %= 64;
- } else
- need_second = 0;
- }
-
- /* Copy trailing full 32-byte sections. This will be the main
- loop if the 64 byte loop can't be used. */
- n32 = left / 32;
- left %= 32;
-
- /* Copy the trailing unaligned destination. */
- dmask_last = (1ul << left) - 1;
-
- tga_regs = par->tga_regs_base;
- tga_fb = par->tga_fb_base;
-
- /* Set up the MODE and PIXELSHIFT registers. */
- __raw_writel(TGA_MODE_SBM_8BPP|TGA_MODE_COPY, tga_regs+TGA_MODE_REG);
- __raw_writel(pixel_shift, tga_regs+TGA_PIXELSHIFT_REG);
- wmb();
-
- for (i = 0; i < height; ++i) {
- unsigned long j;
- void __iomem *sfb;
- void __iomem *dfb;
-
- sfb = tga_fb + spos;
- dfb = tga_fb + dpos;
- if (dmask_first) {
- __raw_writel(smask_first, sfb);
- wmb();
- __raw_writel(dmask_first, dfb);
- wmb();
- sfb += xincr_first;
- dfb += xincr_first;
- }
-
- if (need_second) {
- __raw_writel(0xffffffff, sfb);
- wmb();
- __raw_writel(0xffffffff, dfb);
- wmb();
- sfb += 32;
- dfb += 32;
- }
-
- if (n64 && (((unsigned long)sfb | (unsigned long)dfb) & 63))
- printk(KERN_ERR
- "tgafb: misaligned copy64 (s:%p, d:%p)\n",
- sfb, dfb);
-
- for (j = 0; j < n64; ++j) {
- __raw_writel(sfb - tga_fb, tga_regs+TGA_COPY64_SRC);
- wmb();
- __raw_writel(dfb - tga_fb, tga_regs+TGA_COPY64_DST);
- wmb();
- sfb += 64;
- dfb += 64;
- }
-
- for (j = 0; j < n32; ++j) {
- __raw_writel(0xffffffff, sfb);
- wmb();
- __raw_writel(0xffffffff, dfb);
- wmb();
- sfb += 32;
- dfb += 32;
- }
-
- if (dmask_last) {
- __raw_writel(0xffffffff, sfb);
- wmb();
- __raw_writel(dmask_last, dfb);
- wmb();
- }
-
- spos += yincr;
- dpos += yincr;
+ /* Do acceleration only if we are aligned on 8 pixels */
+ if ((dx | sx | width) & 7) {
+ cfb_copyarea(info, area);
+ return;
}
- /* Reset the MODE register to normal. */
- __raw_writel(TGA_MODE_SBM_8BPP|TGA_MODE_SIMPLE, tga_regs+TGA_MODE_REG);
-}
-
-/* The (almost) general case of backward copy in 8bpp mode. */
-static inline void
-copyarea_backward_8bpp(struct fb_info *info, u32 dx, u32 dy, u32 sx, u32 sy,
- u32 height, u32 width, u32 line_length,
- const struct fb_copyarea *area)
-{
- struct tga_par *par = (struct tga_par *) info->par;
- unsigned long i, left, yincr;
- unsigned long depos, sepos, dealign, sealign;
- u32 mask_first, mask_last;
- unsigned long n32;
- void __iomem *tga_regs;
- void __iomem *tga_fb;
-
yincr = line_length;
if (dy > sy) {
dy += height - 1;
sy += height - 1;
yincr = -yincr;
}
+ backward = dy = sy && dx > sx && dx < sx + width;
/* Compute the offsets and alignments in the frame buffer.
More than anything else, these control how we do copies. */
- depos = dy * line_length + dx + width;
- sepos = sy * line_length + sx + width;
- dealign = depos & 7;
- sealign = sepos & 7;
-
- /* ??? The documentation appears to be incorrect (or very
- misleading) wrt how pixel shifting works in backward copy
- mode, i.e. when PIXELSHIFT is negative. I give up for now.
- Do handle the common case of co-aligned backward copies,
- but frob everything else back on generic code. */
- if (dealign != sealign) {
- cfb_copyarea(info, area);
- return;
- }
-
- /* We begin the copy with the trailing pixels of the
- unaligned destination. */
- mask_first = (1ul << dealign) - 1;
- left = width - dealign;
-
- /* Care for small copies. */
- if (dealign > width) {
- mask_first ^= (1ul << (dealign - width)) - 1;
- left = 0;
- }
+ depos = dy * line_length + dx;
+ sepos = sy * line_length + sx;
+ if (backward)
+ depos += width, sepos += width;
/* Next copy full words at a time. */
- n32 = left / 32;
- left %= 32;
+ n32 = width / 32;
+ last_step = width % 32;
/* Finally copy the unaligned head of the span. */
- mask_last = -1 << (32 - left);
+ mask_last = (1ul << last_step) - 1;
+
+ if (!backward) {
+ step = 32;
+ last_step = 32;
+ } else {
+ step = -32;
+ last_step = -last_step;
+ sepos -= 32;
+ depos -= 32;
+ }
tga_regs = par->tga_regs_base;
tga_fb = par->tga_fb_base;
@@ -1377,25 +1212,33 @@ copyarea_backward_8bpp(struct fb_info *i
sfb = tga_fb + sepos;
dfb = tga_fb + depos;
- if (mask_first) {
- __raw_writel(mask_first, sfb);
- wmb();
- __raw_writel(mask_first, dfb);
- wmb();
- }
- for (j = 0; j < n32; ++j) {
- sfb -= 32;
- dfb -= 32;
+ for (j = 0; j < n32; j++) {
+ if (j < 2 && j + 1 < n32 && !backward &&
+ !(((unsigned long)sfb | (unsigned long)dfb) & 63)) {
+ do {
+ __raw_writel(sfb - tga_fb, tga_regs+TGA_COPY64_SRC);
+ wmb();
+ __raw_writel(dfb - tga_fb, tga_regs+TGA_COPY64_DST);
+ wmb();
+ sfb += 64;
+ dfb += 64;
+ j += 2;
+ } while (j + 1 < n32);
+ j--;
+ continue;
+ }
__raw_writel(0xffffffff, sfb);
wmb();
__raw_writel(0xffffffff, dfb);
wmb();
+ sfb += step;
+ dfb += step;
}
if (mask_last) {
- sfb -= 32;
- dfb -= 32;
+ sfb += last_step - step;
+ dfb += last_step - step;
__raw_writel(mask_last, sfb);
wmb();
__raw_writel(mask_last, dfb);
@@ -1456,14 +1299,9 @@ tgafb_copyarea(struct fb_info *info, con
else if (bpp = 32)
cfb_copyarea(info, area);
- /* Detect overlapping source and destination that requires
- a backward copy. */
- else if (dy = sy && dx > sx && dx < sx + width)
- copyarea_backward_8bpp(info, dx, dy, sx, sy, height,
- width, line_length, area);
else
- copyarea_foreward_8bpp(info, dx, dy, sx, sy, height,
- width, line_length);
+ copyarea_8bpp(info, dx, dy, sx, sy, height,
+ width, line_length, area);
}
^ permalink raw reply
* [PATCH 10/10] tgafb: avoid restriction on modes with line length not a multiple of 64
From: Mikulas Patocka @ 2014-01-23 19:44 UTC (permalink / raw)
To: linux-fbdev
In tgafb there is a restriction that prevents the user from setting a
videomode with line length not a multiple of 64 bytes (for example,
800x600 is not allowed).
The reason for this restriction it that functions copyarea_line_8bpp and
copyarea_line_32bpp can not handle a line length that is not a multiple
of 64 bytes.
This patch removes this restriction on mode setting and makes sure that
the functions copyarea_line_8bpp and copyarea_line_32bpp are called only
if line length is a multiple of 64 bytes. If we set a mode 800x600,
the functions copyarea_line_8bpp and copyarea_line_32bpp are not used,
generic functions for copying are used instead and it works just fine.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
---
drivers/video/tgafb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-3.8-rc3-fast/drivers/video/tgafb.c
=================================--- linux-3.8-rc3-fast.orig/drivers/video/tgafb.c 2013-01-10 23:43:44.000000000 +0100
+++ linux-3.8-rc3-fast/drivers/video/tgafb.c 2013-01-10 23:43:49.000000000 +0100
@@ -198,8 +198,8 @@ tgafb_check_var(struct fb_var_screeninfo
return -EINVAL;
/* Some of the acceleration routines assume the line width is
- a multiple of 64 bytes. */
- if (var->xres * (par->tga_type = TGA_TYPE_8PLANE ? 1 : 4) % 64)
+ a multiple of 8 bytes. */
+ if (var->xres * (par->tga_type = TGA_TYPE_8PLANE ? 1 : 4) % 8)
return -EINVAL;
return 0;
@@ -1286,7 +1286,7 @@ tgafb_copyarea(struct fb_info *info, con
bpp = info->var.bits_per_pixel;
/* Detect copies of the entire line. */
- if (width * (bpp >> 3) = line_length) {
+ if (!(line_length & 63) && width * (bpp >> 3) = line_length) {
if (bpp = 8)
copyarea_line_8bpp(info, dy, sy, height, width);
else
^ permalink raw reply
* Re: [PATCH 4/10] atyfb: set FBINFO_READS_FAST
From: Linus Torvalds @ 2014-01-23 19:45 UTC (permalink / raw)
To: Mikulas Patocka
Cc: linux-fbdev@vger.kernel.org, Tomi Valkeinen,
Linux Kernel Mailing List
In-Reply-To: <alpine.LRH.2.02.1401231426470.7971@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> Both mach64 and matrox have a hardware bitter that is faster than
> rewriting the console - that's why FBINFO_READS_FAST improves performance
> for them.
My point is that I'd expect *anything* that has a hardware blitter to
be faster than rewriting the screen.
FBINFO_READS_FAST is documented to be about "soft-copy" being faster
than re-rendering. Which I take to be about actually doing copying in
*software*.
In particular, updatescrollmode() seems to do this right. It sets
p->scrollmode based on whether there's an accelerated copyarea. But
then SCROLL_PAN/WRAP_MOVE ends up re-testing FBINFO_READS_FAST,
ignoring any hw-accelerated copy-area, and I don't quite see why..
Linus
^ permalink raw reply
* Re: [PATCH 4/10] atyfb: set FBINFO_READS_FAST
From: Mikulas Patocka @ 2014-01-23 20:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fbdev@vger.kernel.org, Tomi Valkeinen,
Linux Kernel Mailing List
In-Reply-To: <CA+55aFxrZE6oxu5CxFo3mRwGdVcq3jvnn_ChoSJDFgQz45Lq_A@mail.gmail.com>
On Thu, 23 Jan 2014, Linus Torvalds wrote:
> On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> > Both mach64 and matrox have a hardware bitter that is faster than
> > rewriting the console - that's why FBINFO_READS_FAST improves performance
> > for them.
>
> My point is that I'd expect *anything* that has a hardware blitter to
> be faster than rewriting the screen.
>
> FBINFO_READS_FAST is documented to be about "soft-copy" being faster
> than re-rendering. Which I take to be about actually doing copying in
> *software*.
>
> In particular, updatescrollmode() seems to do this right. It sets
> p->scrollmode based on whether there's an accelerated copyarea. But
> then SCROLL_PAN/WRAP_MOVE ends up re-testing FBINFO_READS_FAST,
> ignoring any hw-accelerated copy-area, and I don't quite see why..
>
> Linus
I think the argument why not to use the blitter was this:
Some hardware have font expansion - you submit monochromatic bitwise image
of the character via writes to some register and the hardware expands it
to full color. Mach64 has this capability, matrox doesn't (maybe it does,
but the driver doesn't use it).
If you use font expansion, you actually generate less load on the videoram
than using the blitter (the expander only writes to the videoram; the
blitter reads data from the videoram and stores them back).
But the benchmarks that I performed show that the blitter is faster than
the font expander. Maybe on a different computer that has better
bufferring in the PCI chipset the font expander could be faster - who
knows?
Mikulas
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Jingoo Han @ 2014-01-24 2:25 UTC (permalink / raw)
To: 'Liu Ying'
Cc: 'Jani Nikula', linux-fbdev, tomi.valkeinen, plagnioj,
linux-kernel, dri-devel, 'Jingoo Han'
In-Reply-To: <52E0E093.1070803@freescale.com>
On Thursday, January 23, 2014 6:28 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
> > On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
> >> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
> >>> We don't have to turn backlight on/off everytime a blanking
> >>> or unblanking event comes because the backlight status may
> >>> have already been what we want. Another thought is that one
> >>> backlight device may be shared by multiple framebuffers. We
> >>> don't hope blanking one of the framebuffers may turn the
> >>> backlight off for all the other framebuffers, since they are
> >>> likely being active to display something. This patch adds
> >>> some logics to record each framebuffer's backlight usage to
> >>> determine the backlight device use count and whether the
> >>> backlight should be turned on or off. To be more specific,
> >>> only one unblank operation on a certain blanked framebuffer
> >>> may increase the backlight device's use count by one, while
> >>> one blank operation on a certain unblanked framebuffer may
> >>> decrease the use count by one, because the userspace is
> >>> likely to unblank a unblanked framebuffer or blank a blanked
> >>> framebuffer.
> >>>
> >>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> >>> ---
> >>> v1 can be found at https://lkml.org/lkml/2013/5/30/139
> >>>
> >>> v1->v2:
> >>> * Make the commit message be more specific about the condition
> >>> in which backlight device use count can be increased/decreased.
> >>> * Correct the setting for bd->props.fb_blank.
> >>>
> >>> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> >>> include/linux/backlight.h | 6 ++++++
> >>> 2 files changed, 27 insertions(+), 7 deletions(-)
> >>>
> >
> > [.....]
> >>
> >> Anything backlight worries me a little, and there are actually three
> >> changes bundled into one patch here:
> >>
> >> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
> >> changes from 0->1 or 1->0.
> >>
> >> 2. Calling backlight_update_status() only with the above change, and not
> >> on all notifier callbacks.
> >>
> >> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
> >> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
>
> Since I have already post v3(https://lkml.org/lkml/2014/1/22/126)
> to change the setting for bd->props.fb_blank, the idea of the 3rd point
> is not very appropriate any more.
OK, I see.
>
> >>
> >> The rationale in the commit message seems plausible, and AFAICT the code
> >> does what it says on the box, so for that (and for that alone) you can
> >> have my
> >>
> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> >>
> >> *BUT* it would be laborous to figure out whether this change in
> >> behaviour might regress some drivers. I'm just punting on that. And that
> >> brings us back to the three changes above - in a bisect POV it might be
> >> helpful to split the patch up. Up to the maintainers.
> >
> > I agree with Jani Nikula's opinion.
> > Please split this patch into three patches as above mentioned.
> >
>
> I am open to split the patch up.
> However, IMHO, this patch is somewhat self-contained.
> For example, if we try to create 2 patches for the 1st point and
> the 2nd point Jani mentioned, one patch would invent the use_count
> and call backlight_update_status() on all notifier callbacks(just
> ignore the use_count).
> Do you think this is a good patch?
The calling backlight_update_status() regardless the use_count
Will make the critical side effect? I don't think so.
Also, these two patches will be merged at the same time.
Please, split the patch into two patches. It would be clearer.
One more thing, please keep the indent using "Enter", when
sending your reply mail.
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH v4 0/2] backlight: update bl status and some bd properties when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
We don't have to turn backlight on/off every time a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch set adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight status should be updated or not.
Liu Ying (2):
backlight: update bd state & fb_blank properties when necessary
backlight: update backlight status when necessary
v3->v4:
* Split v3 into 2 patches to separate the change for updating the
backlight device properties and backlight status, according to
the comments from Jani Nikula and Jingoo Han.
v2->v3:
* Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
when we turn off a blacklight.
* Correct some trivial typos in the commit message.
v1->v2:
* Make the commit message be more specific about the condition
in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.
drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
include/linux/backlight.h | 6 ++++++
2 files changed, 27 insertions(+), 7 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v4 1/2] backlight: update bd state & fb_blank properties when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
We don't have to update the state and fb_blank properties of
a backlight device every time a blanking or unblanking event
comes because they may have already been what we want. Another
thought is that one backlight device may be shared by multiple
framebuffers. The backlight driver should take the backlight
device as a resource shared by all the associated framebuffers.
This patch adds some logics to record each framebuffer's backlight
usage to determine the backlight device use count and whether
the two properties should be updated or not. To be more specific,
only one unblank operation on a certain blanked framebuffer may
increase the backlight device's use count by one, while one blank
operation on a certain unblanked framebuffer may decrease the use
count by one, because the userspace is likely to unblank an
unblanked framebuffer or blank a blanked framebuffer.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/backlight/backlight.c | 23 ++++++++++++++++++-----
include/linux/backlight.h | 6 ++++++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 5d05555..efc9a2d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -41,6 +41,8 @@ static int fb_notifier_callback(struct notifier_block *self,
{
struct backlight_device *bd;
struct fb_event *evdata = data;
+ int node = evdata->info->node;
+ int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,11 +53,22 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
- bd->props.fb_blank = *(int *)evdata->data;
- if (bd->props.fb_blank = FB_BLANK_UNBLANK)
- bd->props.state &= ~BL_CORE_FBBLANK;
- else
- bd->props.state |= BL_CORE_FBBLANK;
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank = FB_BLANK_UNBLANK &&
+ !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK &&
+ bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = fb_blank;
+ }
+ }
backlight_update_status(bd);
}
mutex_unlock(&bd->ops_lock);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
#define _LINUX_BACKLIGHT_H
#include <linux/device.h>
+#include <linux/fb.h>
#include <linux/mutex.h>
#include <linux/notifier.h>
@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;
struct device dev;
+
+ /* Multiple framebuffers may share one backlight device */
+ bool fb_bl_on[FB_MAX];
+
+ int use_count;
};
static inline void backlight_update_status(struct backlight_device *bd)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/2] backlight: update backlight status when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
We don't have to update a backlight status every time a
blanking or unblanking event comes because the backlight
status may have already been what we want. Another thought
is that one backlight device may be shared by multiple
framebuffers. We don't hope blanking one of the framebuffers
may turn the backlight off for all the other framebuffers,
since they are likely being active to display something.
This patch makes the backlight status be updated only when
the relevant backlight device's use count changes from zero
to one or from one to zero.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/backlight/backlight.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index efc9a2d..27d3cf2 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,7 +34,7 @@ static const char *const backlight_types[] = {
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
* framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
@@ -60,6 +60,7 @@ static int fb_notifier_callback(struct notifier_block *self,
if (!bd->use_count++) {
bd->props.state &= ~BL_CORE_FBBLANK;
bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
}
} else if (fb_blank != FB_BLANK_UNBLANK &&
bd->fb_bl_on[node]) {
@@ -67,9 +68,9 @@ static int fb_notifier_callback(struct notifier_block *self,
if (!(--bd->use_count)) {
bd->props.state |= BL_CORE_FBBLANK;
bd->props.fb_blank = fb_blank;
+ backlight_update_status(bd);
}
}
- backlight_update_status(bd);
}
mutex_unlock(&bd->ops_lock);
return 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 0/2] backlight: update bl status and some bd properties when necessary
From: Jingoo Han @ 2014-01-24 8:20 UTC (permalink / raw)
To: 'Liu Ying'
Cc: 'Jean-Christophe PLAGNIOL-VILLARD',
'Tomi Valkeinen', linux-fbdev, linux-kernel, dri-devel,
'Jani Nikula', 'Jingoo Han'
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
On Friday, January 24, 2014 3:05 PM, Liu Ying wrote:
>
> We don't have to turn backlight on/off every time a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple framebuffers. We
> don't hope blanking one of the framebuffers may turn the
> backlight off for all the other framebuffers, since they are
> likely being active to display something. This patch set adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight status should be updated or not.
>
> Liu Ying (2):
> backlight: update bd state & fb_blank properties when necessary
> backlight: update backlight status when necessary
Thank you for sending the v4 patch.
I have no objection against this patch. However, I will wait
for other people's opinions. Then, if there is no objection,
I will ask Andrew Morton to merge this patch into mm-tree.
Thanks.
Best regards,
Jingoo Han
>
> v3->v4:
> * Split v3 into 2 patches to separate the change for updating the
> backlight device properties and backlight status, according to
> the comments from Jani Nikula and Jingoo Han.
>
> v2->v3:
> * Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
> when we turn off a blacklight.
> * Correct some trivial typos in the commit message.
>
> v1->v2:
> * Make the commit message be more specific about the condition
> in which backlight device use count can be increased/decreased.
> * Correct the setting for bd->props.fb_blank.
>
> drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
> include/linux/backlight.h | 6 ++++++
> 2 files changed, 27 insertions(+), 7 deletions(-)
>
> --
> 1.7.9.5
^ permalink raw reply
* RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-24 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75@gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
>
Link seems to be coming blank to me :)
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH 02/11] x86: sysfb: remove sysfb when probing real hw
From: Ingo Molnar @ 2014-01-24 10:16 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
Dave Airlie, Daniel Vetter, Tomi Valkeinen, linux-kernel,
Tom Gundersen
In-Reply-To: <CANq1E4SyciabqonrFMRa8cMSDxkFuvfqexTBMxKPih+XreF_=A@mail.gmail.com>
* David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * David Herrmann <dh.herrmann@gmail.com> wrote:
> >
> >> >> +#ifdef CONFIG_X86_SYSFB
> >> >> +# include <asm/sysfb.h>
> >> >> +#endif
> >> >
> >> > I guess a single space is sufficient?
> >> >
> >> > Better yet, I'd include sysfb.h unconditionally:
> >>
> >> Unconditionally won't work as only x86 has this header. [...]
> >
> > Well, in non-x86 code an #ifdef x86 looks ugly as well - but I guess
> > better than not building.
> >
> >> [...] If there's a way to place a dummy into asm-generic which is
> >> picked if arch/xy/include/asm/ doesn't have the header, let me know.
> >
> > Not that I know of.
> >
> >> But if I include it unconditionally without any fallback, this will
> >> fail on non-x86. And adding the header to all archs seems overkill.
> >
> > So why not drop the x86-ism and rename it to CONFIG_PLATFORM_SYSFB?
> > Some platforms configure it, some don't. Then the prototypes could
> > move into include/linux/sysfb.h or so and would be platform agnostic.
>
> This is almost exactly what patch #6 does. [...]
Indeed - I never got so far down into the series.
> [...] But it also adds ~400 lines of kernel-doc and ~400 lines of
> Documentation/. Given your remarks, I guess I will just split this
> patch into code and docs, so we can just pick it up for stable in
> case patch #1 does not fix all issues.
I have no objections to this form if it's fixed in a later patch and
this one is easier to backport. I just missed that aspect.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2014-01-24 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.
Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [GIT PULL] fbdev changes for 3.14
From: Tomi Valkeinen @ 2014-01-24 11:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-fbdev, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 6692 bytes --]
Hi Linus,
Please pull the fbdev changes for 3.14.
Tomi
The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda:
Linux 3.13-rc6 (2013-12-29 16:01:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.14
for you to fetch changes up to cb1fbad7ec250ac408a4682d38b205958a17a02b:
Merge branches '3.14/fbdev', '3.14/dss-misc' and '3.14/dss-fclk' into for-next (2014-01-20 10:57:01 +0200)
----------------------------------------------------------------
fbdev changes for 3.14
This is a rather boring pull request. There is one new fb driver, OpenCores
VGA/LCD, but other than that it's just minor cleanups and fixes.
----------------------------------------------------------------
Archit Taneja (2):
OMAPDSS: HDMI4: Accept non-standard timings
OMAPDSS: DISPC: Preload more data in pipeline DMAs for OMAP4+ SoCs
Dan Carpenter (3):
video: mmp: delete a stray mutex_unlock()
video: mmp: Using plain integer as NULL pointer
tgafb: potential NULL dereference in init
Geert Uytterhoeven (1):
video/logo: Remove MIPS-specific include section
Ivaylo Dimitrov (1):
OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
Jingoo Han (4):
video: asiliantfb: remove unnecessary pci_set_drvdata()
video: nvidiafb: remove unnecessary pci_set_drvdata()
video: rivafb: remove unnecessary pci_set_drvdata()
video: vmlfb: remove unnecessary pci_set_drvdata()
Julia Lawall (1):
i810: delete useless variable
Laurent Pinchart (1):
fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
Lothar Waßmann (2):
video: mxsfb: convert pr_debug()/dev_dbg() to pr_err()/dev_err() for error messages
video: mxsfb: fix broken videomode selection
Mark Brown (2):
video: vgacon: Don't build on arm64
video: amba-clcd: Make CLCD driver available on more platforms
Masami Ichikawa (1):
fbcon: Fix memory leak in fbcon_exit().
Olaf Hering (1):
fbmem: really support wildcard video=options for all fbdev drivers
Sachin Kamat (4):
video: ep93xx: Cleanup video-ep93xx.h header
video: msm: Cleanup video-msm_fb.h header
video: pxa: Cleanup video-pxafb.h header
video: pxa168fb: Cleanup pxa168fb.h file
Sascha Hauer (1):
video: mx3fb: Allow blocking during framebuffer allocation
Stefan Kristiansson (1):
video: add OpenCores VGA/LCD framebuffer driver
Tomi Valkeinen (25):
OMAPDSS: fix omap2 dss fck handling
OMAPDSS: remove struct dss_clock_info
OMAPDSS: simplify dss clk dump
OMAPDSS: rename parent clk variables
OMAPDSS: cleanup fck parent handling
OMAPDSS: pass pck to dss fck clock calc
OMAPDSS: add dedicated fck PLL support
OMAPDSS: fix missing EXPORT_SYMBOL()s
OMAPDSS: fix debug prints
OMAPDSS: apply fixes
OMAPDSS: DISPC: Add MFLAG defines
OMAPDSS: rename display-sysfs 'name' entry
OMAPDSS: DSI: fix fifosize
OMAPDSS: HDMI4: remove useless func calls
OMAPDSS: DISPC: fix context restore
OMAPDSS: HDMI: fix hdmi_wait_for_bit_change
OMAPDSS: HDMI: fix HDMI_WP_CLK name
OMAPDSS: HDMI: add missing core irq
OMAPDSS: DSI: split DSI memory map to smaller blocks
OMAPDSS: HDMI: rename resource names
OMAPFB: give informative print when probe succeeds
OMAPDSS: don't print errors on -EPROBE_DEFER
OMAPFB: disable overlays on driver removal
OMAPDSS: panel-acx565akm: clean-up locking
Merge branches '3.14/fbdev', '3.14/dss-misc' and '3.14/dss-fclk' into for-next
Wang YanQing (1):
fbcon: trivial optimization for fbcon_exit
Yijing Wang (1):
video: Replace local macro with PCI standard macro
drivers/video/Kconfig | 19 +-
drivers/video/Makefile | 1 +
drivers/video/asiliantfb.c | 1 -
drivers/video/console/Kconfig | 3 +-
drivers/video/console/fbcon.c | 5 +-
drivers/video/fbmem.c | 3 +
drivers/video/i810/i810_main.c | 4 +-
drivers/video/logo/logo.c | 4 -
drivers/video/mmp/core.c | 9 +-
drivers/video/mx3fb.c | 2 +-
drivers/video/mxsfb.c | 126 +++---
drivers/video/nvidia/nvidia.c | 1 -
drivers/video/ocfb.c | 440 +++++++++++++++++++++
.../omap2/displays-new/panel-sony-acx565akm.c | 44 ++-
drivers/video/omap2/dss/apply.c | 11 +-
drivers/video/omap2/dss/dispc.c | 55 ++-
drivers/video/omap2/dss/dispc.h | 20 +
drivers/video/omap2/dss/display-sysfs.c | 4 +-
drivers/video/omap2/dss/dpi.c | 18 +-
drivers/video/omap2/dss/dsi.c | 223 +++++++----
drivers/video/omap2/dss/dss.c | 163 +++-----
drivers/video/omap2/dss/dss.h | 17 +-
drivers/video/omap2/dss/dss_features.c | 1 +
drivers/video/omap2/dss/dss_features.h | 1 +
drivers/video/omap2/dss/hdmi.h | 16 +-
drivers/video/omap2/dss/hdmi4.c | 22 +-
drivers/video/omap2/dss/hdmi4_core.c | 18 +-
drivers/video/omap2/dss/hdmi_common.c | 2 +
drivers/video/omap2/dss/hdmi_phy.c | 2 +-
drivers/video/omap2/dss/hdmi_pll.c | 18 +-
drivers/video/omap2/dss/hdmi_wp.c | 16 +-
drivers/video/omap2/dss/overlay.c | 5 -
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/dss/venc.c | 3 +-
drivers/video/omap2/omapfb/omapfb-main.c | 19 +
drivers/video/riva/fbdev.c | 1 -
drivers/video/sh_mobile_lcdcfb.c | 2 +-
drivers/video/tgafb.c | 21 +-
drivers/video/vermilion/vermilion.c | 1 -
include/linux/platform_data/video-ep93xx.h | 10 +-
include/linux/platform_data/video-msm_fb.h | 3 +-
include/linux/platform_data/video-pxafb.h | 2 -
include/video/pxa168fb.h | 2 -
43 files changed, 949 insertions(+), 413 deletions(-)
create mode 100644 drivers/video/ocfb.c
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv3 30/41] ARM: omap3-n900.dts: add display information
From: Tomi Valkeinen @ 2014-01-24 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121152605.GA5983@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On 2014-01-21 17:26, Sebastian Reichel wrote:
> On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
>> Add DT data for OMAP3 N900 board. The board has the following
>> displays:
>>
>> lcd: LCD panel connected to OMAP's SDI output
>> tv: analog svideo
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Your dss-dt-review-3 branch boots on my N900 with working display.
>
> Tested-by: Sebastian Reichel <sre@debian.org>
Ok, thanks!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* some divide by zero bugs in >fb_check_var() functions
From: Dan Carpenter @ 2014-01-24 22:35 UTC (permalink / raw)
To: linux-fbdev
My static checker find a number of divide by zero bugs in
->fb_check_var() functions. The call tree looks like this:
do_fb_ioctl() <- get var from the user.
-> fb_set_var()
-> info->fbops->fb_check_var(var, info); <- divide by zero bugs
I wonder if we could add some checking in fb_set_var() to prevent this.
drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
regards,
dan carpenter
^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:30 UTC (permalink / raw)
To: linux-fbdev
Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private Email: nasserabdul190@yahoo.com
I wait for your response.
Yours truly,
Abdul Nasser Sokariah
^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <SECEXCHANGE6DqaJY4k00003907@mail.standardelectronics.com>
Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private Email: nasserabdul190@yahoo.com
I wait for your response.
Yours truly,
Abdul Nasser Sokariah
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox