* [PATCH v3 0/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-31 11:18 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-media, magnus.damm
Hi everybody,
Here's the third version of the fbdev FOURCC-based format configuration API.
Compared to the previous version, I've added an FB_TYPE_FOURCC in addition to
FB_VISUAL_FOURCC, fixed the documentation (thanks to Geert for reviewing it
and explaining how fbdev bitplanes work) and fixed bugs in the sh_mobile_lcdc
YUV support.
The sb_mobile_lcdc patch applies on top of the latest patches that I've sent
to the list. You can find a consolidated version that includes this patch set
at http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/fbdev-yuv.
I've updated the fbdev-test tool to add FOURCC support. The code is available
in the fbdev-test yuv branch at
http://git.ideasonboard.org/?pûdev-test.git;a=shortlog;h=refs/heads/yuv.
Laurent Pinchart (3):
fbdev: Add FOURCC-based format configuration API
v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 ++++++++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
Documentation/fb/api.txt | 317 ++++++++++++++++++++
arch/arm/mach-shmobile/board-ag5evm.c | 2 +-
arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 4 +-
arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
arch/sh/boards/mach-ecovec24/setup.c | 2 +-
arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
arch/sh/boards/mach-migor/setup.c | 4 +-
arch/sh/boards/mach-se/7724/setup.c | 2 +-
drivers/video/sh_mobile_lcdcfb.c | 362 +++++++++++++++--------
include/linux/fb.h | 28 ++-
include/linux/videodev2.h | 2 +
include/video/sh_mobile_lcdc.h | 4 +-
15 files changed, 726 insertions(+), 139 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
create mode 100644 Documentation/fb/api.txt
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PULL] SH mobile LCDC cleanups and fixes
From: Laurent Pinchart @ 2011-08-31 11:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201108191044.52130.laurent.pinchart@ideasonboard.com>
Hi Florian,
On Tuesday 30 August 2011 22:41:39 Florian Tobias Schandinat wrote:
> On 08/19/2011 08:44 AM, Laurent Pinchart wrote:
> > Hi Florian,
> >
> > Here are the latest SH mobile LCDC and MERAM cleanups and fixes based on
> > top of v3.1-rc2. All the patches have been posted to the list. I've
> > incorporated acked-by and tested-by lines when available, but most of
> > the patches received no comment.
> >
> > The following changes since commit
93ee7a9340d64f20295aacc3fb6a22b759323280:
> > Linux 3.1-rc2 (2011-08-14 15:09:08 -0700)
> >
> > are available in the git repository at:
> > git://linuxtv.org/pinchartl/fbdev.git sh-mobile-lcdc
>
> Pulled, thanks.
Thanks you.
Do you plan to pull the "sh_mobile_lcdc: Support format changes at runtime"
patch set as well ? I've just submitted a v2 that includes an additional patch
to fix a MERAM issue.
> It looks good to me, as far as I can tell.
> Just the first commits that were not your own ones should have had more
> verbose commit messages and I think they should have had your Signed-off
> as you received them via e-mail?
I've just picked them from the list, as I needed them to build the other
patches.
> And on another note:
> Would you mind adding yourself as maintainer of drivers/video/sh_mobile_*
> in MAINTAINERS? I can't find any entry for it yet and having me as primary
> source for review for a driver I don't know is a bad idea, at least if
> there are people that know it better.
I don't know the driver *that* well :-) I'm not sure how long I will work on
that driver, so maybe it would be a better idea to list Magnus as the
maintainer. Magnus, what's your opinion ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 8/8] fbdev: sh_mobile_lcdc: Remove sh_mobile_lcdc_set_bpp()
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
The function duplicates code found in sh_mobile_check_var(). Remove
sh_mobile_lcdc_set_bpp() and call sh_mobile_check_var() instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 87 +++++++------------------------------
1 files changed, 17 insertions(+), 70 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index d1576e2..97ab8ba 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1291,66 +1291,6 @@ static void sh_mobile_lcdc_bl_remove(struct backlight_device *bdev)
backlight_device_unregister(bdev);
}
-static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp,
- int nonstd)
-{
- if (nonstd) {
- switch (bpp) {
- case 12:
- case 16:
- case 24:
- var->bits_per_pixel = bpp;
- var->nonstd = nonstd;
- return 0;
- default:
- return -EINVAL;
- }
- }
-
- switch (bpp) {
- case 16: /* PKF[4:0] = 00011 - RGB 565 */
- var->red.offset = 11;
- var->red.length = 5;
- var->green.offset = 5;
- var->green.length = 6;
- var->blue.offset = 0;
- var->blue.length = 5;
- var->transp.offset = 0;
- var->transp.length = 0;
- break;
-
- case 24: /* PKF[4:0] = 01011 - RGB 888 */
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 0;
- var->transp.length = 0;
- break;
-
- case 32: /* PKF[4:0] = 00000 - RGBA 888 */
- var->red.offset = 16;
- var->red.length = 8;
- var->green.offset = 8;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 24;
- var->transp.length = 8;
- break;
- default:
- return -EINVAL;
- }
- var->bits_per_pixel = bpp;
- var->red.msb_right = 0;
- var->green.msb_right = 0;
- var->blue.msb_right = 0;
- var->transp.msb_right = 0;
- return 0;
-}
-
static int sh_mobile_lcdc_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1499,6 +1439,9 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
int ret;
int i;
+ mutex_init(&ch->open_lock);
+
+ /* Allocate the frame buffer device. */
ch->info = framebuffer_alloc(0, dev);
if (!ch->info) {
dev_err(dev, "unable to allocate fb_info\n");
@@ -1506,11 +1449,10 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
}
info = ch->info;
- var = &info->var;
info->fbops = &sh_mobile_lcdc_ops;
info->par = ch;
-
- mutex_init(&ch->open_lock);
+ info->pseudo_palette = &ch->pseudo_palette;
+ info->flags = FBINFO_FLAG_DEFAULT;
/* Iterate through the modes to validate them and find the highest
* resolution.
@@ -1541,13 +1483,15 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
dev_dbg(dev, "Found largest videomode %ux%u\n",
max_mode->xres, max_mode->yres);
+ /* Initialize fixed screen information. Restrict pan to 2 lines steps
+ * for NV12.
+ */
info->fix = sh_mobile_lcdc_fix;
info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
-
- /* Only pan in 2 line steps for NV12 */
if (cfg->nonstd && cfg->bpp = 12)
info->fix.ypanstep = 2;
+ /* Create the mode list. */
if (cfg->lcd_cfg = NULL) {
mode = &default_720p;
num_cfg = 1;
@@ -1558,17 +1502,23 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
fb_videomode_to_modelist(mode, num_cfg, &info->modelist);
+ /* Initialize variable screen information using the first mode as
+ * default. The default Y virtual resolution is twice the panel size to
+ * allow for double-buffering.
+ */
+ var = &info->var;
fb_videomode_to_var(var, mode);
+ var->bits_per_pixel = cfg->bpp;
var->width = cfg->lcd_size_cfg.width;
var->height = cfg->lcd_size_cfg.height;
- /* Default Y virtual resolution is 2x panel size */
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
- ret = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
+ ret = sh_mobile_check_var(var, info);
if (ret)
return ret;
+ /* Allocate frame buffer memory and color map. */
buf = dma_alloc_coherent(dev, info->fix.smem_len, &ch->dma_handle,
GFP_KERNEL);
if (!buf) {
@@ -1576,9 +1526,6 @@ static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
return -ENOMEM;
}
- info->pseudo_palette = &ch->pseudo_palette;
- info->flags = FBINFO_FLAG_DEFAULT;
-
ret = fb_alloc_cmap(&info->cmap, PALETTE_NR, 0);
if (ret < 0) {
dev_err(dev, "unable to allocate cmap\n");
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 7/8] fbdev: sh_mobile_lcdc: Split channel initialization from probe function
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Move channel initialization to sh_mobile_lcdc_channel_init() and call
the function from sh_mobile_lcdc_probe(). This makes the code more
readable and prepares it for fix/var initialization rework.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 247 ++++++++++++++++++++------------------
1 files changed, 129 insertions(+), 118 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 366315b..d1576e2 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1485,15 +1485,129 @@ static int sh_mobile_lcdc_remove(struct platform_device *pdev)
return 0;
}
-static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
+static int __devinit sh_mobile_lcdc_channel_init(struct sh_mobile_lcdc_chan *ch,
+ struct device *dev)
{
+ struct sh_mobile_lcdc_chan_cfg *cfg = &ch->cfg;
+ const struct fb_videomode *max_mode;
+ const struct fb_videomode *mode;
+ struct fb_var_screeninfo *var;
struct fb_info *info;
- struct sh_mobile_lcdc_priv *priv;
+ unsigned int max_size;
+ int num_cfg;
+ void *buf;
+ int ret;
+ int i;
+
+ ch->info = framebuffer_alloc(0, dev);
+ if (!ch->info) {
+ dev_err(dev, "unable to allocate fb_info\n");
+ return -ENOMEM;
+ }
+
+ info = ch->info;
+ var = &info->var;
+ info->fbops = &sh_mobile_lcdc_ops;
+ info->par = ch;
+
+ mutex_init(&ch->open_lock);
+
+ /* Iterate through the modes to validate them and find the highest
+ * resolution.
+ */
+ max_mode = NULL;
+ max_size = 0;
+
+ for (i = 0, mode = cfg->lcd_cfg; i < cfg->num_cfg; i++, mode++) {
+ unsigned int size = mode->yres * mode->xres;
+
+ /* NV12 buffers must have even number of lines */
+ if ((cfg->nonstd) && cfg->bpp = 12 &&
+ (mode->yres & 0x1)) {
+ dev_err(dev, "yres must be multiple of 2 for YCbCr420 "
+ "mode.\n");
+ return -EINVAL;
+ }
+
+ if (size > max_size) {
+ max_mode = mode;
+ max_size = size;
+ }
+ }
+
+ if (!max_size)
+ max_size = MAX_XRES * MAX_YRES;
+ else
+ dev_dbg(dev, "Found largest videomode %ux%u\n",
+ max_mode->xres, max_mode->yres);
+
+ info->fix = sh_mobile_lcdc_fix;
+ info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
+
+ /* Only pan in 2 line steps for NV12 */
+ if (cfg->nonstd && cfg->bpp = 12)
+ info->fix.ypanstep = 2;
+
+ if (cfg->lcd_cfg = NULL) {
+ mode = &default_720p;
+ num_cfg = 1;
+ } else {
+ mode = cfg->lcd_cfg;
+ num_cfg = cfg->num_cfg;
+ }
+
+ fb_videomode_to_modelist(mode, num_cfg, &info->modelist);
+
+ fb_videomode_to_var(var, mode);
+ var->width = cfg->lcd_size_cfg.width;
+ var->height = cfg->lcd_size_cfg.height;
+ /* Default Y virtual resolution is 2x panel size */
+ var->yres_virtual = var->yres * 2;
+ var->activate = FB_ACTIVATE_NOW;
+
+ ret = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
+ if (ret)
+ return ret;
+
+ buf = dma_alloc_coherent(dev, info->fix.smem_len, &ch->dma_handle,
+ GFP_KERNEL);
+ if (!buf) {
+ dev_err(dev, "unable to allocate buffer\n");
+ return -ENOMEM;
+ }
+
+ info->pseudo_palette = &ch->pseudo_palette;
+ info->flags = FBINFO_FLAG_DEFAULT;
+
+ ret = fb_alloc_cmap(&info->cmap, PALETTE_NR, 0);
+ if (ret < 0) {
+ dev_err(dev, "unable to allocate cmap\n");
+ dma_free_coherent(dev, info->fix.smem_len,
+ buf, ch->dma_handle);
+ return ret;
+ }
+
+ info->fix.smem_start = ch->dma_handle;
+ if (var->nonstd)
+ info->fix.line_length = var->xres;
+ else
+ info->fix.line_length = var->xres * (cfg->bpp / 8);
+
+ info->screen_base = buf;
+ info->device = dev;
+ ch->display_var = *var;
+
+ return 0;
+}
+
+static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
+{
struct sh_mobile_lcdc_info *pdata = pdev->dev.platform_data;
+ struct sh_mobile_lcdc_priv *priv;
struct resource *res;
+ int num_channels;
int error;
- void *buf;
- int i, j;
+ int i;
if (!pdata) {
dev_err(&pdev->dev, "no platform data defined\n");
@@ -1525,9 +1639,8 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
priv->irq = i;
atomic_set(&priv->hw_usecnt, -1);
- j = 0;
- for (i = 0; i < ARRAY_SIZE(pdata->ch); i++) {
- struct sh_mobile_lcdc_chan *ch = priv->ch + j;
+ for (i = 0, num_channels = 0; i < ARRAY_SIZE(pdata->ch); i++) {
+ struct sh_mobile_lcdc_chan *ch = priv->ch + num_channels;
ch->lcdc = priv;
memcpy(&ch->cfg, &pdata->ch[i], sizeof(pdata->ch[i]));
@@ -1549,24 +1662,24 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
case LCDC_CHAN_MAINLCD:
ch->enabled = LDCNT2R_ME;
ch->reg_offs = lcdc_offs_mainlcd;
- j++;
+ num_channels++;
break;
case LCDC_CHAN_SUBLCD:
ch->enabled = LDCNT2R_SE;
ch->reg_offs = lcdc_offs_sublcd;
- j++;
+ num_channels++;
break;
}
}
- if (!j) {
+ if (!num_channels) {
dev_err(&pdev->dev, "no channels defined\n");
error = -EINVAL;
goto err1;
}
/* for dual channel LCDC (MAIN + SUB) force shared bpp setting */
- if (j = 2)
+ if (num_channels = 2)
priv->forced_bpp = pdata->ch[0].bpp;
priv->base = ioremap_nocache(res->start, resource_size(res));
@@ -1581,125 +1694,23 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
priv->meram_dev = pdata->meram_dev;
- for (i = 0; i < j; i++) {
- struct fb_var_screeninfo *var;
- const struct fb_videomode *lcd_cfg, *max_cfg = NULL;
+ for (i = 0; i < num_channels; i++) {
struct sh_mobile_lcdc_chan *ch = priv->ch + i;
- struct sh_mobile_lcdc_chan_cfg *cfg = &ch->cfg;
- const struct fb_videomode *mode = cfg->lcd_cfg;
- unsigned long max_size = 0;
- int k;
- int num_cfg;
-
- ch->info = framebuffer_alloc(0, &pdev->dev);
- if (!ch->info) {
- dev_err(&pdev->dev, "unable to allocate fb_info\n");
- error = -ENOMEM;
- break;
- }
-
- info = ch->info;
- var = &info->var;
- info->fbops = &sh_mobile_lcdc_ops;
- info->par = ch;
-
- mutex_init(&ch->open_lock);
-
- for (k = 0, lcd_cfg = mode;
- k < cfg->num_cfg && lcd_cfg;
- k++, lcd_cfg++) {
- unsigned long size = lcd_cfg->yres * lcd_cfg->xres;
- /* NV12 buffers must have even number of lines */
- if ((cfg->nonstd) && cfg->bpp = 12 &&
- (lcd_cfg->yres & 0x1)) {
- dev_err(&pdev->dev, "yres must be multiple of 2"
- " for YCbCr420 mode.\n");
- error = -EINVAL;
- goto err1;
- }
-
- if (size > max_size) {
- max_cfg = lcd_cfg;
- max_size = size;
- }
- }
-
- if (!mode)
- max_size = MAX_XRES * MAX_YRES;
- else if (max_cfg)
- dev_dbg(&pdev->dev, "Found largest videomode %ux%u\n",
- max_cfg->xres, max_cfg->yres);
-
- info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
-
- /* Only pan in 2 line steps for NV12 */
- if (cfg->nonstd && cfg->bpp = 12)
- info->fix.ypanstep = 2;
-
- if (!mode) {
- mode = &default_720p;
- num_cfg = 1;
- } else {
- num_cfg = cfg->num_cfg;
- }
-
- fb_videomode_to_modelist(mode, num_cfg, &info->modelist);
- fb_videomode_to_var(var, mode);
- var->width = cfg->lcd_size_cfg.width;
- var->height = cfg->lcd_size_cfg.height;
- /* Default Y virtual resolution is 2x panel size */
- var->yres_virtual = var->yres * 2;
- var->activate = FB_ACTIVATE_NOW;
-
- error = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
+ error = sh_mobile_lcdc_channel_init(ch, &pdev->dev);
if (error)
- break;
-
- buf = dma_alloc_coherent(&pdev->dev, info->fix.smem_len,
- &ch->dma_handle, GFP_KERNEL);
- if (!buf) {
- dev_err(&pdev->dev, "unable to allocate buffer\n");
- error = -ENOMEM;
- break;
- }
-
- info->pseudo_palette = &ch->pseudo_palette;
- info->flags = FBINFO_FLAG_DEFAULT;
-
- error = fb_alloc_cmap(&info->cmap, PALETTE_NR, 0);
- if (error < 0) {
- dev_err(&pdev->dev, "unable to allocate cmap\n");
- dma_free_coherent(&pdev->dev, info->fix.smem_len,
- buf, ch->dma_handle);
- break;
- }
-
- info->fix.smem_start = ch->dma_handle;
- if (var->nonstd)
- info->fix.line_length = var->xres;
- else
- info->fix.line_length = var->xres * (cfg->bpp / 8);
-
- info->screen_base = buf;
- info->device = &pdev->dev;
- ch->display_var = *var;
+ goto err1;
}
- if (error)
- goto err1;
-
error = sh_mobile_lcdc_start(priv);
if (error) {
dev_err(&pdev->dev, "unable to start hardware\n");
goto err1;
}
- for (i = 0; i < j; i++) {
+ for (i = 0; i < num_channels; i++) {
struct sh_mobile_lcdc_chan *ch = priv->ch + i;
-
- info = ch->info;
+ struct fb_info *info = ch->info;
if (info->fbdefio) {
ch->sglist = vmalloc(sizeof(struct scatterlist) *
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 6/8] fbdev: sh_mobile_lcdc: Avoid forward declarations
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Reorder probe/remove functions to avoid forward declarations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 102 ++++++++++++++++++-------------------
1 files changed, 50 insertions(+), 52 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index b6da1d6..366315b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1434,7 +1434,56 @@ static int sh_mobile_lcdc_notify(struct notifier_block *nb,
return NOTIFY_OK;
}
-static int sh_mobile_lcdc_remove(struct platform_device *pdev);
+static int sh_mobile_lcdc_remove(struct platform_device *pdev)
+{
+ struct sh_mobile_lcdc_priv *priv = platform_get_drvdata(pdev);
+ struct fb_info *info;
+ int i;
+
+ fb_unregister_client(&priv->notifier);
+
+ for (i = 0; i < ARRAY_SIZE(priv->ch); i++)
+ if (priv->ch[i].info && priv->ch[i].info->dev)
+ unregister_framebuffer(priv->ch[i].info);
+
+ sh_mobile_lcdc_stop(priv);
+
+ for (i = 0; i < ARRAY_SIZE(priv->ch); i++) {
+ info = priv->ch[i].info;
+
+ if (!info || !info->device)
+ continue;
+
+ if (priv->ch[i].sglist)
+ vfree(priv->ch[i].sglist);
+
+ if (info->screen_base)
+ dma_free_coherent(&pdev->dev, info->fix.smem_len,
+ info->screen_base,
+ priv->ch[i].dma_handle);
+ fb_dealloc_cmap(&info->cmap);
+ framebuffer_release(info);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(priv->ch); i++) {
+ if (priv->ch[i].bl)
+ sh_mobile_lcdc_bl_remove(priv->ch[i].bl);
+ }
+
+ if (priv->dot_clk)
+ clk_put(priv->dot_clk);
+
+ if (priv->dev)
+ pm_runtime_disable(priv->dev);
+
+ if (priv->base)
+ iounmap(priv->base);
+
+ if (priv->irq)
+ free_irq(priv->irq, priv);
+ kfree(priv);
+ return 0;
+}
static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
{
@@ -1691,57 +1740,6 @@ err1:
return error;
}
-static int sh_mobile_lcdc_remove(struct platform_device *pdev)
-{
- struct sh_mobile_lcdc_priv *priv = platform_get_drvdata(pdev);
- struct fb_info *info;
- int i;
-
- fb_unregister_client(&priv->notifier);
-
- for (i = 0; i < ARRAY_SIZE(priv->ch); i++)
- if (priv->ch[i].info && priv->ch[i].info->dev)
- unregister_framebuffer(priv->ch[i].info);
-
- sh_mobile_lcdc_stop(priv);
-
- for (i = 0; i < ARRAY_SIZE(priv->ch); i++) {
- info = priv->ch[i].info;
-
- if (!info || !info->device)
- continue;
-
- if (priv->ch[i].sglist)
- vfree(priv->ch[i].sglist);
-
- if (info->screen_base)
- dma_free_coherent(&pdev->dev, info->fix.smem_len,
- info->screen_base,
- priv->ch[i].dma_handle);
- fb_dealloc_cmap(&info->cmap);
- framebuffer_release(info);
- }
-
- for (i = 0; i < ARRAY_SIZE(priv->ch); i++) {
- if (priv->ch[i].bl)
- sh_mobile_lcdc_bl_remove(priv->ch[i].bl);
- }
-
- if (priv->dot_clk)
- clk_put(priv->dot_clk);
-
- if (priv->dev)
- pm_runtime_disable(priv->dev);
-
- if (priv->base)
- iounmap(priv->base);
-
- if (priv->irq)
- free_irq(priv->irq, priv);
- kfree(priv);
- return 0;
-}
-
static struct platform_driver sh_mobile_lcdc_driver = {
.driver = {
.name = "sh_mobile_lcdc_fb",
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 5/8] fbdev: sh_mobile_lcdc: Update fix.line_length in .fb_set_par()
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Instead of updating the fixed screen information line length manually
after calling fb_set_var() in sh_mobile_fb_reconfig(), update the field
in the .fb_set_par() operation handler.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 1ff215c..b6da1d6 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -998,11 +998,6 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
- if (info->var.nonstd)
- info->fix.line_length = mode1.xres;
- else
- info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
-
/*
* fb_set_var() calls the notifier change internally, only if
* FBINFO_MISC_USEREVENT flag is set. Since we do not want to fake a
@@ -1157,12 +1152,22 @@ static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *in
static int sh_mobile_set_par(struct fb_info *info)
{
struct sh_mobile_lcdc_chan *ch = info->par;
+ u32 line_length = info->fix.line_length;
int ret;
sh_mobile_lcdc_stop(ch->lcdc);
+
+ if (info->var.nonstd)
+ info->fix.line_length = info->var.xres;
+ else
+ info->fix.line_length = info->var.xres
+ * info->var.bits_per_pixel / 8;
+
ret = sh_mobile_lcdc_start(ch->lcdc);
- if (ret < 0)
+ if (ret < 0) {
dev_err(info->dev, "%s: unable to restart LCDC\n", __func__);
+ info->fix.line_length = line_length;
+ }
return ret;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 4/8] fbdev: sh_mobile_lcdc: use display information in info for panning
From: Laurent Pinchart @ 2011-08-31 11:00 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/sh_mobile_lcdcfb.c | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index f9f420d..1ff215c 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -877,12 +877,12 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
unsigned long base_addr_y, base_addr_c;
unsigned long c_offset;
- if (!var->nonstd)
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * (info->var.bits_per_pixel / 8));
+ if (!info->var.nonstd)
+ new_pan_offset = var->yoffset * info->fix.line_length
+ + var->xoffset * (info->var.bits_per_pixel / 8);
else
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset);
+ new_pan_offset = var->yoffset * info->fix.line_length
+ + var->xoffset;
if (new_pan_offset = ch->pan_offset)
return 0; /* No change, do nothing */
@@ -891,13 +891,13 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
/* Set the source address for the next refresh */
base_addr_y = ch->dma_handle + new_pan_offset;
- if (var->nonstd) {
+ if (info->var.nonstd) {
/* Set y offset */
- c_offset = (var->yoffset *
- info->fix.line_length *
- (info->var.bits_per_pixel - 8)) / 8;
- base_addr_c = ch->dma_handle + var->xres * var->yres_virtual +
- c_offset;
+ c_offset = var->yoffset * info->fix.line_length
+ * (info->var.bits_per_pixel - 8) / 8;
+ base_addr_c = ch->dma_handle
+ + info->var.xres * info->var.yres_virtual
+ + c_offset;
/* Set x offset */
if (info->var.bits_per_pixel = 24)
base_addr_c += 2 * var->xoffset;
@@ -923,7 +923,7 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
ch->base_addr_c = base_addr_c;
lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
- if (var->nonstd)
+ if (info->var.nonstd)
lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
if (lcdc_chan_is_sublcd(ch))
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 3/8] fbdev: sh_mobile_lcdc: Add support for format changes at runtime
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Implement .fb_set_par to support frame buffer format changes at runtime.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 33b0ff8..f9f420d 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1154,6 +1154,19 @@ static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *in
return 0;
}
+static int sh_mobile_set_par(struct fb_info *info)
+{
+ struct sh_mobile_lcdc_chan *ch = info->par;
+ int ret;
+
+ sh_mobile_lcdc_stop(ch->lcdc);
+ ret = sh_mobile_lcdc_start(ch->lcdc);
+ if (ret < 0)
+ dev_err(info->dev, "%s: unable to restart LCDC\n", __func__);
+
+ return ret;
+}
+
/*
* Screen blanking. Behavior is as follows:
* FB_BLANK_UNBLANK: screen unblanked, clocks enabled
@@ -1211,6 +1224,7 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_open = sh_mobile_open,
.fb_release = sh_mobile_release,
.fb_check_var = sh_mobile_check_var,
+ .fb_set_par = sh_mobile_set_par,
};
static int sh_mobile_lcdc_update_bl(struct backlight_device *bdev)
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 2/8] fbdev: sh_mobile_lcdc: Adjust requested parameters in .fb_check_var
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Instead of failing when the requested fb_var_screeninfo parameters are
not supported, adjust the parameters according to the hardware
capabilities.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_lcdcfb.c | 103 ++++++++++++++++++++++++++++++++------
1 files changed, 88 insertions(+), 15 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 088cb17..33b0ff8 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1055,28 +1055,101 @@ static int sh_mobile_check_var(struct fb_var_screeninfo *var, struct fb_info *in
{
struct sh_mobile_lcdc_chan *ch = info->par;
struct sh_mobile_lcdc_priv *p = ch->lcdc;
+ unsigned int best_dist = (unsigned int)-1;
+ unsigned int best_xres = 0;
+ unsigned int best_yres = 0;
+ unsigned int i;
- if (var->xres > MAX_XRES || var->yres > MAX_YRES ||
- var->xres * var->yres * (ch->cfg.bpp / 8) * 2 > info->fix.smem_len) {
- dev_warn(info->dev, "Invalid info: %u-%u-%u-%u x %u-%u-%u-%u @ %lukHz!\n",
- var->left_margin, var->xres, var->right_margin, var->hsync_len,
- var->upper_margin, var->yres, var->lower_margin, var->vsync_len,
- PICOS2KHZ(var->pixclock));
+ if (var->xres > MAX_XRES || var->yres > MAX_YRES)
return -EINVAL;
+
+ /* If board code provides us with a list of available modes, make sure
+ * we use one of them. Find the mode closest to the requested one. The
+ * distance between two modes is defined as the size of the
+ * non-overlapping parts of the two rectangles.
+ */
+ for (i = 0; i < ch->cfg.num_cfg; ++i) {
+ const struct fb_videomode *mode = &ch->cfg.lcd_cfg[i];
+ unsigned int dist;
+
+ /* We can only round up. */
+ if (var->xres > mode->xres || var->yres > mode->yres)
+ continue;
+
+ dist = var->xres * var->yres + mode->xres * mode->yres
+ - 2 * min(var->xres, mode->xres)
+ * min(var->yres, mode->yres);
+
+ if (dist < best_dist) {
+ best_xres = mode->xres;
+ best_yres = mode->yres;
+ best_dist = dist;
+ }
}
- /* only accept the forced_bpp for dual channel configurations */
- if (p->forced_bpp && p->forced_bpp != var->bits_per_pixel)
+ /* If no available mode can be used, return an error. */
+ if (ch->cfg.num_cfg != 0) {
+ if (best_dist = (unsigned int)-1)
+ return -EINVAL;
+
+ var->xres = best_xres;
+ var->yres = best_yres;
+ }
+
+ /* Make sure the virtual resolution is at least as big as the visible
+ * resolution.
+ */
+ if (var->xres_virtual < var->xres)
+ var->xres_virtual = var->xres;
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
+ if (var->bits_per_pixel <= 16) { /* RGB 565 */
+ var->bits_per_pixel = 16;
+ var->red.offset = 11;
+ var->red.length = 5;
+ var->green.offset = 5;
+ var->green.length = 6;
+ var->blue.offset = 0;
+ var->blue.length = 5;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 24) { /* RGB 888 */
+ var->bits_per_pixel = 24;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 0;
+ var->transp.length = 0;
+ } else if (var->bits_per_pixel <= 32) { /* RGBA 888 */
+ var->bits_per_pixel = 32;
+ var->red.offset = 16;
+ var->red.length = 8;
+ var->green.offset = 8;
+ var->green.length = 8;
+ var->blue.offset = 0;
+ var->blue.length = 8;
+ var->transp.offset = 24;
+ var->transp.length = 8;
+ } else
return -EINVAL;
- switch (var->bits_per_pixel) {
- case 16: /* PKF[4:0] = 00011 - RGB 565 */
- case 24: /* PKF[4:0] = 01011 - RGB 888 */
- case 32: /* PKF[4:0] = 00000 - RGBA 888 */
- break;
- default:
+ var->red.msb_right = 0;
+ var->green.msb_right = 0;
+ var->blue.msb_right = 0;
+ var->transp.msb_right = 0;
+
+ /* Make sure we don't exceed our allocated memory. */
+ if (var->xres_virtual * var->yres_virtual * var->bits_per_pixel / 8 >
+ info->fix.smem_len)
+ return -EINVAL;
+
+ /* only accept the forced_bpp for dual channel configurations */
+ if (p->forced_bpp && p->forced_bpp != var->bits_per_pixel)
return -EINVAL;
- }
return 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 1/8] sh_mobile_meram: Reset ICBs at unregistration time
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
When ICBs are unregistered and later reused they need to be reset to
avoid data corruption. Set the WBF, WF and RF bits to make sure ICBs get
reset properly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index f632970..4d63490 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -373,8 +373,10 @@ static void meram_deinit(struct sh_mobile_meram_priv *priv,
struct sh_mobile_meram_icb *icb)
{
/* disable ICB */
- meram_write_icb(priv->base, icb->cache_icb, MExxCTL, 0);
- meram_write_icb(priv->base, icb->marker_icb, MExxCTL, 0);
+ meram_write_icb(priv->base, icb->cache_icb, MExxCTL,
+ MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF);
+ meram_write_icb(priv->base, icb->marker_icb, MExxCTL,
+ MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF);
icb->cache_unit = 0;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 0/8] sh_mobile_lcdc: Support format changes at runtime
From: Laurent Pinchart @ 2011-08-31 11:00 UTC (permalink / raw)
To: linux-fbdev
Hi everybody,
Here's the second version of the .fb_set_par() support for the sh_mobile_lcdc
driver patch set. It allows userspace to change the frame buffer format and
size at runtime. The patches apply on top of Florian's fbdev-next branch
available at git://github.com/schandinat/linux-2.6.git.
Compared to v1, this version includes an additional MERAM fix.
Frame buffer memory reallocation is currently not supported. You will need to
make sure platform data sets the maximum size and bpp to high enough values
for all formats and sizes you want to support at runtime.
The patches have been tested with the fbdev-test utility
(http://git.ideasonboard.org/?pûdev-test.git;a=summary) on a Mackerel board.
Laurent Pinchart (8):
sh_mobile_meram: Reset ICBs at unregistration time
fbdev: sh_mobile_lcdc: Adjust requested parameters in .fb_check_var
fbdev: sh_mobile_lcdc: Add support for format changes at runtime
fbdev: sh_mobile_lcdc: use display information in info for panning
fbdev: sh_mobile_lcdc: Update fix.line_length in .fb_set_par()
fbdev: sh_mobile_lcdc: Avoid forward declarations
fbdev: sh_mobile_lcdc: Split channel initialization from probe
function
fbdev: sh_mobile_lcdc: Remove sh_mobile_lcdc_set_bpp()
drivers/video/sh_mobile_lcdcfb.c | 570 +++++++++++++++++++++-----------------
drivers/video/sh_mobile_meram.c | 6 +-
2 files changed, 313 insertions(+), 263 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PULL] SH mobile LCDC cleanups and fixes
From: Florian Tobias Schandinat @ 2011-08-30 20:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201108191044.52130.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 08/19/2011 08:44 AM, Laurent Pinchart wrote:
> Hi Florian,
>
> Here are the latest SH mobile LCDC and MERAM cleanups and fixes based on top
> of v3.1-rc2. All the patches have been posted to the list. I've incorporated
> acked-by and tested-by lines when available, but most of the patches received
> no comment.
>
> The following changes since commit 93ee7a9340d64f20295aacc3fb6a22b759323280:
>
> Linux 3.1-rc2 (2011-08-14 15:09:08 -0700)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git sh-mobile-lcdc
Pulled, thanks.
It looks good to me, as far as I can tell.
Just the first commits that were not your own ones should have had more verbose
commit messages and I think they should have had your Signed-off as you received
them via e-mail?
And on another note:
Would you mind adding yourself as maintainer of drivers/video/sh_mobile_* in
MAINTAINERS? I can't find any entry for it yet and having me as primary source
for review for a driver I don't know is a bad idea, at least if there are people
that know it better.
Thanks,
Florian Tobias Schandinat
>
> Damian Hobson-Garcia (5):
> fbdev: sh_mobile_meram: Enable runtime PM
> fbdev: sh_mobile_meram: Enable/disable MERAM along with LCDC
> fbdev: sh_mobile_meram: Move private data from .h to .c
> fbdev: sh_mobile_meram: Backup/restore device registers on shutdown/resume
> fbdev: sh_mobile_meram: Assign meram to the SH7372_A4LC power domain
>
> Laurent Pinchart (11):
> fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
> fbdev: sh_mobile_lcdc: Replace hardcoded register values with macros
> fbdev: sh_mobile_lcdc: Don't acknowlege interrupts unintentionally
> fbdev: sh_mobile_lcdc: Compute clock pattern using divider denominator
> fbdev: sh_mobile_lcdc: Split LCDC start code from sh_mobile_lcdc_start
> fbdev: sh_mobile_lcdc: Store the frame buffer base address when panning
> fbdev: sh_mobile_lcdc: Restart LCDC in runtime PM resume handler
> fbdev: sh_mobile_meram: Replace hardcoded register values with macros
> fbdev: sh_mobile_meram: Validate ICB configuration outside mutex
> fbdev: sh_mobile_meram: Fix MExxCTL register save on runtime PM suspend
> fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h
>
> arch/arm/mach-shmobile/board-mackerel.c | 1 +
> drivers/video/sh_mobile_lcdcfb.c | 592 ++++++++++++++-----------------
> drivers/video/sh_mobile_lcdcfb.h | 12 +-
> drivers/video/sh_mobile_meram.c | 202 +++++++++--
> drivers/video/sh_mobile_meram.h | 41 ---
> include/video/sh_mobile_lcdc.h | 135 ++++++-
> 6 files changed, 556 insertions(+), 427 deletions(-)
> delete mode 100644 drivers/video/sh_mobile_meram.h
>
^ permalink raw reply
* Re: [PATCH V8 1/5] ARM: EXYNOS4: Change clock name for FIMD
From: Tushar Behera @ 2011-08-30 14:56 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Jingoo Han', 'Paul Mundt', linux-samsung-soc,
linux-fbdev, 'Jonghun Han', 'Ben Dooks'
In-Reply-To: <006501cc4776$2ee2a4a0$8ca7ede0$%kim@samsung.com>
On Thursday 21 July 2011 12:46 PM, Kukjin Kim wrote:
> Jingoo Han wrote:
>>
>> This patch changes clock for FIMD from 'fimd' to 'lcd'.
>> Also, devname for FIMD is changed from 's5pv310-fb' to 'exynos4-fb'.
>>
>> Signed-off-by: Jingoo Han<jg1.han@samsung.com>
>> ---
>> arch/arm/mach-exynos4/clock.c | 12 ++++++------
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
>> index 98b5cc4..778a202 100644
>> --- a/arch/arm/mach-exynos4/clock.c
>> +++ b/arch/arm/mach-exynos4/clock.c
>> @@ -405,13 +405,13 @@ static struct clk init_clocks_off[] = {
>> .enable = exynos4_clk_ip_cam_ctrl,
>> .ctrlbit = (1<< 3),
>> }, {
>> - .name = "fimd",
>> - .devname = "s5pv310-fb.0",
>> + .name = "lcd",
>> + .devname = "exynos4-fb.0",
>> .enable = exynos4_clk_ip_lcd0_ctrl,
>> .ctrlbit = (1<< 0),
>> }, {
>> - .name = "fimd",
>> - .devname = "s5pv310-fb.1",
>> + .name = "lcd",
>
> As I remember, some guys discussed about the clock name before.
>
> Please refer to the following diagram. Before EXYNOS4210 clk 'lcd' was used
> for FIMD IP core clock and source of the LCD pixel clock. But the mux used
> to select source of LCD pixel clock is removed. So 'lcd' clock is only used
> for core clock of FIMD IP. It isn't used for LCD pixel clock.
>
> As a result clock name was changed from lcd to fimd in the EXYNOS4210
> datasheet.
>
In drivers/video/s3c-fb.c:s3c_fb_probe(), the bus clock is assumed to be
'lcd'. The bus clock name in all other related machine folder is 'lcd'.
Hence for consistency, we might consider renaming 'fimd'=>'lcd', even
though the clock name is different in the datasheet.
--
Tushar Behera
^ permalink raw reply
* Re: [PATCH] video/backlight: Remove obsolete cleanup for clientdata
From: Jean Delvare @ 2011-08-30 12:52 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, Richard Purdie, Paul Mundt,
Andrew Morton, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1314269652-18702-1-git-send-email-w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, 25 Aug 2011 12:54:12 +0200, Wolfram Sang wrote:
> A few new i2c-drivers came into the kernel which clear the clientdata-pointer
> on exit or error. This is obsolete meanwhile, the core will do it.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> drivers/video/backlight/adp8870_bl.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
> index 05a8832..71d90f4 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -932,7 +932,6 @@ out:
> out1:
> backlight_device_unregister(bl);
> out2:
> - i2c_set_clientdata(client, NULL);
> kfree(data);
>
> return ret;
> @@ -952,7 +951,6 @@ static int __devexit adp8870_remove(struct i2c_client *client)
> &adp8870_bl_attr_group);
>
> backlight_device_unregister(data->bl);
> - i2c_set_clientdata(client, NULL);
> kfree(data);
>
> return 0;
Acked-by: Jean Delvare <khali@linux-fr.org>
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] fbdev: fix parsing of standard timings
From: Tomi Valkeinen @ 2011-08-30 5:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1314362328-30456-1-git-send-email-tomi.valkeinen@ti.com>
Hi Florian,
On Fri, 2011-08-26 at 18:02 +0000, Florian Tobias Schandinat wrote:
> Hi Tomi,
>
> On 08/26/2011 12:38 PM, Tomi Valkeinen wrote:
> > The standard timings parses uses 1:1 dimensions when the ratio in the
> > EDID data is 0. However, for EDID 1.3 and later the dimensions are 16:10
> > when the ratio is 0.
> >
> > Pass the version and revision numbers to get_std_timing() which can then
> > make the right decision about dimensions.
> >
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Thanks, looks good to me.
> I'd be happy if someone with access to the original EDID specs could confirm
> this and add his reviewed by.
> I also think adding a comment explaining this change would be helpful.
You can see the same thing done in
drivers/gpu/drm/drm_edid.c:drm_mode_std(). Although they seem to check
only revision, which looks a bit risky to me.
The specs seem to be available by just googling them, although I don't
know if it's legal to distribute them or not...
I've added your comment, I agree it's good. Patch below.
Tomi
From 82c630291ad39d45009352fce1b23b4d0f44f92d Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Thu, 25 Aug 2011 15:36:40 +0300
Subject: [PATCH] fbdev: fix parsing of standard timings
The standard timings parses uses 1:1 dimensions when the ratio in the
EDID data is 0. However, for EDID 1.3 and later the dimensions are 16:10
when the ratio is 0.
Pass the version and revision numbers to get_std_timing() which can then
make the right decision about dimensions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbmon.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 4f57485..cef6557 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -493,7 +493,8 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
return num;
}
-static int get_std_timing(unsigned char *block, struct fb_videomode *mode)
+static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
+ int ver, int rev)
{
int xres, yres = 0, refresh, ratio, i;
@@ -504,7 +505,11 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode)
ratio = (block[1] & 0xc0) >> 6;
switch (ratio) {
case 0:
- yres = xres;
+ /* in EDID 1.3 the meaning of 0 changed to 16:10 (prior 1:1) */
+ if (ver < 1 || (ver = 1 && rev < 3))
+ yres = xres;
+ else
+ yres = (xres * 10)/16;
break;
case 1:
yres = (xres * 3)/4;
@@ -533,12 +538,12 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode)
}
static int get_dst_timing(unsigned char *block,
- struct fb_videomode *mode)
+ struct fb_videomode *mode, int ver, int rev)
{
int j, num = 0;
for (j = 0; j < 6; j++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num]);
+ num += get_std_timing(block, &mode[num], ver, rev);
return num;
}
@@ -599,6 +604,10 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
struct fb_videomode *mode, *m;
unsigned char *block;
int num = 0, i, first = 1;
+ int ver, rev;
+
+ ver = edid[EDID_STRUCT_VERSION];
+ rev = edid[EDID_STRUCT_REVISION];
mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
if (mode = NULL)
@@ -632,12 +641,12 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
DPRINTK(" Standard Timings\n");
block = edid + STD_TIMING_DESCRIPTIONS_START;
for (i = 0; i < STD_TIMING; i++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num]);
+ num += get_std_timing(block, &mode[num], ver, rev);
block = edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (i = 0; i < 4; i++, block+= DETAILED_TIMING_DESCRIPTION_SIZE) {
if (block[0] = 0x00 && block[1] = 0x00 && block[3] = 0xfa)
- num += get_dst_timing(block + 5, &mode[num]);
+ num += get_dst_timing(block + 5, &mode[num], ver, rev);
}
/* Yikes, EDID data is totally useless */
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-30 1:09 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Geert Uytterhoeven, linux-fbdev, linux-media, magnus.damm,
Guennadi Liakhovetski
In-Reply-To: <4E5BC11F.7000704@gmx.de>
Hi Florian,
On Monday 29 August 2011 18:41:03 Florian Tobias Schandinat wrote:
> On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
> > On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
> >>> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> >>>> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> >>>>> On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >>>>>> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >>>>>>>> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >>>>>>>>
> >>>>>>>> - When using a mode that cannot be represented in the legacy
> >>>>>>>>
> >>>>>>>> way,
> >>>>>>>
> >>>>>>> Definitely.
> >>>>>>>
> >>>>>>>> - But what with modes that can be represented? Legacy software
> >>>>>>>>
> >>>>>>>> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >>>>>>>
> >>>>>>> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >>>>>>> configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
> >>>>>>> with a non-FOURCC format, the driver will report non-FOURCC types
> >>>>>>> and visuals.
> >>>>>>
> >>>>>> Hmm, two use cases:
> >>>>>> - The video mode is configured using a FOURCC-aware tool ("fbset
> >>>>>> on
> >>>>>>
> >>>>>> steroids").
> >>>>>
> >>>>> Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
> >>>>
> >>>> Yep.
> >>>>
> >>>>>> Later the user runs a legacy application.
> >>>>>>
> >>>>>> => Do not retain FOURCC across opening of /dev/fb*.
> >>>>>
> >>>>> I know about that problem, but it's not that easy to work around. We
> >>>>> have no per-open fixed and variable screen info, and FB devices can
> >>>>> be opened by multiple applications at the same time.
> >>>>>
> >>>>>> - Is there an easy way to force FOURCC reporting, so new apps
> >>>>>> don't
> >>>>>>
> >>>>>> have to support parsing the legacy formats? This is useful for new
> >>>>>> apps that want to support (a subset of) FOURCC modes only.
> >>>>>
> >>>>> Not at the moment.
> >>>>
> >>>> So perhaps we do need new ioctls instead...
> >>>> That would also ease an in-kernel translation layer.
> >>>
> >>> Do you mean new ioctls to replace the FOURCC API proposal, or new
> >>> ioctls for the above two operations ?
> >>
> >> New ioctls to replace the FOURCC proposal.
> >
> > *sigh*...
> >
> > I'd like other people's opinion on this before throwing everything away.
> > Florian, Magnus, Guennadi, others, what do you think ?
>
> So, your issue is that some formats can be represented in the new and the
> old way? There are 2 simpler solutions I can think of:
>
> (1) ignore it, just do it the way Laurent proposed. I understand that
> someone might feel uneasy about applications that are trapped because they
> don't know the new format but could work with the old one. But I think
> this is not a big issue as many applications will just try to set their
> own mode. For those that doesn't and rely on the previous mode that is set
> by fbset or similar, we could change fbset to prefer the old format if
> available. But even if we don't do this, I don't have a problem with a
> program failing because it sees an unsuitable mode even if it supports the
> legacy mode. It's not a regression and can be easily fixed in userspace.
I agree with you here. Issues should be fixed in userspace. I don't expect
many issues in practice, as fbdev is often used on systems where userspace
components are developed to work with each other (such as embedded systems).
If such a system is upgraded to use YUV support, all components will likely be
tested and upgraded.
> (2) forbid it, just allow drivers to implement FOURCC for formats that
> cannot be represented in the old scheme. This is my preferred solution if
> anyone has problems with (1).
I'm tempted by that solution. Not that I have an issue with (1), but I'm
wondering if we should try to use the FOURCC API for all formats, or just for
formats that can't be represented by the current API. We currently have no
bitplane FOURCCs, and I'm not sure if it would be worth adding them.
BTW, do recent hardware still support planar (in the bitplane sense) frame
buffers ? If so, is that used in practice on recent devices ? If the answer is
no, (1) might be the best solution, with bit-planar formats supported by the
current API only, and all other formats supported by the FOURCC API.
> I don't see how IOCTLs would help here. The pixel format just belongs into
> var and fix so it has to be represented there anyway and thus set through
> it. We could do an IOCTL that always returns the FOURCC active at the
> moment, if such a FOURCC exists, and always use the legacy API for
> representing it in var/fix, if it exists. But as I see this is not what
> you thought about so please explain what your IOCTLS would look like and
> how they would solve the problem.
>
> And I don't think a in-kernel translation layer is a good idea. Yes, it
> sounds interesting, but it's tricky and the result will be that the driver
> and userspace will permanently see different var and fix structures.
> Seriously I think changing every framebuffer driver out there would be
> easier and much saner than trying to implement such a thing.
I agree.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: linux-next tree addition request (fbdev)
From: Stephen Rothwell @ 2011-08-29 23:43 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-next, linux-fbdev@vger.kernel.org, Paul Mundt
In-Reply-To: <4E54FF5E.5050308@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
Hi Florian,
On Wed, 24 Aug 2011 13:40:46 +0000 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>
> can you please add
>
> git://github.com/schandinat/linux-2.6.git fbdev-next
>
> to linux-next. It collects patches for the frame buffer subsystem.
> Can you please add the linux-fbdev@vger.kernel.org mailing list as additional
> contact for warnings/errors/problems?
>
> You probably want to drop Paul's fbdev branches as they contain some outdated
> patches that will conflict with the newer versions.
I have replced Paul;s fbdev tree with yours and dropped his fbdev-current tree.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration
From: Florian Tobias Schandinat @ 2011-08-29 16:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, linux-fbdev, linux-media, magnus.damm,
Guennadi Liakhovetski
In-Reply-To: <201108291632.06717.laurent.pinchart@ideasonboard.com>
Hi,
On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
> Hi Geert,
>
> On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
>>> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
>>>> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
>>>>> On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>>>>>> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
>>>>>>>> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>>>>>>>> - When using a mode that cannot be represented in the legacy
>>>>>>>> way,
>>>>>>>
>>>>>>> Definitely.
>>>>>>>
>>>>>>>> - But what with modes that can be represented? Legacy software
>>>>>>>> cannot handle FB_{TYPE,VISUAL}_FOURCC.
>>>>>>>
>>>>>>> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>>>>>>> configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
>>>>>>> with a non-FOURCC format, the driver will report non-FOURCC types
>>>>>>> and visuals.
>>>>>>
>>>>>> Hmm, two use cases:
>>>>>> - The video mode is configured using a FOURCC-aware tool ("fbset on
>>>>>> steroids").
>>>>>
>>>>> Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
>>>>
>>>> Yep.
>>>>
>>>>>> Later the user runs a legacy application.
>>>>>> => Do not retain FOURCC across opening of /dev/fb*.
>>>>>
>>>>> I know about that problem, but it's not that easy to work around. We
>>>>> have no per-open fixed and variable screen info, and FB devices can
>>>>> be opened by multiple applications at the same time.
>>>>>
>>>>>> - Is there an easy way to force FOURCC reporting, so new apps don't
>>>>>> have to support parsing the legacy formats? This is useful for new
>>>>>> apps that want to support (a subset of) FOURCC modes only.
>>>>>
>>>>> Not at the moment.
>>>>
>>>> So perhaps we do need new ioctls instead...
>>>> That would also ease an in-kernel translation layer.
>>>
>>> Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
>>> for the above two operations ?
>>
>> New ioctls to replace the FOURCC proposal.
>
> *sigh*...
>
> I'd like other people's opinion on this before throwing everything away.
> Florian, Magnus, Guennadi, others, what do you think ?
>
So, your issue is that some formats can be represented in the new and the old way?
There are 2 simpler solutions I can think of:
(1) ignore it, just do it the way Laurent proposed. I understand that someone
might feel uneasy about applications that are trapped because they don't know
the new format but could work with the old one. But I think this is not a big
issue as many applications will just try to set their own mode. For those that
doesn't and rely on the previous mode that is set by fbset or similar, we could
change fbset to prefer the old format if available. But even if we don't do
this, I don't have a problem with a program failing because it sees an
unsuitable mode even if it supports the legacy mode. It's not a regression and
can be easily fixed in userspace.
(2) forbid it, just allow drivers to implement FOURCC for formats that cannot be
represented in the old scheme. This is my preferred solution if anyone has
problems with (1).
I don't see how IOCTLs would help here. The pixel format just belongs into var
and fix so it has to be represented there anyway and thus set through it. We
could do an IOCTL that always returns the FOURCC active at the moment, if such a
FOURCC exists, and always use the legacy API for representing it in var/fix, if
it exists. But as I see this is not what you thought about so please explain
what your IOCTLS would look like and how they would solve the problem.
And I don't think a in-kernel translation layer is a good idea. Yes, it sounds
interesting, but it's tricky and the result will be that the driver and
userspace will permanently see different var and fix structures. Seriously I
think changing every framebuffer driver out there would be easier and much saner
than trying to implement such a thing.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-29 14:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-fbdev, linux-media, magnus.damm, Florian Tobias Schandinat,
Guennadi Liakhovetski
In-Reply-To: <CAMuHMdV1mPFUWk_=6sB73hFiRXeXwgLGKzSQy=gZA0YuG0Fb3A@mail.gmail.com>
Hi Geert,
On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
> > On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> >> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> >> >> - When using a mode that cannot be represented in the legacy
> >> >> >> way,
> >> >> >
> >> >> > Definitely.
> >> >> >
> >> >> >> - But what with modes that can be represented? Legacy software
> >> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >> >> >
> >> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
> >> >> > with a non-FOURCC format, the driver will report non-FOURCC types
> >> >> > and visuals.
> >> >>
> >> >> Hmm, two use cases:
> >> >> - The video mode is configured using a FOURCC-aware tool ("fbset on
> >> >> steroids").
> >> >
> >> > Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
> >>
> >> Yep.
> >>
> >> >> Later the user runs a legacy application.
> >> >> => Do not retain FOURCC across opening of /dev/fb*.
> >> >
> >> > I know about that problem, but it's not that easy to work around. We
> >> > have no per-open fixed and variable screen info, and FB devices can
> >> > be opened by multiple applications at the same time.
> >> >
> >> >> - Is there an easy way to force FOURCC reporting, so new apps don't
> >> >> have to support parsing the legacy formats? This is useful for new
> >> >> apps that want to support (a subset of) FOURCC modes only.
> >> >
> >> > Not at the moment.
> >>
> >> So perhaps we do need new ioctls instead...
> >> That would also ease an in-kernel translation layer.
> >
> > Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
> > for the above two operations ?
>
> New ioctls to replace the FOURCC proposal.
*sigh*...
I'd like other people's opinion on this before throwing everything away.
Florian, Magnus, Guennadi, others, what do you think ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-08-29 14:26 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <201108291617.13236.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
>> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
>> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> >> >> Â - When using a mode that cannot be represented in the legacy way,
>> >> >
>> >> > Definitely.
>> >> >
>> >> >> Â - But what with modes that can be represented? Legacy software
>> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
>> >> >
>> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
>> >> > a non-FOURCC format, the driver will report non-FOURCC types and
>> >> > visuals.
>> >>
>> >> Hmm, two use cases:
>> >> Â - The video mode is configured using a FOURCC-aware tool ("fbset on
>> >> steroids").
>> >
>> > Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
>>
>> Yep.
>>
>> >> Â Â Later the user runs a legacy application.
>> >> Â Â Â => Do not retain FOURCC across opening of /dev/fb*.
>> >
>> > I know about that problem, but it's not that easy to work around. We have
>> > no per-open fixed and variable screen info, and FB devices can be opened
>> > by multiple applications at the same time.
>> >
>> >> Â - Is there an easy way to force FOURCC reporting, so new apps don't
>> >> have to support parsing the legacy formats? This is useful for new apps
>> >> that want to support (a subset of) FOURCC modes only.
>> >
>> > Not at the moment.
>>
>> So perhaps we do need new ioctls instead...
>> That would also ease an in-kernel translation layer.
>
> Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
> the above two operations ?
New ioctls to replace the FOURCC proposal.
Gr{oetje,eeting}s,
            Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-29 14:17 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <CAMuHMdV=ZWMSJ_-r9fRMs0RCHyDZL=1a0_ZPZCgLBYJf=Ws4=Q@mail.gmail.com>
Hi Geert,
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> >> - When using a mode that cannot be represented in the legacy way,
> >> >
> >> > Definitely.
> >> >
> >> >> - But what with modes that can be represented? Legacy software
> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >> >
> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
> >> > a non-FOURCC format, the driver will report non-FOURCC types and
> >> > visuals.
> >>
> >> Hmm, two use cases:
> >> - The video mode is configured using a FOURCC-aware tool ("fbset on
> >> steroids").
> >
> > Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
>
> Yep.
>
> >> Later the user runs a legacy application.
> >> => Do not retain FOURCC across opening of /dev/fb*.
> >
> > I know about that problem, but it's not that easy to work around. We have
> > no per-open fixed and variable screen info, and FB devices can be opened
> > by multiple applications at the same time.
> >
> >> - Is there an easy way to force FOURCC reporting, so new apps don't
> >> have to support parsing the legacy formats? This is useful for new apps
> >> that want to support (a subset of) FOURCC modes only.
> >
> > Not at the moment.
>
> So perhaps we do need new ioctls instead...
> That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
the above two operations ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-08-29 14:14 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <201108291534.35951.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
>> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> >> Â - When using a mode that cannot be represented in the legacy way,
>> >
>> > Definitely.
>> >
>> >> Â - But what with modes that can be represented? Legacy software cannot
>> >> Â Â handle FB_{TYPE,VISUAL}_FOURCC.
>> >
>> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
>> > non-FOURCC format, the driver will report non-FOURCC types and visuals.
>>
>> Hmm, two use cases:
>> Â - The video mode is configured using a FOURCC-aware tool ("fbset on
>> steroids").
>
> Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
Yep.
>> Â Â Later the user runs a legacy application.
>> Â Â Â => Do not retain FOURCC across opening of /dev/fb*.
>
> I know about that problem, but it's not that easy to work around. We have no
> per-open fixed and variable screen info, and FB devices can be opened by
> multiple applications at the same time.
>
>> Â - Is there an easy way to force FOURCC reporting, so new apps don't have
>> to support parsing the legacy formats? This is useful for new apps that
>> want to support (a subset of) FOURCC modes only.
>
> Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Gr{oetje,eeting}s,
            Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                 -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-29 13:34 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <CAMuHMdVGV6dYW+szHyD30=HvAnSh92rRp=PMauwZZLw6H7DhYw@mail.gmail.com>
Hi Geert,
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> - When using a mode that cannot be represented in the legacy way,
> >
> > Definitely.
> >
> >> - But what with modes that can be represented? Legacy software cannot
> >> handle FB_{TYPE,VISUAL}_FOURCC.
> >
> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
> > non-FOURCC format, the driver will report non-FOURCC types and visuals.
>
> Hmm, two use cases:
> - The video mode is configured using a FOURCC-aware tool ("fbset on
> steroids").
Such as http://git.ideasonboard.org/?pûdev-test.git;a=summary :-)
> Later the user runs a legacy application.
> => Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have no
per-open fixed and variable screen info, and FB devices can be opened by
multiple applications at the same time.
> - Is there an easy way to force FOURCC reporting, so new apps don't have
> to support parsing the legacy formats? This is useful for new apps that
> want to support (a subset of) FOURCC modes only.
Not at the moment.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Geert Uytterhoeven @ 2011-08-29 13:09 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <201108291455.36145.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> - When using a mode that cannot be represented in the legacy way,
>
> Definitely.
>
>> - But what with modes that can be represented? Legacy software cannot
>> handle FB_{TYPE,VISUAL}_FOURCC.
>
> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
> using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
> format, the driver will report non-FOURCC types and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool ("fbset on
steroids").
Later the user runs a legacy application.
=> Do not retain FOURCC across opening of /dev/fb*.
- Is there an easy way to force FOURCC reporting, so new apps don't have to
support parsing the legacy formats? This is useful for new apps that want to
support (a subset of) FOURCC modes only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
From: Laurent Pinchart @ 2011-08-29 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-fbdev, linux-media, magnus.damm
In-Reply-To: <CAMuHMdUheemZVb7cPAsyPrC9LLowr+XV_5A+H1EfWWbWHeCVFw@mail.gmail.com>
Hi Geert,
On Monday 29 August 2011 13:20:44 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart wrote:
> > On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote:
> >> > On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
> >> >> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
> >> [...]
> >>
> >> > If my understanding is now correct, a V4L2 planar YUV type where Y, U
> >> > and V components are stored in separate byte-oriented planes, with
> >> > each plane storing Y, U or V components packed (such as
> >> > http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html),
> >> > would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would
> >> > be true for an RGB format where each component is stored in a
> >> > separate plane with each plane sotring R, G or B packed.
> >>
> >> Indeed. Currently this cannot be represented.
> >
> > Good, at least I now understand the situation :-)
> >
> >> For ideas from the past, see e.g.
> >> http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
> >>
> >> > If the above is correct, what FB_TYPE_* should a driver report when
> >> > using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P
> >> > (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html)
> >> > or V4L2_PIX_FMT_NV12
> >> > (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
> >>
> >> We need new types for those. Or always use FOURCC for them.
> >
> > My proposal currently defined FB_VISUAL_FOURCC. What about adding
> > FB_TYPE_FOURCC as well ?
>
> That may make sense.
> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> - When using a mode that cannot be represented in the legacy way,
Definitely.
> - But what with modes that can be represented? Legacy software cannot
> handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
format, the driver will report non-FOURCC types and visuals.
--
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