* [PATCH v3 14/29] mb862xxfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Anatolij Gustschin <agust@denx.de>
---
drivers/video/mb862xx/mb862xxfbdrv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c
index f70bd63..2191de0 100644
--- a/drivers/video/mb862xx/mb862xxfbdrv.c
+++ b/drivers/video/mb862xx/mb862xxfbdrv.c
@@ -278,7 +278,7 @@ static int mb862xxfb_pan(struct fb_var_screeninfo *var,
reg = pack(var->yoffset, var->xoffset);
outreg(disp, GC_L0WY_L0WX, reg);
- reg = pack(var->yres_virtual, var->xres_virtual);
+ reg = pack(info->var.yres_virtual, info->var.xres_virtual);
outreg(disp, GC_L0WH_L0WW, reg);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 15/29] mx3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it. Also use the
aligned fix.line_length and not the (possible) unaligned xres_virtual.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/video/mx3fb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 7e3a490..bd76858 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1062,15 +1062,15 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
y_bottom = var->yoffset;
if (!(var->vmode & FB_VMODE_YWRAP))
- y_bottom += var->yres;
+ y_bottom += fbi->var.yres;
if (y_bottom > fbi->var.yres_virtual)
return -EINVAL;
mutex_lock(&mx3_fbi->mutex);
- offset = (var->yoffset * var->xres_virtual + var->xoffset) *
- (var->bits_per_pixel / 8);
+ offset = var->yoffset * fbi->fix.line_length
+ + var->xoffset * (fbi->var.bits_per_pixel / 8);
base = fbi->fix.smem_start + offset;
dev_dbg(fbi->device, "Updating SDC BG buf %d address=0x%08lX\n",
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 16/29] neofb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/neofb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/neofb.c b/drivers/video/neofb.c
index 588527a..feea7b1 100644
--- a/drivers/video/neofb.c
+++ b/drivers/video/neofb.c
@@ -1185,8 +1185,8 @@ static int neofb_pan_display(struct fb_var_screeninfo *var,
DBG("neofb_update_start");
- Base = (var->yoffset * var->xres_virtual + var->xoffset) >> 2;
- Base *= (var->bits_per_pixel + 7) / 8;
+ Base = (var->yoffset * info->var.xres_virtual + var->xoffset) >> 2;
+ Base *= (info->var.bits_per_pixel + 7) / 8;
neoUnlock();
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 17/29] pm2fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/pm2fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pm2fb.c b/drivers/video/pm2fb.c
index 27f93aa..f4f8ce8 100644
--- a/drivers/video/pm2fb.c
+++ b/drivers/video/pm2fb.c
@@ -973,8 +973,8 @@ static int pm2fb_pan_display(struct fb_var_screeninfo *var,
{
struct pm2fb_par *p = info->par;
u32 base;
- u32 depth = (var->bits_per_pixel + 7) & ~7;
- u32 xres = (var->xres + 31) & ~31;
+ u32 depth = (info->var.bits_per_pixel + 7) & ~7;
+ u32 xres = (info->var.xres + 31) & ~31;
depth = (depth > 32) ? 32 : depth;
base = to3264(var->yoffset * xres + var->xoffset, depth, 1);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 18/29] pm3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/pm3fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pm3fb.c b/drivers/video/pm3fb.c
index 6666f45..8221b5b 100644
--- a/drivers/video/pm3fb.c
+++ b/drivers/video/pm3fb.c
@@ -1147,9 +1147,9 @@ static int pm3fb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct pm3_par *par = info->par;
- const u32 xres = (var->xres + 31) & ~31;
+ const u32 xres = (info->var.xres + 31) & ~31;
- par->base = pm3fb_shift_bpp(var->bits_per_pixel,
+ par->base = pm3fb_shift_bpp(info->var.bits_per_pixel,
(var->yoffset * xres)
+ var->xoffset);
PM3_WAIT(par, 1);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 19/29] s3c-fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 4aecf21..fd9f20d 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -883,7 +883,7 @@ static int s3c_fb_pan_display(struct fb_var_screeninfo *var,
}
}
/* Offset in bytes to the end of the displayed area */
- end_boff = start_boff + var->yres * info->fix.line_length;
+ end_boff = start_boff + info->var.yres * info->fix.line_length;
/* Temporarily turn off per-vsync update from shadow registers until
* both start and end addresses are updated to prevent corruption */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 20/29] s3fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/s3fb.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 4ca5d0c..0f9af1a 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1019,12 +1019,13 @@ static int s3fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
unsigned int offset;
/* Calculate the offset */
- if (var->bits_per_pixel = 0) {
- offset = (var->yoffset / 16) * (var->xres_virtual / 2) + (var->xoffset / 2);
+ if (info->var.bits_per_pixel = 0) {
+ offset = (var->yoffset / 16) * (info->var.xres_virtual / 2)
+ + (var->xoffset / 2);
offset = offset >> 2;
} else {
offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * var->bits_per_pixel / 8);
+ (var->xoffset * info->var.bits_per_pixel / 8);
offset = offset >> 2;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 21/29] savagefb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it. Also use the
aligned fix.line_length and not the (possible) unaligned xres_virtual.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tormod Volden <debian.tormod@gmail.com>
Cc: Antonino Daplas <adaplas@gmail.com>
---
drivers/video/savage/savagefb_driver.c | 16 +++++++---------
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/video/savage/savagefb_driver.c b/drivers/video/savage/savagefb_driver.c
index 4de541c..beb4950 100644
--- a/drivers/video/savage/savagefb_driver.c
+++ b/drivers/video/savage/savagefb_driver.c
@@ -1477,15 +1477,9 @@ static void savagefb_set_par_int(struct savagefb_par *par, struct savage_reg *r
vgaHWProtect(par, 0);
}
-static void savagefb_update_start(struct savagefb_par *par,
- struct fb_var_screeninfo *var)
+static void savagefb_update_start(struct savagefb_par *par, int base)
{
- int base;
-
- base = ((var->yoffset * var->xres_virtual + (var->xoffset & ~1))
- * ((var->bits_per_pixel+7) / 8)) >> 2;
-
- /* now program the start address registers */
+ /* program the start address registers */
vga_out16(0x3d4, (base & 0x00ff00) | 0x0c, par);
vga_out16(0x3d4, ((base & 0x00ff) << 8) | 0x0d, par);
vga_out8(0x3d4, 0x69, par);
@@ -1550,8 +1544,12 @@ static int savagefb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
struct savagefb_par *par = info->par;
+ int base;
+
+ base = (var->yoffset * info->fix.line_length
+ + (var->xoffset & ~1) * ((info->var.bits_per_pixel+7) / 8)) >> 2;
- savagefb_update_start(par, var);
+ savagefb_update_start(par, base);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 22/29] sisfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Fix checkpatch.pl warnings in the surrounding code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Thomas Winischhofer <thomas@winischhofer.net>
---
drivers/video/sis/sis_main.c | 30 ++++++++++--------------------
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/video/sis/sis_main.c b/drivers/video/sis/sis_main.c
index 7525984..078ca21 100644
--- a/drivers/video/sis/sis_main.c
+++ b/drivers/video/sis/sis_main.c
@@ -1333,19 +1333,14 @@ sisfb_set_base_CRT2(struct sis_video_info *ivideo, unsigned int base)
}
static int
-sisfb_pan_var(struct sis_video_info *ivideo, struct fb_var_screeninfo *var)
+sisfb_pan_var(struct sis_video_info *ivideo, struct fb_info *info,
+ struct fb_var_screeninfo *var)
{
- if(var->xoffset > (var->xres_virtual - var->xres)) {
- return -EINVAL;
- }
- if(var->yoffset > (var->yres_virtual - var->yres)) {
- return -EINVAL;
- }
-
- ivideo->current_base = (var->yoffset * var->xres_virtual) + var->xoffset;
+ ivideo->current_base = var->yoffset * info->var.xres_virtual
+ + var->xoffset;
/* calculate base bpp dep. */
- switch(var->bits_per_pixel) {
+ switch (info->var.bits_per_pixel) {
case 32:
break;
case 16:
@@ -1635,20 +1630,15 @@ sisfb_pan_display(struct fb_var_screeninfo *var, struct fb_info* info)
struct sis_video_info *ivideo = (struct sis_video_info *)info->par;
int err;
- if(var->xoffset > (var->xres_virtual - var->xres))
- return -EINVAL;
-
- if(var->yoffset > (var->yres_virtual - var->yres))
- return -EINVAL;
-
- if(var->vmode & FB_VMODE_YWRAP)
+ if (var->vmode & FB_VMODE_YWRAP)
return -EINVAL;
- if(var->xoffset + info->var.xres > info->var.xres_virtual ||
- var->yoffset + info->var.yres > info->var.yres_virtual)
+ if (var->xoffset + info->var.xres > info->var.xres_virtual ||
+ var->yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
- if((err = sisfb_pan_var(ivideo, var)) < 0)
+ err = sisfb_pan_var(ivideo, info, var);
+ if (err < 0)
return err;
info->var.xoffset = var->xoffset;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 23/29] sm501fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ben Dooks <ben@simtec.co.uk>
---
drivers/video/sm501fb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index 6294dca..a78254c 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -582,7 +582,7 @@ static int sm501fb_pan_crt(struct fb_var_screeninfo *var,
{
struct sm501fb_par *par = info->par;
struct sm501fb_info *fbi = par->info;
- unsigned int bytes_pixel = var->bits_per_pixel / 8;
+ unsigned int bytes_pixel = info->var.bits_per_pixel / 8;
unsigned long reg;
unsigned long xoffs;
@@ -614,10 +614,10 @@ static int sm501fb_pan_pnl(struct fb_var_screeninfo *var,
struct sm501fb_info *fbi = par->info;
unsigned long reg;
- reg = var->xoffset | (var->xres_virtual << 16);
+ reg = var->xoffset | (info->var.xres_virtual << 16);
smc501_writel(reg, fbi->regs + SM501_DC_PANEL_FB_WIDTH);
- reg = var->yoffset | (var->yres_virtual << 16);
+ reg = var->yoffset | (info->var.yres_virtual << 16);
smc501_writel(reg, fbi->regs + SM501_DC_PANEL_FB_HEIGHT);
sm501fb_sync_regs(fbi);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 24/29] tridentfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
---
drivers/video/tridentfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/tridentfb.c b/drivers/video/tridentfb.c
index c6c7756..34cf019 100644
--- a/drivers/video/tridentfb.c
+++ b/drivers/video/tridentfb.c
@@ -987,8 +987,8 @@ static int tridentfb_pan_display(struct fb_var_screeninfo *var,
unsigned int offset;
debug("enter\n");
- offset = (var->xoffset + (var->yoffset * var->xres_virtual))
- * var->bits_per_pixel / 32;
+ offset = (var->xoffset + (var->yoffset * info->var.xres_virtual))
+ * info->var.bits_per_pixel / 32;
set_screen_start(par, offset);
debug("exit\n");
return 0;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 25/29] vfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/vfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/vfb.c b/drivers/video/vfb.c
index bc67251..bf2f780 100644
--- a/drivers/video/vfb.c
+++ b/drivers/video/vfb.c
@@ -395,8 +395,8 @@ static int vfb_pan_display(struct fb_var_screeninfo *var,
|| var->xoffset)
return -EINVAL;
} else {
- if (var->xoffset + var->xres > info->var.xres_virtual ||
- var->yoffset + var->yres > info->var.yres_virtual)
+ if (var->xoffset + info->var.xres > info->var.xres_virtual ||
+ var->yoffset + info->var.yres > info->var.yres_virtual)
return -EINVAL;
}
info->var.xoffset = var->xoffset;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 26/29] vga16fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Antonino A. Daplas <adaplas@gmail.com>
---
drivers/video/vga16fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 305c975..0267acd 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -207,7 +207,7 @@ static void vga16fb_pan_var(struct fb_info *info,
* granularity if someone supports xoffset in bit resolution */
vga_io_r(VGA_IS1_RC); /* reset flip-flop */
vga_io_w(VGA_ATT_IW, VGA_ATC_PEL);
- if (var->bits_per_pixel = 8)
+ if (info->var.bits_per_pixel = 8)
vga_io_w(VGA_ATT_IW, (xoffset & 3) << 1);
else
vga_io_w(VGA_ATT_IW, xoffset & 7);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 27/29] vt8500lcdfb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alexey Charkov <alchark@gmail.com>
---
drivers/video/vt8500lcdfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 0e120d6..c13c246 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -210,8 +210,8 @@ static int vt8500lcd_pan_display(struct fb_var_screeninfo *var,
struct vt8500lcd_info *fbi = to_vt8500lcd_info(info);
writel((1 << 31)
- | (((var->xres_virtual - var->xres) * pixlen / 4) << 20)
- | (off >> 2), fbi->regbase + 0x20);
+ | (((info->var.xres_virtual - info->var.xres) * pixlen / 4) << 20)
+ | (off >> 2), fbi->regbase + 0x20);
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 28/29] vt8623fb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ondrej Zajicek <santiago@crfreenet.org>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/video/vt8623fb.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/vt8623fb.c b/drivers/video/vt8623fb.c
index f9b3e3d..4e74d26 100644
--- a/drivers/video/vt8623fb.c
+++ b/drivers/video/vt8623fb.c
@@ -620,13 +620,14 @@ static int vt8623fb_pan_display(struct fb_var_screeninfo *var, struct fb_info *i
unsigned int offset;
/* Calculate the offset */
- if (var->bits_per_pixel = 0) {
- offset = (var->yoffset / 16) * var->xres_virtual + var->xoffset;
+ if (info->var.bits_per_pixel = 0) {
+ offset = (var->yoffset / 16) * info->var.xres_virtual
+ + var->xoffset;
offset = offset >> 3;
} else {
offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * var->bits_per_pixel / 8);
- offset = offset >> ((var->bits_per_pixel = 4) ? 2 : 1);
+ (var->xoffset * info->var.bits_per_pixel / 8);
+ offset = offset >> ((info->var.bits_per_pixel = 4) ? 2 : 1);
}
/* Set the offset */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 29/29] staging: xgifb: use display information in info not in var for panning
From: Laurent Pinchart @ 2011-07-08 11:14 UTC (permalink / raw)
To: linux-fbdev
We must not use any information in the passed var besides xoffset,
yoffset and vmode as otherwise applications might abuse it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnaud Patard <apatard@mandriva.com>
---
drivers/staging/xgifb/XGI_main_26.c | 22 ++++++----------------
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c
index cadec2a..e92f6fa 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -1365,26 +1365,16 @@ static int XGIfb_do_set_var(struct fb_var_screeninfo *var, int isactive,
}
#ifdef XGIFB_PAN
-static int XGIfb_pan_var(struct fb_var_screeninfo *var)
+static int XGIfb_pan_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
unsigned int base;
/* printk("Inside pan_var"); */
- if (var->xoffset > (var->xres_virtual - var->xres)) {
- /* printk("Pan: xo: %d xv %d xr %d\n",
- var->xoffset, var->xres_virtual, var->xres); */
- return -EINVAL;
- }
- if (var->yoffset > (var->yres_virtual - var->yres)) {
- /* printk("Pan: yo: %d yv %d yr %d\n",
- var->yoffset, var->yres_virtual, var->yres); */
- return -EINVAL;
- }
- base = var->yoffset * var->xres_virtual + var->xoffset;
+ base = var->yoffset * info->var.xres_virtual + var->xoffset;
/* calculate base bpp dep. */
- switch (var->bits_per_pixel) {
+ switch (info->var.bits_per_pixel) {
case 16:
base >>= 1;
break;
@@ -1682,9 +1672,9 @@ static int XGIfb_pan_display(struct fb_var_screeninfo *var,
/* printk("\nInside pan_display:\n"); */
- if (var->xoffset > (var->xres_virtual - var->xres))
+ if (var->xoffset > (info->var.xres_virtual - info->var.xres))
return -EINVAL;
- if (var->yoffset > (var->yres_virtual - var->yres))
+ if (var->yoffset > (info->var.yres_virtual - info->var.yres))
return -EINVAL;
if (var->vmode & FB_VMODE_YWRAP) {
@@ -1697,7 +1687,7 @@ static int XGIfb_pan_display(struct fb_var_screeninfo *var,
> info->var.yres_virtual)
return -EINVAL;
}
- err = XGIfb_pan_var(var);
+ err = XGIfb_pan_var(var, info);
if (err < 0)
return err;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] drivers/video: use strings to specify the Freescale DIU
From: Anatolij Gustschin @ 2011-07-09 14:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, lethal, linux-fbdev
In-Reply-To: <1310057466-14599-1-git-send-email-timur@freescale.com>
On Thu, 7 Jul 2011 11:51:06 -0500
Timur Tabi <timur@freescale.com> wrote:
> Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
> the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
> on the kernel command line, the module command-line, and the sysfs "monitor"
> device.
>
> Note that changing the monitor port does not currently work on the P1022DS,
> because the code that talks to the PIXIS FPGA is broken.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-----
> arch/powerpc/platforms/85xx/p1022_ds.c | 47 ++++++++---------
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +++++++++-----------
> arch/powerpc/sysdev/fsl_soc.h | 25 ++++++---
> drivers/video/fsl-diu-fb.c | 73 +++++++++++++++++++------
> 5 files changed, 128 insertions(+), 94 deletions(-)
It mostly looks okay to me, please see one comment below.
Otherwise
Acked-by: Anatolij Gustschin <agust@denx.de>
...
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index 0acc7d6..9c6837e 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
...
> @@ -832,8 +862,8 @@ static int fsl_diu_set_par(struct fb_info *info)
> }
>
> ad->pix_fmt > - diu_ops.get_pixel_format(var->bits_per_pixel,
> - machine_data->monitor_port);
> + cpu_to_be32(diu_ops.get_pixel_format(machine_data->monitor_port,
> + var->bits_per_pixel));
I think you can drop cpu_to_be32 here, it is somehow confusing. The
descriptor fields are LE32, get_pixel_format() returns LE32 value.
> ad->addr = cpu_to_le32(info->fix.smem_start);
Thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH] drivers/video: use strings to specify the Freescale DIU
From: Tabi Timur-B04825 @ 2011-07-09 19:37 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: linuxppc-dev@ozlabs.org, Gala Kumar-B11780, lethal@linux-sh.org,
Tabi Timur-B04825, linux-fbdev@vger.kernel.org
In-Reply-To: <20110709163809.53f18fea@wker>
Anatolij Gustschin wrote:
>> > ad->pix_fmt >> > - diu_ops.get_pixel_format(var->bits_per_pixel,
>> > - machine_data->monitor_port);
>> > + cpu_to_be32(diu_ops.get_pixel_format(machine_data->monitor_port,
>> > + var->bits_per_pixel));
> I think you can drop cpu_to_be32 here, it is somehow confusing. The
> descriptor fields are LE32,
Not according to the structure definition:
struct diu_ad {
/* Word 0(32-bit) in DDR memory */
/* __u16 comp; */
/* __u16 pixel_s:2; */
/* __u16 pallete:1; */
/* __u16 red_c:2; */
/* __u16 green_c:2; */
/* __u16 blue_c:2; */
/* __u16 alpha_c:3; */
/* __u16 byte_f:1; */
/* __u16 res0:3; */
__be32 pix_fmt; /* hard coding pixel format */
I see other places where the endianness of pix_fmt is assumed. I'll have
to fix those later.
When I look at the 5121 and 1022 reference manuals, it says that the area
descriptor is little-endian. I think York made this register big-endian
so that it matches the endianness of get_pixel_format(), which doesn't
make much sense. I'll have to fix the whole endianness thing with pix_fmt
in another patch.
> get_pixel_format() returns LE32 value.
I don't think the endianness of get_pixel_format() is fixed. It's
whatever the CPU native endiannes is. That's why I added a cpu_to_be32().
Anyway, I'm not quite sure what the right answer is, but it seems obvious
that cpu_to_be32() is wrong. I'll post another patch which removes it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] [v2] drivers/video: use strings to specify the Freescale DIU monitor port
From: Timur Tabi @ 2011-07-09 20:38 UTC (permalink / raw)
To: lethal, agust, linuxppc-dev, linux-fbdev
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
on the kernel command line, the module command-line, and the sysfs "monitor"
device.
Note that changing the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.
Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-----
arch/powerpc/platforms/85xx/p1022_ds.c | 47 ++++++++---------
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +++++++++----------
arch/powerpc/sysdev/fsl_soc.h | 25 ++++++---
drivers/video/fsl-diu-fb.c | 74 +++++++++++++++++++-------
5 files changed, 128 insertions(+), 95 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index e41ebbd..3dc62f9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -66,8 +66,8 @@ struct fsl_diu_shared_fb {
bool in_use;
};
-unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
return 0x00000400;
}
-void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
-void mpc512x_set_monitor_port(int monitor_port)
+void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
{
}
@@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock)
iounmap(ccm);
}
-ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf)
+enum fsl_diu_monitor_port
+mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return sprintf(buf, "0 - 5121 LCD\n");
-}
-
-int mpc512x_set_sysfs_monitor_port(int val)
-{
- return 0;
+ return FSL_DIU_PORT_DVI;
}
static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb;
@@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void)
diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port = mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
- diu_ops.show_monitor_port = mpc512x_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc512x_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
#endif
}
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 266b3aa..c01c727 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -93,8 +93,8 @@
* The Area Descriptor is a 32-bit value that determine which bits in each
* pixel are to be used for each color.
*/
-static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
switch (bits_per_pixel) {
case 32:
@@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
* On some boards, the gamma table for some ports may need to be modified.
* This is not the case on the P1022DS, so we do nothing.
*/
-static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
}
@@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
* p1022ds_set_monitor_port: switch the output to a different monitor port
*
*/
-static void p1022ds_set_monitor_port(int monitor_port)
+static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
{
struct device_node *pixis_node;
void __iomem *pixis;
@@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port)
}
brdcfg1 = pixis + 9; /* BRDCFG1 is at offset 9 in the ngPIXIS */
- switch (monitor_port) {
- case 0: /* DVI */
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DVIEN);
break;
- case 1: /* Single link LVDS */
+ case FSL_DIU_PORT_LVDS:
+ printk(KERN_INFO "%s:%u\n", __func__, __LINE__);
/* Enable the DFP port, disable the DVI and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT,
PX_BRDCFG1_DFPEN);
break;
default:
- pr_err("p1022ds: unsupported monitor port %i\n", monitor_port);
+ pr_err("p1022ds: unsupported monitor port %i\n", port);
}
iounmap(pixis);
@@ -214,23 +217,18 @@ void p1022ds_set_pixel_clock(unsigned int pixclock)
}
/**
- * p1022ds_show_monitor_port: show the current monitor
- *
- * This function returns a string indicating whether the current monitor is
- * set to DVI or LVDS.
- */
-ssize_t p1022ds_show_monitor_port(int monitor_port, char *buf)
-{
- return sprintf(buf, "%c0 - DVI\n%c1 - Single link LVDS\n",
- monitor_port = 0 ? '*' : ' ', monitor_port = 1 ? '*' : ' ');
-}
-
-/**
- * p1022ds_set_sysfs_monitor_port: set the monitor port for sysfs
+ * p1022ds_valid_monitor_port: set the monitor port for sysfs
*/
-int p1022ds_set_sysfs_monitor_port(int val)
+enum fsl_diu_monitor_port
+p1022ds_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return val < 2 ? val : 0;
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
+ case FSL_DIU_PORT_LVDS:
+ return port;
+ default:
+ return FSL_DIU_PORT_DVI; /* Dual-link LVDS is not supported */
+ }
}
#endif
@@ -305,8 +303,7 @@ static void __init p1022_ds_setup_arch(void)
diu_ops.set_gamma_table = p1022ds_set_gamma_table;
diu_ops.set_monitor_port = p1022ds_set_monitor_port;
diu_ops.set_pixel_clock = p1022ds_set_pixel_clock;
- diu_ops.show_monitor_port = p1022ds_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = p1022ds_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = p1022ds_valid_monitor_port;
#endif
#ifdef CONFIG_SMP
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 74e018e..13fa9a6 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -152,10 +152,10 @@ machine_device_initcall(mpc86xx_hpcd, mpc8610_declare_of_platform_devices);
(c2 << AD_COMP_2_SHIFT) | (c1 << AD_COMP_1_SHIFT) | \
(c0 << AD_COMP_0_SHIFT) | (size << AD_PIXEL_S_SHIFT))
-unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc8610hpcd_get_pixel_format(enum fsl_diu_monitor_port port,
+ unsigned int bits_per_pixel)
{
- static const unsigned long pixelformat[][3] = {
+ static const u32 pixelformat[][3] = {
{
MAKE_AD(3, 0, 2, 1, 3, 8, 8, 8, 8),
MAKE_AD(4, 2, 0, 1, 2, 8, 8, 8, 0),
@@ -170,7 +170,8 @@ unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
unsigned int arch_monitor;
/* The DVI port is mis-wired on revision 1 of this board. */
- arch_monitor = ((*pixis_arch = 0x01) && (monitor_port = 0))? 0 : 1;
+ arch_monitor + ((*pixis_arch = 0x01) && (port = FSL_DIU_PORT_DVI)) ? 0 : 1;
switch (bits_per_pixel) {
case 32:
@@ -185,10 +186,11 @@ unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
}
}
-void mpc8610hpcd_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc8610hpcd_set_gamma_table(enum fsl_diu_monitor_port port,
+ char *gamma_table_base)
{
int i;
- if (monitor_port = 2) { /* dual link LVDS */
+ if (port = FSL_DIU_PORT_DLVDS) {
for (i = 0; i < 256*3; i++)
gamma_table_base[i] = (gamma_table_base[i] << 2) |
((gamma_table_base[i] >> 6) & 0x03);
@@ -199,17 +201,21 @@ void mpc8610hpcd_set_gamma_table(int monitor_port, char *gamma_table_base)
#define PX_BRDCFG0_DLINK (1 << 4)
#define PX_BRDCFG0_DIU_MASK (PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK)
-void mpc8610hpcd_set_monitor_port(int monitor_port)
+void mpc8610hpcd_set_monitor_port(enum fsl_diu_monitor_port port)
{
- static const u8 bdcfg[] = {
- PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK,
- PX_BRDCFG0_DLINK,
- 0,
- };
-
- if (monitor_port < 3)
+ switch (port) {
+ case FSL_DIU_PORT_DVI:
clrsetbits_8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK,
- bdcfg[monitor_port]);
+ PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK);
+ break;
+ case FSL_DIU_PORT_LVDS:
+ clrsetbits_8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK,
+ PX_BRDCFG0_DLINK);
+ break;
+ case FSL_DIU_PORT_DLVDS:
+ clrbits8(pixis_bdcfg0, PX_BRDCFG0_DIU_MASK);
+ break;
+ }
}
/**
@@ -262,20 +268,10 @@ void mpc8610hpcd_set_pixel_clock(unsigned int pixclock)
iounmap(guts);
}
-ssize_t mpc8610hpcd_show_monitor_port(int monitor_port, char *buf)
-{
- return snprintf(buf, PAGE_SIZE,
- "%c0 - DVI\n"
- "%c1 - Single link LVDS\n"
- "%c2 - Dual link LVDS\n",
- monitor_port = 0 ? '*' : ' ',
- monitor_port = 1 ? '*' : ' ',
- monitor_port = 2 ? '*' : ' ');
-}
-
-int mpc8610hpcd_set_sysfs_monitor_port(int val)
+enum fsl_diu_monitor_port
+mpc8610hpcd_valid_monitor_port(enum fsl_diu_monitor_port port)
{
- return val < 3 ? val : 0;
+ return port;
}
#endif
@@ -307,8 +303,7 @@ static void __init mpc86xx_hpcd_setup_arch(void)
diu_ops.set_gamma_table = mpc8610hpcd_set_gamma_table;
diu_ops.set_monitor_port = mpc8610hpcd_set_monitor_port;
diu_ops.set_pixel_clock = mpc8610hpcd_set_pixel_clock;
- diu_ops.show_monitor_port = mpc8610hpcd_show_monitor_port;
- diu_ops.set_sysfs_monitor_port = mpc8610hpcd_set_sysfs_monitor_port;
+ diu_ops.valid_monitor_port = mpc8610hpcd_valid_monitor_port;
#endif
pixis_node = of_find_compatible_node(NULL, NULL, "fsl,fpga-pixis");
diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
index 2ece02b..c6d0073 100644
--- a/arch/powerpc/sysdev/fsl_soc.h
+++ b/arch/powerpc/sysdev/fsl_soc.h
@@ -22,15 +22,24 @@ struct device_node;
extern void fsl_rstcr_restart(char *cmd);
#if defined(CONFIG_FB_FSL_DIU) || defined(CONFIG_FB_FSL_DIU_MODULE)
+
+/* The different ports that the DIU can be connected to */
+enum fsl_diu_monitor_port {
+ FSL_DIU_PORT_DVI, /* DVI */
+ FSL_DIU_PORT_LVDS, /* Single-link LVDS */
+ FSL_DIU_PORT_DLVDS /* Dual-link LVDS */
+};
+
struct platform_diu_data_ops {
- unsigned int (*get_pixel_format) (unsigned int bits_per_pixel,
- int monitor_port);
- void (*set_gamma_table) (int monitor_port, char *gamma_table_base);
- void (*set_monitor_port) (int monitor_port);
- void (*set_pixel_clock) (unsigned int pixclock);
- ssize_t (*show_monitor_port) (int monitor_port, char *buf);
- int (*set_sysfs_monitor_port) (int val);
- void (*release_bootmem) (void);
+ u32 (*get_pixel_format)(enum fsl_diu_monitor_port port,
+ unsigned int bpp);
+ void (*set_gamma_table)(enum fsl_diu_monitor_port port,
+ char *gamma_table_base);
+ void (*set_monitor_port)(enum fsl_diu_monitor_port port);
+ void (*set_pixel_clock)(unsigned int pixclock);
+ enum fsl_diu_monitor_port (*valid_monitor_port)
+ (enum fsl_diu_monitor_port port);
+ void (*release_bootmem)(void);
};
extern struct platform_diu_data_ops diu_ops;
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index bedf5be..6762976 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -31,8 +31,6 @@
#include <linux/uaccess.h>
#include <linux/vmalloc.h>
-#include <linux/of_platform.h>
-
#include <sysdev/fsl_soc.h>
#include <linux/fsl-diu-fb.h>
#include "edid.h"
@@ -183,7 +181,8 @@ static struct fb_videomode __devinitdata fsl_diu_mode_db[] = {
static char *fb_mode = "1024x768-32@60";
static unsigned long default_bpp = 32;
-static int monitor_port;
+static enum fsl_diu_monitor_port monitor_port;
+static char *monitor_string;
#if defined(CONFIG_NOT_COHERENT_CACHE)
static u8 *coherence_data;
@@ -201,7 +200,7 @@ struct fsl_diu_data {
void *dummy_aoi_virt;
unsigned int irq;
int fb_enabled;
- int monitor_port;
+ enum fsl_diu_monitor_port monitor_port;
};
struct mfb_info {
@@ -282,6 +281,37 @@ static struct diu_hw dr = {
static struct diu_pool pool;
/**
+ * fsl_diu_name_to_port - convert a port name to a monitor port enum
+ *
+ * Takes the name of a monitor port ("dvi", "lvds", or "dlvds") and returns
+ * the enum fsl_diu_monitor_port that corresponds to that string.
+ *
+ * For compatibility with older versions, a number ("0", "1", or "2") is also
+ * supported.
+ *
+ * If the string is unknown, DVI is assumed.
+ *
+ * If the particular port is not supported by the platform, another port
+ * (platform-specific) is chosen instead.
+ */
+static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
+{
+ enum fsl_diu_monitor_port port = FSL_DIU_PORT_DVI;
+ unsigned long val;
+
+ if (s) {
+ if (!strict_strtoul(s, 10, &val) && (val <= 2))
+ port = (enum fsl_diu_monitor_port) val;
+ else if (strncmp(s, "lvds", 4) = 0)
+ port = FSL_DIU_PORT_LVDS;
+ else if (strncmp(s, "dlvds", 5) = 0)
+ port = FSL_DIU_PORT_DLVDS;
+ }
+
+ return diu_ops.valid_monitor_port(port);
+}
+
+/**
* fsl_diu_alloc - allocate memory for the DIU
* @size: number of bytes to allocate
* @param: returned physical address of memory
@@ -847,9 +877,8 @@ static int fsl_diu_set_par(struct fb_info *info)
}
}
- ad->pix_fmt - diu_ops.get_pixel_format(var->bits_per_pixel,
- machine_data->monitor_port);
+ ad->pix_fmt = diu_ops.get_pixel_format(machine_data->monitor_port,
+ var->bits_per_pixel);
ad->addr = cpu_to_le32(info->fix.smem_start);
ad->src_size_g_alpha = cpu_to_le32((var->yres_virtual << 12) |
var->xres_virtual) | mfbi->g_alpha;
@@ -1455,16 +1484,12 @@ static void free_buf(struct device *dev, struct diu_addr *buf, u32 size,
static ssize_t store_monitor(struct device *device,
struct device_attribute *attr, const char *buf, size_t count)
{
- int old_monitor_port;
- unsigned long val;
+ enum fsl_diu_monitor_port old_monitor_port;
struct fsl_diu_data *machine_data container_of(attr, struct fsl_diu_data, dev_attr);
- if (strict_strtoul(buf, 10, &val))
- return 0;
-
old_monitor_port = machine_data->monitor_port;
- machine_data->monitor_port = diu_ops.set_sysfs_monitor_port(val);
+ machine_data->monitor_port = fsl_diu_name_to_port(buf);
if (old_monitor_port != machine_data->monitor_port) {
/* All AOIs need adjust pixel format
@@ -1484,7 +1509,17 @@ static ssize_t show_monitor(struct device *device,
{
struct fsl_diu_data *machine_data container_of(attr, struct fsl_diu_data, dev_attr);
- return diu_ops.show_monitor_port(machine_data->monitor_port, buf);
+
+ switch (machine_data->monitor_port) {
+ case FSL_DIU_PORT_DVI:
+ return sprintf(buf, "DVI\n");
+ case FSL_DIU_PORT_LVDS:
+ return sprintf(buf, "Single-link LVDS\n");
+ case FSL_DIU_PORT_DLVDS:
+ return sprintf(buf, "Dual-link LVDS\n");
+ }
+
+ return 0;
}
static int __devinit fsl_diu_probe(struct platform_device *ofdev)
@@ -1708,8 +1743,7 @@ static int __init fsl_diu_setup(char *options)
if (!*opt)
continue;
if (!strncmp(opt, "monitor=", 8)) {
- if (!strict_strtoul(opt + 8, 10, &val) && (val <= 2))
- monitor_port = val;
+ monitor_port = fsl_diu_name_to_port(opt + 8);
} else if (!strncmp(opt, "bpp=", 4)) {
if (!strict_strtoul(opt + 4, 10, &val))
default_bpp = val;
@@ -1762,6 +1796,8 @@ static int __init fsl_diu_init(void)
if (fb_get_options("fslfb", &option))
return -ENODEV;
fsl_diu_setup(option);
+#else
+ monitor_port = fsl_diu_name_to_port(monitor_string);
#endif
printk(KERN_INFO "Freescale DIU driver\n");
@@ -1828,7 +1864,7 @@ MODULE_PARM_DESC(mode,
"Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\" ");
module_param_named(bpp, default_bpp, ulong, 0);
MODULE_PARM_DESC(bpp, "Specify bit-per-pixel if not specified mode");
-module_param_named(monitor, monitor_port, int, 0);
-MODULE_PARM_DESC(monitor,
- "Specify the monitor port (0, 1 or 2) if supported by the platform");
+module_param_named(monitor, monitor_string, charp, 0);
+MODULE_PARM_DESC(monitor, "Specify the monitor port "
+ "(\"dvi\", \"lvds\", or \"dlvds\") if supported by the platform");
--
1.7.4.4
^ permalink raw reply related
* [PATCH] drivers/video/udlfb match class, subclass, and protocol
From: bernie @ 2011-07-10 7:30 UTC (permalink / raw)
To: linux-fbdev
From: Bernie Thompson <bernie@plugable.com>
Match udlfb only against vendor-specific class (e.g. only DisplayLink
graphics, not composite standard audio class interfaces). This enables
compatibility with composite graphics+audio devices (e.g. HDMI).
Match udlfb only against compatible subclass 0 and protocol 0 chips.
DisplayLink's USB 3.0 generation chips increment these values
to signal that they have a incompatible protocol, preventing udlfb
from erroneously matching to hardware it does not support.
Tested to confirm proper behavior on both USB 2.0 and USB 3.0
generation devices.
Reported-by: Andrew Kephart <akephart@akephart.org>
Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
drivers/video/udlfb.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index c6584c9..4e13375 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -49,13 +49,22 @@ static const u32 udlfb_info_flags = FBINFO_DEFAULT | FBINFO_READS_FAST |
FBINFO_HWACCEL_COPYAREA | FBINFO_MISC_ALWAYS_SETPAR;
/*
- * There are many DisplayLink-based products, all with unique PIDs. We are able
- * to support all volume ones (circa 2009) with a single driver, so we match
- * globally on VID. TODO: Probe() needs to detect when we might be running
- * "future" chips, and bail on those, so a compatible driver can match.
+ * There are many DisplayLink-based graphics products, all with unique PIDs.
+ * So we match on DisplayLink's VID + Vendor-Defined Interface Class (0xff)
+ * We also require a match on SubClass (0x00) and Protocol (0x00),
+ * which is compatible with all known USB 2.0 era graphics chips and firmware,
+ * but allows DisplayLink to increment those for any future incompatible chips
*/
static struct usb_device_id id_table[] = {
- {.idVendor = 0x17e9, .match_flags = USB_DEVICE_ID_MATCH_VENDOR,},
+ {.idVendor = 0x17e9,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0x00,
+ .bInterfaceProtocol = 0x00,
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR |
+ USB_DEVICE_ID_MATCH_INT_CLASS |
+ USB_DEVICE_ID_MATCH_INT_SUBCLASS |
+ USB_DEVICE_ID_MATCH_INT_PROTOCOL,
+ },
{},
};
MODULE_DEVICE_TABLE(usb, id_table);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] drivers/video/udlfb bind framebuffer to interface.
From: JinGoo Han @ 2011-07-11 4:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309910651-3483-1-git-send-email-bernie@plugable.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1840 bytes --]
Hi, Bernie Thompson.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of bernie@plugable.com
> Sent: Wednesday, July 06, 2011 9:04 AM
> To: linux-fbdev@vger.kernel.org
> Cc: lethal@linux-sh.org; Kay Sievers; Bernie Thompson
> Subject: [PATCH] drivers/video/udlfb bind framebuffer to interface.
>
> From: Kay Sievers <kay.sievers@vrfy.org>
>
> Udlfb has been binding the framebuffer device to its parent, which
> isn't correct and causes confusion with operations like udev remove.
>
> Coming plug and play multiseat support is dependent on this fix.
>
> Signed-off-by: Bernie Thompson <bernie@plugable.com>
This patch author seems to be Kay Sievers <kay.sievers@vrfy.org>.
Should you add Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> ?
> ---
> drivers/video/udlfb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index 816a4fd..c6584c9 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1549,7 +1549,7 @@ static int dlfb_usb_probe(struct usb_interface
> *interface,
> /* We don't register a new USB class. Our client interface is fbdev
> */
>
> /* allocates framebuffer driver structure, not framebuffer memory
> */
> - info = framebuffer_alloc(0, &usbdev->dev);
> + info = framebuffer_alloc(0, &interface->dev);
> if (!info) {
> retval = -ENOMEM;
> pr_err("framebuffer_alloc failed\n");
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH 0/5 v4] LCDC MERAM runtime PM support
From: Paul Mundt @ 2011-07-11 5:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309766728-32419-1-git-send-email-dhobsong@igel.co.jp>
On Mon, Jul 04, 2011 at 05:05:28PM +0900, Damian Hobson-Garcia wrote:
> This patch series is a provides PM runtime support for the LCDC MERAM.
>
> The runtime_pm_get/put calls are made at the same time as the LCDC calls, so
> that the LCDC MERAM is enabled with the first LCDC device and disabled
> with the last LCDC device.
>
> The first 4 patches will apply to rmobile-latest or common/fbdev-meram as-is,
> but the final patch needs to have the "PM / Domains: Support for generic I/O PM
> domains" patch series.
>
> Only the first 2 patches of the series have been updated from v3 sent on
> 2011/06/22
>
> Changes from V3
>
> * Remove the MERAM callbacks used to runtime_get/runtime_put the device from
> the LCDC driver. Instead, just call the functions on the MERAM device
> directly
>
> Damian Hobson-Garcia (5):
> fbdev: sh_mobile_meram: Enable runtime PM
> fbdev: sh_mobile_meram: Enable/disable MERAM along with LCDC - v4
> fbdev: sh_mobile_meram: Move private data from .h to .c
> fbdev: sh_mobile_meram: Backup/restore device registers on
> shutdown/resume - v3
> fbdev: sh_mobile_meram: Assign meram to the SH7372_A4LC power domain
>
I've applied 1-4, and will roll in the last one once the power domain
stuff hits mainline.
^ permalink raw reply
* Re: [PATCH 0/5 v4] LCDC MERAM runtime PM support
From: Paul Mundt @ 2011-07-11 5:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1309766728-32419-1-git-send-email-dhobsong@igel.co.jp>
On Mon, Jul 11, 2011 at 02:36:42PM +0900, Paul Mundt wrote:
> On Mon, Jul 04, 2011 at 05:05:28PM +0900, Damian Hobson-Garcia wrote:
> > This patch series is a provides PM runtime support for the LCDC MERAM.
> >
> > The runtime_pm_get/put calls are made at the same time as the LCDC calls, so
> > that the LCDC MERAM is enabled with the first LCDC device and disabled
> > with the last LCDC device.
> >
> > The first 4 patches will apply to rmobile-latest or common/fbdev-meram as-is,
> > but the final patch needs to have the "PM / Domains: Support for generic I/O PM
> > domains" patch series.
> >
> > Only the first 2 patches of the series have been updated from v3 sent on
> > 2011/06/22
> >
> > Changes from V3
> >
> > * Remove the MERAM callbacks used to runtime_get/runtime_put the device from
> > the LCDC driver. Instead, just call the functions on the MERAM device
> > directly
> >
> > Damian Hobson-Garcia (5):
> > fbdev: sh_mobile_meram: Enable runtime PM
> > fbdev: sh_mobile_meram: Enable/disable MERAM along with LCDC - v4
> > fbdev: sh_mobile_meram: Move private data from .h to .c
> > fbdev: sh_mobile_meram: Backup/restore device registers on
> > shutdown/resume - v3
> > fbdev: sh_mobile_meram: Assign meram to the SH7372_A4LC power domain
> >
> I've applied 1-4, and will roll in the last one once the power domain
> stuff hits mainline.
Magnus informs me that there is still some testing going on with this
series and that there may be future updates. I've queued up the changes
in the common/fbdev-meram topic branch but will hold off on pulling that
in to the fbdev tree until everyone involved is happy with it.
^ permalink raw reply
* [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
From: Laurent Pinchart @ 2011-07-11 12:35 UTC (permalink / raw)
To: linux-fbdev
Resuming from runtime PM restores all LCDC registers. If the dot clock
is off at that time display panning information will be corrupted.
Turn the dot clock on before resuming from runtime PM. Similarly,
turn the clock off after suspending the LCDC.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
drivers/video/sh_mobile_lcdcfb.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
This patch should fix the LCDC panning issue caused by runtime suspend. It
applies on top of Rafael J. Wysocki's pm-domains branch and Damian
Hobson-Garcia's MERAM patches.
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 48a40e3..e9b80bc 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -256,9 +256,9 @@ struct sh_mobile_lcdc_sys_bus_ops sh_mobile_lcdc_sys_bus_ops = {
static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
{
if (atomic_inc_and_test(&priv->hw_usecnt)) {
- pm_runtime_get_sync(priv->dev);
if (priv->dot_clk)
clk_enable(priv->dot_clk);
+ pm_runtime_get_sync(priv->dev);
if (priv->meram_dev && priv->meram_dev->pdev)
pm_runtime_get_sync(&priv->meram_dev->pdev->dev);
}
@@ -267,11 +267,11 @@ static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
static void sh_mobile_lcdc_clk_off(struct sh_mobile_lcdc_priv *priv)
{
if (atomic_sub_return(1, &priv->hw_usecnt) = -1) {
- if (priv->dot_clk)
- clk_disable(priv->dot_clk);
if (priv->meram_dev && priv->meram_dev->pdev)
pm_runtime_put_sync(&priv->meram_dev->pdev->dev);
pm_runtime_put(priv->dev);
+ if (priv->dot_clk)
+ clk_disable(priv->dot_clk);
}
}
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-07-11 15:32 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Geert Uytterhoeven, Paul Mundt, linux-fbdev, linux-media,
dri-devel
In-Reply-To: <4E04E975.2060003@gmx.de>
On Friday 24 June 2011 21:45:57 Florian Tobias Schandinat wrote:
> On 06/24/2011 06:55 PM, Geert Uytterhoeven wrote:
> > On Fri, Jun 24, 2011 at 08:19, Paul Mundt wrote:
> >> On Thu, Jun 23, 2011 at 06:08:03PM +0200, Geert Uytterhoeven wrote:
> >>> On Wed, Jun 22, 2011 at 07:45, Florian Tobias Schandinat wrote:
> >>>> On 06/21/2011 10:31 PM, Laurent Pinchart wrote:
> >>>>> On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote:
> >>>>>> As FOURCC values are always 4 ASCII characters (hence all 4 bytes
> >>>>>> must be non-zero), I don't think there are any conflicts with
> >>>>>> existing values of
> >>>>>> nonstd. To make it even safer and easier to parse, you could set bit
> >>>>>> 31 of
> >>>>>> nonstd as a FOURCC indicator.
> >>>>>
> >>>>> I would then create a union between nonstd and fourcc, and document
> >>>>> nonstd as
> >>>>> being used for the legacy API only. Most existing drivers use a
> >>>>> couple of nonstd bits only. The driver that (ab)uses nonstd the most
> >>>>> is pxafb and uses
> >>>>> bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd&
> >>>>> 0xff000000 != 0 could be used as a FOURCC mode test.
> >>>>>
> >>>>> This assumes that FOURCCs will never have their last character set to
> >>>>> '\0'. Is
> >>>>> that a safe assumption for the future ?
> >>>>
> >>>> Yes, I think. The information I found indicates that space should be
> >>>> used for padding, so a \0 shouldn't exist.
> >>>> I think using only the nonstd field and requiring applications to
> >>>> check the capabilities would be possible, although not fool proof ;)
> >>>
> >>> So we can declare the 8 msb bits of nonstd reserved, and assume FOURCC
> >>> if any of them is set.
> >>>
> >>> Nicely backwards compatible, as sane drivers should reject nonstd
> >>> values they don't support (apps _will_ start filling in FOURCC values
> >>> ignoring capabilities, won't they?).
> >>
> >> That seems like a reasonable case, but if we're going to do that then
> >> certainly the nonstd bit encoding needs to be documented and treated as
> >> a hard ABI.
> >>
> >> I'm not so sure about the if any bit in the upper byte is set assume
> >> FOURCC case though, there will presumably be other users in the future
> >> that will want bits for themselves, too. What exactly was the issue with
> >> having a FOURCC capability bit in the upper byte?
> >
> > That indeed gives less issues (as long as you don't stuff 8-bit ASCII
> > in the MSB) and more bits for tradiditional nonstd users.
>
> The only disadvantage I can see is that it requires adding this bit in the
> application and stripping it when interpreting it. But I think the 24 lower
> bits should be enough for driver specific behavior (as the current values
> really can only be interpreted per driver).
I'm also not keen on adding/stripping the MSB. It would be easier for
applications to use FOURCCs directly.
> > BTW, after giving it some more thought: what does the FB_CAP_FOURCC buys
> > us? It's not like all drivers will support whatever random FOURCC mode
> > you give them, so you have to check whether it's supported by doing a
> > set_var first.
>
> Because any solution purely based on the nonstd field is insane. The abuse
> of that field is just too widespread. Drivers that use nonstd usually only
> check whether it is zero or nonzero and others will just interpret parts
> of nonstd and ignore the rest. They will happily accept FOURCC values in
> the nonstd and just doing the wrong thing. Even if we would fix those the
> problems applications will run into with older kernels will remain.
I agree with Florian here. Many drivers currently check whether nonstd != 0.
Who knows what kind of values applications feed them ?
I'd like to reach an agreement on the API, and implement it. I'm fine with
either grayscale or nonstd to store the FOURCC (with a slight preference for
grayscale), and with either a vmode flag or using the most significant byte of
the grayscale/nonstd field to detect FOURCC mode. I believe FB_CAP_FOURCC (or
something similar) is needed.
--
Regards,
Laurent Pinchart
^ 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