* Re: Linux 2.6.38-rc6
From: Anca Emanuel @ 2011-02-24 13:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, linux-fbdev, Ben Skeggs, dri-devel, Borislav Petkov,
Linux Kernel Mailing List
In-Reply-To: <AANLkTinD2cC9dGg2eBtZQhWvhSsuH2BcWDj8byLhWWso@mail.gmail.com>
On Thu, Feb 24, 2011 at 2:28 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
>>>
>>> Looks like nouveafb took over from vesafb. Did you do anything special
>>> to trigger this?
>>
>> No. Just boot the system.
>
> Every boot?
Yes.
>
> And just out of interest, what happens if you don't have the vesafb
> driver at all?
>
> Linus
>
I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
and it works.
dmesg: http://pastebin.com/JAZsk4vD
^ permalink raw reply
* Re: [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Tomi Valkeinen @ 2011-02-24 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298528800-7399-1-git-send-email-samreen@ti.com>
On Thu, 2011-02-24 at 00:26 -0600, Nilofer, Samreen wrote:
> Enabling all the display interface options to be built as module
> And enabling all the display panels to be built as modules.
>
> Signed-off-by: Samreen <samreen@ti.com>
This looks good to me.
Tony, want to ack this? This enables all DSS features as modules. This
should go through dss tree, as this doesn't work without a fix that is
there.
Tomi
> arch/arm/configs/omap2plus_defconfig | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index ae890ca..407ccf8 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_MODE_HELPERS=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_OMAP_LCD_VGA=y
> +CONFIG_OMAP2_DSS=m
> +CONFIG_OMAP2_DSS_RFBI=y
> +CONFIG_OMAP2_DSS_SDI=y
> +CONFIG_OMAP2_DSS_DSI=y
> +CONFIG_FB_OMAP2=m
> +CONFIG_PANEL_GENERIC_DPI=m
> +CONFIG_PANEL_SHARP_LS037V7DW01=m
> +CONFIG_PANEL_NEC_NL8048HL11_01B=m
> +CONFIG_PANEL_TAAL=m
> +CONFIG_PANEL_TPO_TD043MTEA1=m
> +CONFIG_PANEL_ACX565AKM=m
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> CONFIG_LCD_CLASS_DEVICE=y
> CONFIG_LCD_PLATFORM=y
^ permalink raw reply
* [PATCH v6] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Samreen @ 2011-02-24 6:38 UTC (permalink / raw)
To: linux-arm-kernel
Enabling all the display interface options to be built as module
And enabling all the display panels to be built as modules.
Signed-off-by: Samreen <samreen@ti.com>
---
Version6:
Enabling all the display interface options and all the display
panels.
Version5:
Incorporating the comments from Tony Lindgren, Kevin Hilman,
Paul Mundt & Tomi Valkeinen to build DSS & panels as modules.
See: https://patchwork.kernel.org/patch/281492/
Version4:
Remove the enabling of the display panels by default.
Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.
Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of
Sharp LQ043T1DG01 panel enabled in previous version of this patch.
Testing:
---------
The base used for OMAP3 testing is:
branch: master
commit: bb95b65a
URL: git://gitorious.org/linux-omap-dss2/linux.git
And OMAP4 testing is on the following branch + few patches to enable DSI taal panel:
branch: lo-dss2-Feb18
commit: 67bcb5600
URL: git://dev.omapzoom.org/pub/scm/axelcx/kernel-display.git
The patch is tested on 3630zoom, 3430sdp & 4430sdp, it was not tested
on OMAP2 platform due crash seen while boot.
(See: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43921.html)
arch/arm/configs/omap2plus_defconfig | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..407ccf8 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,17 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS_RFBI=y
+CONFIG_OMAP2_DSS_SDI=y
+CONFIG_OMAP2_DSS_DSI=y
+CONFIG_FB_OMAP2=m
+CONFIG_PANEL_GENERIC_DPI=m
+CONFIG_PANEL_SHARP_LS037V7DW01=m
+CONFIG_PANEL_NEC_NL8048HL11_01B=m
+CONFIG_PANEL_TAAL=m
+CONFIG_PANEL_TPO_TD043MTEA1=m
+CONFIG_PANEL_ACX565AKM=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Geert Uytterhoeven @ 2011-02-24 6:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
On Thu, Feb 24, 2011 at 00:28, Magnus Damm <magnus.damm@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 8:22 PM, Damian <dhobsong@igel.co.jp> wrote:
>>>> diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
>>>> new file mode 100644
>>>> index 0000000..ec448bc
>>>> --- /dev/null
>>>> +++ b/include/linux/sh_mobile_fb.h
>>>> @@ -0,0 +1,14 @@
>>>> +/*
>>>> + * SH-Mobile High-Definition Multimedia Interface (HDMI)
>>>> + *
>>>> + * Copyright (C) 2011, Damian Hobson-Garciax<dhobsong@igel.co.jp>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>> +#ifndef SH_MOBILE_FB_H
>>>> +#define SH_MOBILE_FB_H
>>>> +
>>>> +#define SH_FB_YUV 0x1
>>>> +#endif /* SH_MOBILE_FB_H */
>>>> diff --git a/include/video/sh_mobile_lcdc.h
>>>> b/include/video/sh_mobile_lcdc.h
>>>> index daabae5..650ff17 100644
>>>> --- a/include/video/sh_mobile_lcdc.h
>>>> +++ b/include/video/sh_mobile_lcdc.h
>>>> @@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
>>>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>>>> struct sh_mobile_lcdc_board_cfg board_cfg;
>>>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn
>>>> I/F */
>>>> + int nonstd;
>>>> };
>>>>
>>>> struct sh_mobile_lcdc_info {
>>>> --
>>>> 1.7.1
>>>
>>> Can't the SH_FB_YUV macro definition go into
>>> include/video/sh_mobile_lcdc.h too?
>>
>> My thinking behind separating this out was that I wanted this
>> define to be accessible from user space. The reason is so that
>> an application can test the value of .nonstd against the flag to
>> know for sure if it is dealing with a YUV framebuffer or not.
>
> Hm, but ideally we want something standard. How do you know the nonstd
> flag is working as you expect from user space? All of a sudden you
> have code that depends on what type of fbdev driver you are using.
> This is ugly, but abstracting the nonstd interface does not make it
> better IMO.
>
> The nonstd thing is a hack, but for now it is close enough. V4L2 has
> standard NV12/NV16 support already, but I don't think there is any
> such thing for fbdev. So i see your patches as a stop-gap, but I
> really don't want to make it more complicated than it has to be. So
> exporting nonstd values in a header file to user space seems too
> complicated IMO.
>
> Please just live with the fact that nonstd is special for now. We need
> to rework the entire LCDC/HDMI/DSI area to support multiple planes and
> better PM anyway. Perhaps KMS is the way forward, or perhaps Media
> Controller? Maybe both?
>
>> I was under the impression that only headers under include/linux/ should be
>> accessed from user space, but to be honest, I'm not sure about that.
>> If that is in fact not the case, then I totally agree that it can go
>> into include/video/sh_mobile_lcdc.h.
>
> Please ditch the SH_FB_YUV constant all together. No need to build
> some abstraction on top of a hackish interface. Just check if nonstd
> is non-zero in the driver and assume that means YUV for now. That's
> good enough.
For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new FB_VISUAL_*
type instead, which indicates the fb_var_screeninfo.{red,green,blue} fields are
YCbCr instead of RGB.
Depending on the frame buffer organization, you also need new FB_TYPE_*/FB_AUX_*
types.
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
* [PATCH v2] fbdev: sh_mobile_lcdc: Add YUV framebuffer support
From: Damian Hobson-Garcia @ 2011-02-24 5:47 UTC (permalink / raw)
To: linux-fbdev
Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats
(bpp = 12, 16, and 24) respectively.
When double-buffering both Y planes appear before the C planes (Y-Y-C-C),
as opposed to Y-C-Y-C.
Set .nonstd in struct sh_mobile_lcdc_chan_cfg to enable YUV mode, and use
.bpp to distiguish between the 3 modes.
The value of .nonstd is copied to bits 16-31 of LDDFR in the LCDC and
should be set accordingly.
.nonstd must be set to 0 for RGB mode.
Due to the encoding of YUV data, the framebuffer will clear to green
instead of black.
In YUV 420 mode, panning is only possible in 2 line increments.
Additionally in YUV 420 mode the vertical resolution of the framebuffer
must be an even number.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
Changed from v1
* Drop the use of SH_FB_YUV defines everywhere
* Delete the now unnecessary <linux/sh_mobile_fb.h>
* Delete the second patch in the series (now only this patch remains)
drivers/video/sh_mobile_lcdcfb.c | 141 ++++++++++++++++++++++++++++++--------
drivers/video/sh_mobile_lcdcfb.h | 2 +-
include/video/sh_mobile_lcdc.h | 1 +
3 files changed, 115 insertions(+), 29 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index bf12e53..173973b 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -67,6 +67,7 @@ static unsigned long lcdc_offs_mainlcd[NR_CH_REGS] = {
[LDSM1R] = 0x428,
[LDSM2R] = 0x42c,
[LDSA1R] = 0x430,
+ [LDSA2R] = 0x434,
[LDMLSR] = 0x438,
[LDHCNR] = 0x448,
[LDHSYNR] = 0x44c,
@@ -151,6 +152,7 @@ static bool banked(int reg_nr)
case LDDFR:
case LDSM1R:
case LDSA1R:
+ case LDSA2R:
case LDMLSR:
case LDHCNR:
case LDHSYNR:
@@ -463,6 +465,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
struct sh_mobile_lcdc_board_cfg *board_cfg;
unsigned long tmp;
int bpp = 0;
+ unsigned long ldddsr;
int k, m;
int ret = 0;
@@ -541,16 +544,21 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
}
/* word and long word swap */
- switch (bpp) {
- case 16:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 6);
- break;
- case 24:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 7);
- break;
- case 32:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 4);
- break;
+ ldddsr = lcdc_read(priv, _LDDDSR);
+ if (priv->ch[0].info->var.nonstd)
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ else {
+ switch (bpp) {
+ case 16:
+ lcdc_write(priv, _LDDDSR, ldddsr | 6);
+ break;
+ case 24:
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ break;
+ case 32:
+ lcdc_write(priv, _LDDDSR, ldddsr | 4);
+ break;
+ }
}
for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
@@ -561,21 +569,40 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
/* set bpp format in PKF[4:0] */
tmp = lcdc_read_chan(ch, LDDFR);
- tmp &= ~0x0001001f;
- switch (ch->info->var.bits_per_pixel) {
- case 16:
- tmp |= 0x03;
- break;
- case 24:
- tmp |= 0x0b;
- break;
- case 32:
- break;
+ tmp &= ~0x0003031f;
+ if (ch->info->var.nonstd) {
+ tmp |= (ch->info->var.nonstd << 16);
+ switch (ch->info->var.bits_per_pixel) {
+ case 12:
+ break;
+ case 16:
+ tmp |= (0x1 << 8);
+ break;
+ case 24:
+ tmp |= (0x2 << 8);
+ break;
+ }
+ } else {
+ switch (ch->info->var.bits_per_pixel) {
+ case 16:
+ tmp |= 0x03;
+ break;
+ case 24:
+ tmp |= 0x0b;
+ break;
+ case 32:
+ break;
+ }
}
lcdc_write_chan(ch, LDDFR, tmp);
/* point out our frame buffer */
lcdc_write_chan(ch, LDSA1R, ch->info->fix.smem_start);
+ if (ch->info->var.nonstd)
+ lcdc_write_chan(ch, LDSA2R,
+ ch->info->fix.smem_start +
+ ch->info->var.xres *
+ ch->info->var.yres_virtual);
/* set line size */
lcdc_write_chan(ch, LDMLSR, ch->info->fix.line_length);
@@ -804,9 +831,15 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
struct sh_mobile_lcdc_priv *priv = ch->lcdc;
unsigned long ldrcntr;
unsigned long new_pan_offset;
+ unsigned long base_addr_y, base_addr_c;
+ unsigned long c_offset;
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * (info->var.bits_per_pixel / 8));
+ if (!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);
if (new_pan_offset = ch->pan_offset)
return 0; /* No change, do nothing */
@@ -814,7 +847,26 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
ldrcntr = lcdc_read(priv, _LDRCNTR);
/* Set the source address for the next refresh */
- lcdc_write_chan_mirror(ch, LDSA1R, ch->dma_handle + new_pan_offset);
+ base_addr_y = ch->dma_handle + new_pan_offset;
+ if (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;
+ /* Set x offset */
+ if (info->var.bits_per_pixel = 24)
+ base_addr_c += 2 * var->xoffset;
+ else
+ base_addr_c += var->xoffset;
+ } else
+ base_addr_c = 0;
+
+ lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
+ if (base_addr_c)
+ lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
+
if (lcdc_chan_is_sublcd(ch))
lcdc_write(ch->lcdc, _LDRCNTR, ldrcntr ^ LDRCNTR_SRS);
else
@@ -885,7 +937,10 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
- info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
+ 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
@@ -980,8 +1035,22 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_check_var = sh_mobile_check_var,
};
-static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp)
+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;
@@ -1260,6 +1329,14 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
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;
@@ -1274,7 +1351,11 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
max_cfg->xres, max_cfg->yres);
info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * (cfg->bpp / 8) * 2;
+ 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;
@@ -1292,7 +1373,7 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
- error = sh_mobile_lcdc_set_bpp(var, cfg->bpp);
+ error = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
if (error)
break;
@@ -1316,7 +1397,11 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
}
info->fix.smem_start = ch->dma_handle;
- info->fix.line_length = var->xres * (cfg->bpp / 8);
+ 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;
diff --git a/drivers/video/sh_mobile_lcdcfb.h b/drivers/video/sh_mobile_lcdcfb.h
index 9ecee2f..c953cb0 100644
--- a/drivers/video/sh_mobile_lcdcfb.h
+++ b/drivers/video/sh_mobile_lcdcfb.h
@@ -8,7 +8,7 @@
/* per-channel registers */
enum { LDDCKPAT1R, LDDCKPAT2R, LDMT1R, LDMT2R, LDMT3R, LDDFR, LDSM1R,
- LDSM2R, LDSA1R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
+ LDSM2R, LDSA1R, LDSA2R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
LDHAJR,
NR_CH_REGS };
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index daabae5..650ff17 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
struct sh_mobile_lcdc_board_cfg board_cfg;
struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
+ int nonstd;
};
struct sh_mobile_lcdc_info {
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Nilofer, Samreen @ 2011-02-24 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298468006.18466.37.camel@deskari>
Hi,
Valkeinen, Tomi wrote:
> Hi,
>
> On Wed, 2011-02-23 at 06:22 -0600, Nilofer, Samreen wrote:
>> Enabling Display options to be built as modules Also, the generic dpi,
>> sharp & nec panels are also enabled as modules.
>
> I've just posted a patch which fixes the problem with the
> regulators in DSS. With that patch we can safely enable all DSS interfaces
> (and thus panels) and the resulting binary will work on all boards.
>
> So can you make one more version which enables all the
> interfaces and panels as modules, based on
> git://gitorious.org/linux-omap-dss2/linux.git master
>
[samreen]
Sure. Will post out the next version soon.
> Tomi
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-02-24 3:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
Hi Magnus,
On 2011/02/24 8:28, Magnus Damm wrote:
> Hi Damian,
>
> On Wed, Feb 23, 2011 at 8:22 PM, Damian<dhobsong@igel.co.jp> wrote:
>>
>>>> diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
>>>> new file mode 100644
>>>> index 0000000..ec448bc
>>>> --- /dev/null
>>>> +++ b/include/linux/sh_mobile_fb.h
>>>> @@ -0,0 +1,14 @@
>>>> +/*
>>>> + * SH-Mobile High-Definition Multimedia Interface (HDMI)
>>>> + *
>>>> + * Copyright (C) 2011, Damian Hobson-Garciax<dhobsong@igel.co.jp>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>> +#ifndef SH_MOBILE_FB_H
>>>> +#define SH_MOBILE_FB_H
>>>> +
>>>> +#define SH_FB_YUV 0x1
>>>> +#endif /* SH_MOBILE_FB_H */
>>>> diff --git a/include/video/sh_mobile_lcdc.h
>>>> b/include/video/sh_mobile_lcdc.h
>>>> index daabae5..650ff17 100644
>>>> --- a/include/video/sh_mobile_lcdc.h
>>>> +++ b/include/video/sh_mobile_lcdc.h
>>>> @@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
>>>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>>>> struct sh_mobile_lcdc_board_cfg board_cfg;
>>>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn
>>>> I/F */
>>>> + int nonstd;
>>>> };
>>>>
>>>> struct sh_mobile_lcdc_info {
>>>> --
>>>> 1.7.1
>>>
>>> Can't the SH_FB_YUV macro definition go into
>>> include/video/sh_mobile_lcdc.h too?
>>
>> My thinking behind separating this out was that I wanted this
>> define to be accessible from user space. The reason is so that
>> an application can test the value of .nonstd against the flag to
>> know for sure if it is dealing with a YUV framebuffer or not.
>
> Hm, but ideally we want something standard. How do you know the nonstd
> flag is working as you expect from user space? All of a sudden you
> have code that depends on what type of fbdev driver you are using.
> This is ugly, but abstracting the nonstd interface does not make it
> better IMO.
>
> The nonstd thing is a hack, but for now it is close enough. V4L2 has
> standard NV12/NV16 support already, but I don't think there is any
> such thing for fbdev. So i see your patches as a stop-gap, but I
> really don't want to make it more complicated than it has to be. So
> exporting nonstd values in a header file to user space seems too
> complicated IMO.
>
> Please just live with the fact that nonstd is special for now. We need
> to rework the entire LCDC/HDMI/DSI area to support multiple planes and
> better PM anyway. Perhaps KMS is the way forward, or perhaps Media
> Controller? Maybe both?
>
>> I was under the impression that only headers under include/linux/ should be
>> accessed from user space, but to be honest, I'm not sure about that.
>> If that is in fact not the case, then I totally agree that it can go
>> into include/video/sh_mobile_lcdc.h.
>
> Please ditch the SH_FB_YUV constant all together. No need to build
> some abstraction on top of a hackish interface. Just check if nonstd
> is non-zero in the driver and assume that means YUV for now. That's
> good enough.
>
Ok, I see what you're saying. But if the SH_FB_YUV flag is disappearing,
I guess it makes sense to ditch the second patch in this series as well,
since that's just further abstraction (albeit locally).
> Thanks,
>
> / magnus
Thank you,
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* RE: [PATCH] drivers: ld9040 amoled driver support
From: leedonghwa @ 2011-02-24 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110118193046.27790664.akpm@linux-foundation.org>
Hi, Andrew and Paul
A month had elapsed since my patch was posted in mainline, but,
there is no review about it. So I make a request again to review
it.
As I explained before, ld9040 driver is very simple driver to
control amoled lcd panel. And it is very similar with s6e63m0
amoled driver, the difference is nothing but each specific
registers value.
Please review it.
Thank you,
Donghwa Lee
^ permalink raw reply
* Re: Linux 2.6.38-rc6
From: Dave Airlie @ 2011-02-24 0:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Anca Emanuel, Dave Airlie, linux-fbdev, Ben Skeggs, dri-devel,
Borislav Petkov, Linux Kernel Mailing List
In-Reply-To: <AANLkTinD2cC9dGg2eBtZQhWvhSsuH2BcWDj8byLhWWso@mail.gmail.com>
On Thu, Feb 24, 2011 at 10:28 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
>>>
>>> Looks like nouveafb took over from vesafb. Did you do anything special
>>> to trigger this?
>>
>> No. Just boot the system.
>
> Every boot?
>
> And just out of interest, what happens if you don't have the vesafb
> driver at all?
>
I think this is a race condition somewhere with plymouth getting
access to vesafb before it gets kicked off the hw,
I'm assuming removing the vga= line from the command line will stop it,
Dave.
^ permalink raw reply
* Re: Linux 2.6.38-rc6
From: Linus Torvalds @ 2011-02-24 0:28 UTC (permalink / raw)
To: Anca Emanuel
Cc: Dave Airlie, linux-fbdev, Ben Skeggs, dri-devel, Borislav Petkov,
Linux Kernel Mailing List
In-Reply-To: <AANLkTinxHVDwSCouTaZEvR3yTJnSPAas9z6JauGDdS7=@mail.gmail.com>
On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
>>
>> Looks like nouveafb took over from vesafb. Did you do anything special
>> to trigger this?
>
> No. Just boot the system.
Every boot?
And just out of interest, what happens if you don't have the vesafb
driver at all?
Linus
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Magnus Damm @ 2011-02-23 23:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
Hi Damian,
On Wed, Feb 23, 2011 at 8:22 PM, Damian <dhobsong@igel.co.jp> wrote:
>
>>> diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
>>> new file mode 100644
>>> index 0000000..ec448bc
>>> --- /dev/null
>>> +++ b/include/linux/sh_mobile_fb.h
>>> @@ -0,0 +1,14 @@
>>> +/*
>>> + * SH-Mobile High-Definition Multimedia Interface (HDMI)
>>> + *
>>> + * Copyright (C) 2011, Damian Hobson-Garciax<dhobsong@igel.co.jp>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +#ifndef SH_MOBILE_FB_H
>>> +#define SH_MOBILE_FB_H
>>> +
>>> +#define SH_FB_YUV 0x1
>>> +#endif /* SH_MOBILE_FB_H */
>>> diff --git a/include/video/sh_mobile_lcdc.h
>>> b/include/video/sh_mobile_lcdc.h
>>> index daabae5..650ff17 100644
>>> --- a/include/video/sh_mobile_lcdc.h
>>> +++ b/include/video/sh_mobile_lcdc.h
>>> @@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
>>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>>> struct sh_mobile_lcdc_board_cfg board_cfg;
>>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn
>>> I/F */
>>> + int nonstd;
>>> };
>>>
>>> struct sh_mobile_lcdc_info {
>>> --
>>> 1.7.1
>>
>> Can't the SH_FB_YUV macro definition go into
>> include/video/sh_mobile_lcdc.h too?
>
> My thinking behind separating this out was that I wanted this
> define to be accessible from user space. The reason is so that
> an application can test the value of .nonstd against the flag to
> know for sure if it is dealing with a YUV framebuffer or not.
Hm, but ideally we want something standard. How do you know the nonstd
flag is working as you expect from user space? All of a sudden you
have code that depends on what type of fbdev driver you are using.
This is ugly, but abstracting the nonstd interface does not make it
better IMO.
The nonstd thing is a hack, but for now it is close enough. V4L2 has
standard NV12/NV16 support already, but I don't think there is any
such thing for fbdev. So i see your patches as a stop-gap, but I
really don't want to make it more complicated than it has to be. So
exporting nonstd values in a header file to user space seems too
complicated IMO.
Please just live with the fact that nonstd is special for now. We need
to rework the entire LCDC/HDMI/DSI area to support multiple planes and
better PM anyway. Perhaps KMS is the way forward, or perhaps Media
Controller? Maybe both?
> I was under the impression that only headers under include/linux/ should be
> accessed from user space, but to be honest, I'm not sure about that.
> If that is in fact not the case, then I totally agree that it can go
> into include/video/sh_mobile_lcdc.h.
Please ditch the SH_FB_YUV constant all together. No need to build
some abstraction on top of a hackish interface. Just check if nonstd
is non-zero in the driver and assume that means YUV for now. That's
good enough.
Thanks,
/ magnus
^ permalink raw reply
* Re: Linux 2.6.38-rc6
From: Anca Emanuel @ 2011-02-23 17:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, linux-fbdev, Ben Skeggs, dri-devel, Borislav Petkov,
Linux Kernel Mailing List
In-Reply-To: <AANLkTi=Ys4mb4pc28cH4NMdtMgb2KewJbkXEGJmEP4J0@mail.gmail.com>
On Wed, Feb 23, 2011 at 6:32 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
>> General protection fault:
>> http://i.imgur.com/TBJ6y.jpg
>>
>> dmesg: http://pastebin.com/qD8pR8QH
>> config: http://pastebin.com/XEurtHWi
>
> That's drivers/video/fbmem.c: fb_release(), and the "Code:"
> disassembly shows that it is
>
> 1b: e8 f7 c0 29 00 callq xyz
> 20: 48 8b 93 b8 03 00 00 mov 0x3b8(%rbx),%rdx
> 27:* 48 8b 42 10 mov 0x10(%rdx),%rax <-- trapping instruction
>
> which corresponds to
>
> mutex_lock(&info->lock);
> if (info->fbops->fb_release)
> info->fbops->fb_release(info,1);
>
> so it looks like 'info->fbops' is invalid. It's in %rdx, and is
> 0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
> like some bad corruption (looks like a sequence of 16-bit numbers, but
> it could be anything).
>
> Looks like nouveafb took over from vesafb. Did you do anything special
> to trigger this?
No. Just boot the system.
>
> Also, you do seem to have some extra patches (yama at the least). Anything else?
I used git clone, nothing else.
First time 2.6.38-rc6 was working.
After an update from ubuntu I get that error at boot.
The dmesg is from Ubuntu 11.04 with their kernel and is working fine.
>
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Linux 2.6.38-rc6
From: Linus Torvalds @ 2011-02-23 16:32 UTC (permalink / raw)
To: Anca Emanuel, Dave Airlie, linux-fbdev, Ben Skeggs, dri-devel
Cc: Borislav Petkov, Linux Kernel Mailing List
In-Reply-To: <AANLkTinh4pF7iaUGMcv_9gPy+VBD5POsTHbF_2zPJ17r@mail.gmail.com>
On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel <anca.emanuel@gmail.com> wrote:
> General protection fault:
> http://i.imgur.com/TBJ6y.jpg
>
> dmesg: http://pastebin.com/qD8pR8QH
> config: http://pastebin.com/XEurtHWi
That's drivers/video/fbmem.c: fb_release(), and the "Code:"
disassembly shows that it is
1b: e8 f7 c0 29 00 callq xyz
20: 48 8b 93 b8 03 00 00 mov 0x3b8(%rbx),%rdx
27:* 48 8b 42 10 mov 0x10(%rdx),%rax <-- trapping instruction
which corresponds to
mutex_lock(&info->lock);
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
so it looks like 'info->fbops' is invalid. It's in %rdx, and is
0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
like some bad corruption (looks like a sequence of 16-bit numbers, but
it could be anything).
Looks like nouveafb took over from vesafb. Did you do anything special
to trigger this?
Also, you do seem to have some extra patches (yama at the least). Anything else?
Linus
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: James Simmons @ 2011-02-23 14:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
> > Can't the SH_FB_YUV macro definition go into
> > include/video/sh_mobile_lcdc.h too?
>
> My thinking behind separating this out was that I wanted this
> define to be accessible from user space. The reason is so that
> an application can test the value of .nonstd against the flag to
> know for sure if it is dealing with a YUV framebuffer or not.
> I was under the impression that only headers under include/linux/ should be
> accessed from user space, but to be honest, I'm not sure about that.
> If that is in fact not the case, then I totally agree that it can go
> into include/video/sh_mobile_lcdc.h.
> Do you know where the proper place for such a header would be?
Originally the idea was headers in include/video would be card
specific material to be used by userspace. Also those headers could be
used also by the kernel driver as well.
^ permalink raw reply
* Re: [PATCH] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Tomi Valkeinen @ 2011-02-23 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298463753-24880-1-git-send-email-samreen@ti.com>
Hi,
On Wed, 2011-02-23 at 06:22 -0600, Nilofer, Samreen wrote:
> Enabling Display options to be built as modules
> Also, the generic dpi, sharp & nec panels are also
> enabled as modules.
I've just posted a patch which fixes the problem with the regulators in
DSS. With that patch we can safely enable all DSS interfaces (and thus
panels) and the resulting binary will work on all boards.
So can you make one more version which enables all the interfaces and
panels as modules, based on
git://gitorious.org/linux-omap-dss2/linux.git master
Tomi
^ permalink raw reply
* [PATCH] OMAP2/3/4: DSS2: Enable Display SubSystem as modules
From: Samreen @ 2011-02-23 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Enabling Display options to be built as modules
Also, the generic dpi, sharp & nec panels are also
enabled as modules.
Signed-off-by: Samreen <samreen@ti.com>
---
Version5:
Incorporating the comments from Tony Lindgren, Kevin Hilman,
Paul Mundt & Tomi Valkeinen to build DSS & panels as modules.
See: https://patchwork.kernel.org/patch/281492/
Version4:
Remove the enabling of the display panels by default.
Version3:
Eliminate the separate default number of FBs for
different architecture. Keeping default FBs as 3 as before.
Version2:
Enables by default NEC panel used in zoom2/3/3630sdp, instead of
Sharp LQ043T1DG01 panel enabled in previous version of this patch.
Testing:
---------
The base used for OMAP3 testing is:
branch: master
commit: 7c23277
URL: git://gitorious.org/linux-omap-dss2/linux.git
And OMAP4 testing is on the following branch + few patches to enable DSI taal panel:
branch: lo-dss2-Feb18
commit: 67bcb5600
URL: git://dev.omapzoom.org/pub/scm/axelcx/kernel-display.git
The patch is tested on 3630zoom, 3430sdp & 4430sdp, it was not tested
on OMAP2 platform due crash seen while boot.
(See: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43921.html)
arch/arm/configs/omap2plus_defconfig | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..ddcae13 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -192,6 +192,11 @@ CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OMAP_LCD_VGA=y
+CONFIG_OMAP2_DSS=m
+CONFIG_FB_OMAP2=m
+CONFIG_PANEL_GENERIC_DPI=m
+CONFIG_PANEL_SHARP_LS037V7DW01=m
+CONFIG_PANEL_NEC_NL8048HL11_01B=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian @ 2011-02-23 11:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
>> diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
>> new file mode 100644
>> index 0000000..ec448bc
>> --- /dev/null
>> +++ b/include/linux/sh_mobile_fb.h
>> @@ -0,0 +1,14 @@
>> +/*
>> + * SH-Mobile High-Definition Multimedia Interface (HDMI)
>> + *
>> + * Copyright (C) 2011, Damian Hobson-Garciax<dhobsong@igel.co.jp>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef SH_MOBILE_FB_H
>> +#define SH_MOBILE_FB_H
>> +
>> +#define SH_FB_YUV 0x1
>> +#endif /* SH_MOBILE_FB_H */
>> diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
>> index daabae5..650ff17 100644
>> --- a/include/video/sh_mobile_lcdc.h
>> +++ b/include/video/sh_mobile_lcdc.h
>> @@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>> struct sh_mobile_lcdc_board_cfg board_cfg;
>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
>> + int nonstd;
>> };
>>
>> struct sh_mobile_lcdc_info {
>> --
>> 1.7.1
>
> Can't the SH_FB_YUV macro definition go into
> include/video/sh_mobile_lcdc.h too?
My thinking behind separating this out was that I wanted this
define to be accessible from user space. The reason is so that
an application can test the value of .nonstd against the flag to
know for sure if it is dealing with a YUV framebuffer or not.
I was under the impression that only headers under include/linux/ should
be accessed from user space, but to be honest, I'm not sure about that.
If that is in fact not the case, then I totally agree that it can go
into include/video/sh_mobile_lcdc.h.
Do you know where the proper place for such a header would be?
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
Thanks,
Damian
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Guennadi Liakhovetski @ 2011-02-23 10:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1298456210-26519-2-git-send-email-dhobsong@igel.co.jp>
On Wed, 23 Feb 2011, Damian Hobson-Garcia wrote:
> Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats (bpp = 12, 16, and 24)
> respectively.
> Set .nonstd = SH_FB_YUV to enable YUV mode, and use bpp to distiguish between
> the 3 modes.
> Due to the encoding of YUV data, the framebuffer will clear to green instead of black.
>
> Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 142 ++++++++++++++++++++++++++++++--------
> drivers/video/sh_mobile_lcdcfb.h | 2 +-
> include/linux/sh_mobile_fb.h | 14 ++++
> include/video/sh_mobile_lcdc.h | 1 +
> 4 files changed, 130 insertions(+), 29 deletions(-)
> create mode 100644 include/linux/sh_mobile_fb.h
>
[snip]
> diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
> new file mode 100644
> index 0000000..ec448bc
> --- /dev/null
> +++ b/include/linux/sh_mobile_fb.h
> @@ -0,0 +1,14 @@
> +/*
> + * SH-Mobile High-Definition Multimedia Interface (HDMI)
> + *
> + * Copyright (C) 2011, Damian Hobson-Garciax <dhobsong@igel.co.jp>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef SH_MOBILE_FB_H
> +#define SH_MOBILE_FB_H
> +
> +#define SH_FB_YUV 0x1
> +#endif /* SH_MOBILE_FB_H */
> diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
> index daabae5..650ff17 100644
> --- a/include/video/sh_mobile_lcdc.h
> +++ b/include/video/sh_mobile_lcdc.h
> @@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
> struct sh_mobile_lcdc_board_cfg board_cfg;
> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
> + int nonstd;
> };
>
> struct sh_mobile_lcdc_info {
> --
> 1.7.1
Can't the SH_FB_YUV macro definition go into
include/video/sh_mobile_lcdc.h too?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 2/2] fbdev: sh_mobile_lcdc: Define additional .nonstd flags for sh7372
From: Damian Hobson-Garcia @ 2011-02-23 10:16 UTC (permalink / raw)
To: linux-fbdev
The value of the .nonstd member of struct sh_mobile_lcdc_info is written
directly into bits 16 and up of LDDFR in the LCDC. This patch defines
additional flags that can be "or'ed" with the .nonstd value to control
the LCDC behaviour when operating the the YUV display mode.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
arch/arm/mach-shmobile/include/mach/sh7372.h | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/include/mach/sh7372.h b/arch/arm/mach-shmobile/include/mach/sh7372.h
index 5736efc..cdbc2cf 100644
--- a/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ b/arch/arm/mach-shmobile/include/mach/sh7372.h
@@ -13,6 +13,17 @@
#include <linux/sh_clk.h>
+/* LCDC YUV support:
+ * The following bit flags are used to set the bits 17 and up
+ * in the MLDDFR. These flags should be used to set the
+ * .nonstd field in the struct sh_mobile_lcdc_info.
+ * Bit 16, which is accessible from user space is defined in
+ * <linux/sh_mobile_fb.h>
+ * The flags have different values for different chips
+ */
+#define LCDC_YUV_FULL_RANGE ((0x1 << 17) >> 16)
+#define LCDC_YUV_BT_709 ((0x1 << 18) >> 16)
+
/*
* Pin Function Controller:
* GPIO_FN_xx - GPIO used to select pin function
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support
From: Damian Hobson-Garcia @ 2011-02-23 10:16 UTC (permalink / raw)
To: linux-fbdev
Supports YCbCr420sp, YCbCr422sp, and YCbCr44sp, formats (bpp = 12, 16, and 24)
respectively.
Set .nonstd = SH_FB_YUV to enable YUV mode, and use bpp to distiguish between
the 3 modes.
Due to the encoding of YUV data, the framebuffer will clear to green instead of black.
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
---
drivers/video/sh_mobile_lcdcfb.c | 142 ++++++++++++++++++++++++++++++--------
drivers/video/sh_mobile_lcdcfb.h | 2 +-
include/linux/sh_mobile_fb.h | 14 ++++
include/video/sh_mobile_lcdc.h | 1 +
4 files changed, 130 insertions(+), 29 deletions(-)
create mode 100644 include/linux/sh_mobile_fb.h
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index bf12e53..f2814ea 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -24,6 +24,7 @@
#include <video/sh_mobile_lcdc.h>
#include <asm/atomic.h>
+#include <linux/sh_mobile_fb.h>
#include "sh_mobile_lcdcfb.h"
#define SIDE_B_OFFSET 0x1000
@@ -67,6 +68,7 @@ static unsigned long lcdc_offs_mainlcd[NR_CH_REGS] = {
[LDSM1R] = 0x428,
[LDSM2R] = 0x42c,
[LDSA1R] = 0x430,
+ [LDSA2R] = 0x434,
[LDMLSR] = 0x438,
[LDHCNR] = 0x448,
[LDHSYNR] = 0x44c,
@@ -151,6 +153,7 @@ static bool banked(int reg_nr)
case LDDFR:
case LDSM1R:
case LDSA1R:
+ case LDSA2R:
case LDMLSR:
case LDHCNR:
case LDHSYNR:
@@ -463,6 +466,7 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
struct sh_mobile_lcdc_board_cfg *board_cfg;
unsigned long tmp;
int bpp = 0;
+ unsigned long ldddsr;
int k, m;
int ret = 0;
@@ -541,16 +545,21 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
}
/* word and long word swap */
- switch (bpp) {
- case 16:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 6);
- break;
- case 24:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 7);
- break;
- case 32:
- lcdc_write(priv, _LDDDSR, lcdc_read(priv, _LDDDSR) | 4);
- break;
+ ldddsr = lcdc_read(priv, _LDDDSR);
+ if (priv->ch[0].info->var.nonstd & SH_FB_YUV)
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ else {
+ switch (bpp) {
+ case 16:
+ lcdc_write(priv, _LDDDSR, ldddsr | 6);
+ break;
+ case 24:
+ lcdc_write(priv, _LDDDSR, ldddsr | 7);
+ break;
+ case 32:
+ lcdc_write(priv, _LDDDSR, ldddsr | 4);
+ break;
+ }
}
for (k = 0; k < ARRAY_SIZE(priv->ch); k++) {
@@ -561,21 +570,40 @@ static int sh_mobile_lcdc_start(struct sh_mobile_lcdc_priv *priv)
/* set bpp format in PKF[4:0] */
tmp = lcdc_read_chan(ch, LDDFR);
- tmp &= ~0x0001001f;
- switch (ch->info->var.bits_per_pixel) {
- case 16:
- tmp |= 0x03;
- break;
- case 24:
- tmp |= 0x0b;
- break;
- case 32:
- break;
+ tmp &= ~0x0003031f;
+ if (ch->info->var.nonstd & SH_FB_YUV) {
+ tmp |= (ch->info->var.nonstd << 16);
+ switch (ch->info->var.bits_per_pixel) {
+ case 12:
+ break;
+ case 16:
+ tmp |= (0x1 << 8);
+ break;
+ case 24:
+ tmp |= (0x2 << 8);
+ break;
+ }
+ } else {
+ switch (ch->info->var.bits_per_pixel) {
+ case 16:
+ tmp |= 0x03;
+ break;
+ case 24:
+ tmp |= 0x0b;
+ break;
+ case 32:
+ break;
+ }
}
lcdc_write_chan(ch, LDDFR, tmp);
/* point out our frame buffer */
lcdc_write_chan(ch, LDSA1R, ch->info->fix.smem_start);
+ if (ch->info->var.nonstd & SH_FB_YUV)
+ lcdc_write_chan(ch, LDSA2R,
+ ch->info->fix.smem_start +
+ ch->info->var.xres *
+ ch->info->var.yres_virtual);
/* set line size */
lcdc_write_chan(ch, LDMLSR, ch->info->fix.line_length);
@@ -804,9 +832,15 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
struct sh_mobile_lcdc_priv *priv = ch->lcdc;
unsigned long ldrcntr;
unsigned long new_pan_offset;
+ unsigned long base_addr_y, base_addr_c;
+ unsigned long c_offset;
- new_pan_offset = (var->yoffset * info->fix.line_length) +
- (var->xoffset * (info->var.bits_per_pixel / 8));
+ if (!(var->nonstd & SH_FB_YUV))
+ 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);
if (new_pan_offset = ch->pan_offset)
return 0; /* No change, do nothing */
@@ -814,7 +848,26 @@ static int sh_mobile_fb_pan_display(struct fb_var_screeninfo *var,
ldrcntr = lcdc_read(priv, _LDRCNTR);
/* Set the source address for the next refresh */
- lcdc_write_chan_mirror(ch, LDSA1R, ch->dma_handle + new_pan_offset);
+ base_addr_y = ch->dma_handle + new_pan_offset;
+ if (var->nonstd & SH_FB_YUV) {
+ /* 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;
+ /* Set x offset */
+ if (info->var.bits_per_pixel = 24)
+ base_addr_c += 2 * var->xoffset;
+ else
+ base_addr_c += var->xoffset;
+ } else
+ base_addr_c = 0;
+
+ lcdc_write_chan_mirror(ch, LDSA1R, base_addr_y);
+ if (base_addr_c)
+ lcdc_write_chan_mirror(ch, LDSA2R, base_addr_c);
+
if (lcdc_chan_is_sublcd(ch))
lcdc_write(ch->lcdc, _LDRCNTR, ldrcntr ^ LDRCNTR_SRS);
else
@@ -885,7 +938,10 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
/* Couldn't reconfigure, hopefully, can continue as before */
return;
- info->fix.line_length = mode1.xres * (ch->cfg.bpp / 8);
+ if (info->var.nonstd & SH_FB_YUV)
+ 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
@@ -980,8 +1036,22 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_check_var = sh_mobile_check_var,
};
-static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp)
+static int sh_mobile_lcdc_set_bpp(struct fb_var_screeninfo *var, int bpp,
+ int nonstd)
{
+ if (nonstd & SH_FB_YUV) {
+ 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;
@@ -1260,6 +1330,14 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
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 & SH_FB_YUV) && 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;
@@ -1274,7 +1352,11 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
max_cfg->xres, max_cfg->yres);
info->fix = sh_mobile_lcdc_fix;
- info->fix.smem_len = max_size * (cfg->bpp / 8) * 2;
+ info->fix.smem_len = max_size * 2 * cfg->bpp / 8;
+
+ /* Only pan in 2 line steps for NV12 */
+ if ((cfg->nonstd & SH_FB_YUV) && cfg->bpp = 12)
+ info->fix.ypanstep = 2;
if (!mode) {
mode = &default_720p;
@@ -1292,7 +1374,7 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
var->yres_virtual = var->yres * 2;
var->activate = FB_ACTIVATE_NOW;
- error = sh_mobile_lcdc_set_bpp(var, cfg->bpp);
+ error = sh_mobile_lcdc_set_bpp(var, cfg->bpp, cfg->nonstd);
if (error)
break;
@@ -1316,7 +1398,11 @@ static int __devinit sh_mobile_lcdc_probe(struct platform_device *pdev)
}
info->fix.smem_start = ch->dma_handle;
- info->fix.line_length = var->xres * (cfg->bpp / 8);
+ if (var->nonstd & SH_FB_YUV)
+ 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;
diff --git a/drivers/video/sh_mobile_lcdcfb.h b/drivers/video/sh_mobile_lcdcfb.h
index 9ecee2f..c953cb0 100644
--- a/drivers/video/sh_mobile_lcdcfb.h
+++ b/drivers/video/sh_mobile_lcdcfb.h
@@ -8,7 +8,7 @@
/* per-channel registers */
enum { LDDCKPAT1R, LDDCKPAT2R, LDMT1R, LDMT2R, LDMT3R, LDDFR, LDSM1R,
- LDSM2R, LDSA1R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
+ LDSM2R, LDSA1R, LDSA2R, LDMLSR, LDHCNR, LDHSYNR, LDVLNR, LDVSYNR, LDPMR,
LDHAJR,
NR_CH_REGS };
diff --git a/include/linux/sh_mobile_fb.h b/include/linux/sh_mobile_fb.h
new file mode 100644
index 0000000..ec448bc
--- /dev/null
+++ b/include/linux/sh_mobile_fb.h
@@ -0,0 +1,14 @@
+/*
+ * SH-Mobile High-Definition Multimedia Interface (HDMI)
+ *
+ * Copyright (C) 2011, Damian Hobson-Garciax <dhobsong@igel.co.jp>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef SH_MOBILE_FB_H
+#define SH_MOBILE_FB_H
+
+#define SH_FB_YUV 0x1
+#endif /* SH_MOBILE_FB_H */
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index daabae5..650ff17 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -77,6 +77,7 @@ struct sh_mobile_lcdc_chan_cfg {
struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
struct sh_mobile_lcdc_board_cfg board_cfg;
struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
+ int nonstd;
};
struct sh_mobile_lcdc_info {
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] fbdev: sh_mobile_lcdc: YUV framebuffer support
From: Damian Hobson-Garcia @ 2011-02-23 10:16 UTC (permalink / raw)
To: linux-fbdev
These patches add support for 12, 16, and 24 bit YUV framebuffers.
These patches are a reworking of an earlier submitted patch
"Add NV12 input framebuffer support" to include the two other modes.
Additionally updated are:
* Y and C plane ordering. When double-buffering both Y planes appear before
the C planes (Y-Y-C-C), instead of Y-C-Y-C.
* In YUV 420 mode, panning is only possible in 2 line increments
* Additionally in YUV 420 mode the value of yres must be set to an even number
* The value of .nonstd in struct sh_mobile_lcdc_chan_cfg from the platform data is
exposed to applications via the .nonstd element of struct fb_var_screeninfo.
Additionally this value is written to bits 16-31 of LDDFR in the LCDC.
* Chip dependent flags for the bits of LDDFR greater that bit 17 are defined
* Add a userspace include file <linux/sh_mobile_fb.h> as a place to hold defines
and future ioctl definitions.
Damian Hobson-Garcia (2):
fbdev: sh_mobile_lcdc: Add YUV input support
fbdev: sh_mobile_lcdc: Define additional .nonstd flags for sh7372
arch/arm/mach-shmobile/include/mach/sh7372.h | 11 ++
drivers/video/sh_mobile_lcdcfb.c | 142 +++++++++++++++++++++-----
drivers/video/sh_mobile_lcdcfb.h | 2 +-
include/linux/sh_mobile_fb.h | 14 +++
include/video/sh_mobile_lcdc.h | 1 +
5 files changed, 141 insertions(+), 29 deletions(-)
create mode 100644 include/linux/sh_mobile_fb.h
^ permalink raw reply
* Re: [PATCH] OMAPFB: Adding a check for timings in set_def_mode
From: Tomi Valkeinen @ 2011-02-23 9:47 UTC (permalink / raw)
To: Janorkar, Mayuresh
Cc: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org,
lethal@linux-sh.org
In-Reply-To: <1298381713-13624-1-git-send-email-mayur@ti.com>
On Tue, 2011-02-22 at 07:35 -0600, Janorkar, Mayuresh wrote:
> When omapfb.mode is passed through bootargs, when omapfb is setting mode,
> it would check if timings passed are fine for panel attached to it.
> It makes use of check_timing API provided by the panel.
>
> In current code if check_timing API is not available for attached panel,
> OMAPFB would return -EINVAL and BPP sent via bootargs will not have any effect.
>
> In case of panels like TAAL panel, omapfb or any other driver should not be allowed to
> change the timings. So bpps sent via bootargs will not have an effect.
>
> In such case we can check only the x_res and y_res with the panels resolution
> and if they match go ahead and set the bpps.
> The bpp value sent via bootarg would have an effect.
>
> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
This looks good, applying to DSS tree.
Tomi
^ permalink raw reply
* [PATCH] s3fb: fix 15/16bpp modes with over 115MHz pixclocks on 86C365 Trio3D
From: Ondrej Zary @ 2011-02-22 22:36 UTC (permalink / raw)
To: Ondrej Zajicek; +Cc: linux-fbdev, Kernel development list, David Miller
Enable pixel multiplexing in 15/16bpp modes when pixclock is over 115MHz
on Trio3D (86C365) cards to fix artifacts on the left side of screen.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.38-rc4-/drivers/video/s3fb.c 2011-02-20 20:48:41.000000000 +0100
+++ linux-2.6.38-rc4/drivers/video/s3fb.c 2011-02-22 23:31:16.000000000 +0100
@@ -675,6 +675,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x20, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x30, 0xF0);
@@ -691,6 +700,15 @@
svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
else
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ } else if (par->chip = CHIP_365_TRIO3D) {
+ svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
+ if (info->var.pixclock > 8695) {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
+ hmul = 2;
+ } else {
+ svga_wcrt_mask(par->state.vgabase, 0x67, 0x40, 0xF0);
+ multiplex = 1;
+ }
} else {
svga_wcrt_mask(par->state.vgabase, 0x50, 0x10, 0x30);
svga_wcrt_mask(par->state.vgabase, 0x67, 0x50, 0xF0);
--
Ondrej Zary
^ permalink raw reply
* [PATCH] OMAPFB: Adding a check for timings in set_def_mode
From: Mayuresh Janorkar @ 2011-02-22 13:07 UTC (permalink / raw)
To: linux-fbdev, linux-omap, lethal, tomi.valkeinen; +Cc: Mayuresh Janorkar
When omapfb.mode is passed through bootargs, when omapfb is setting mode,
it would check if timings passed are fine for panel attached to it.
It makes use of check_timing API provided by the panel.
In current code if check_timing API is not available for attached panel,
OMAPFB would return -EINVAL and BPP sent via bootargs will not have any effect.
In case of panels like TAAL panel, omapfb or any other driver should not be allowed to
change the timings. So bpps sent via bootargs will not have an effect.
In such case we can check only the x_res and y_res with the panels resolution
and if they match go ahead and set the bpps.
The bpp value sent via bootarg would have an effect.
Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
---
BASE: git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
HEAD: dss2
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 4fdab8e..505ec66 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2090,7 +2090,7 @@ static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
{
int r;
u8 bpp;
- struct omap_video_timings timings;
+ struct omap_video_timings timings, temp_timings;
r = omapfb_mode_to_timings(mode_str, &timings, &bpp);
if (r)
@@ -2100,14 +2100,23 @@ static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
fbdev->bpp_overrides[fbdev->num_bpp_overrides].bpp = bpp;
++fbdev->num_bpp_overrides;
- if (!display->driver->check_timings || !display->driver->set_timings)
- return -EINVAL;
+ if (display->driver->check_timings) {
+ r = display->driver->check_timings(display, &timings);
+ if (r)
+ return r;
+ } else {
+ /* If check_timings is not present compare xres and yres */
+ if (display->driver->get_timings) {
+ display->driver->get_timings(display, &temp_timings);
- r = display->driver->check_timings(display, &timings);
- if (r)
- return r;
+ if (temp_timings.x_res != timings.x_res ||
+ temp_timings.y_res != timings.y_res)
+ return -EINVAL;
+ }
+ }
- display->driver->set_timings(display, &timings);
+ if (display->driver->set_timings)
+ display->driver->set_timings(display, &timings);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/1] sh_mobile_lcdc: Add NV12 input framebuffer support
From: Damian @ 2011-02-22 2:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1297734708-20803-2-git-send-email-dhobsong@igel.co.jp>
On 2011/02/17 14:45, Damian wrote:
Hi again Magnus,
> On 2011/02/17 9:19, Magnus Damm wrote:
> Hi Magnus,
>> Hi Damian,
>>
>> On Tue, Feb 15, 2011 at 10:51 AM, Damian Hobson-Garcia
>> <dhobsong@igel.co.jp> wrote:
>>> Specify .bpp = 12 and .yuv = 1 when configuring the LCDC channel that
>>> you want
>>> to you with NV12 input support.
>>>
>>> Due to the encoding of YUV data, writing 0s to the framebuffer will
>>> clear to
>>> green instead of black.
>>>
>>> There is also no native framebuffer support for YUV formats,
>>> so this mode will not work with most software rendering.
>>>
>>> Signed-off-by: Damian Hobson-Garcia<dhobsong@igel.co.jp>
>>> ---
>>
>> Nice to see patches for YUV mode support!
> And thank you for your comments.
>>
>>> --- a/include/video/sh_mobile_lcdc.h
>>> +++ b/include/video/sh_mobile_lcdc.h
>>> @@ -25,6 +25,8 @@ enum {
>>> SYS24, /* 24bpp */
>>> };
>>>
>>> +#define REN_COLOR_NV12 0x1 /* Non-standard framebuffer color format
>>> - NV12 */
>>> +
>>> enum { LCDC_CHAN_DISABLED = 0,
>>> LCDC_CHAN_MAINLCD,
>>> LCDC_CHAN_SUBLCD };
>>> @@ -77,6 +79,7 @@ struct sh_mobile_lcdc_chan_cfg {
>>> struct sh_mobile_lcdc_lcd_size_cfg lcd_size_cfg;
>>> struct sh_mobile_lcdc_board_cfg board_cfg;
>>> struct sh_mobile_lcdc_sys_bus_cfg sys_bus_cfg; /* only for SYSn I/F */
>>> + int yuv;
>>
>> Instead of having "yuv" here I think you should use "nonstd" and make
>> sure the "nonstd" field in struct fb_var_screeninfo is set the same
>> way.
>>
>> Also, the REN_COLOR_NV12 constant can go away IMO.
> Yes, I guess that using the nonstd together with the bits_per_pixel,
> REN_COLOR_NV12 is unnecessary.
>>
>> I believe the best way to deal with this is to map the "nonstd" value
>> directly to bit 16-18 in LDDFR. If "nonstd" is non-zero then you
>> should program bits 8-9 depending on the bpp value. This way both 12,
>> 16 and 20 (?) bit YUV can be supported with compression enabled or
>> not. I believe both sh7724 and sh7372 can be supported too - given
>> that the correct "nonstd" value is provided. But since it's provided
>> by the platform data it is part of the system configuration and we can
>> assume it is correct.
One question/comment about setting the value of nonstd.
Ideally, when an application reads the nonstd field from
fb_var_screeninfo, it would need to be sure that the value corresponds
to a YUV setting instead of some other valid non-zero nonstd value,
right? So maybe defining a bitmask for the YUV bit somewhere accessible
from user space would be beneficial (perhaps a new file,
linux/sh_mobile_fb.h, which might also be a good place to define any
ioctls that might be used in future, for blending for example).
It seems that for both sh7372 and sh7724 that bit would be bit 16 in
LDDFR, which is nice. As for the remaining bits, which are chip
dependent, I was thinking that it would be good to define similar
mask/flags and "or" them all together to build up nonstd. The question
is where to define these. There are separate files for mach/sh7724.h
and mach/sh7372.h, which I though might fit nicely or would it be better
to define flags for both chips in video/sh_mobile_lcdc.h?
> Sounds good. By 20 bit are you referring to the YCbCr 4:4:4 mode? I
> haven't really looked at that but it sounds like it should work. I think
> that its a 24 bit mode though, if I understand correctly 8 bits each for
> Y, Cb, Cr.
>>
>> Please consider reworking the patch to make it more generic. Just
>> adding NV12 support is aiming too low. =)
>>
> I'm also looking at re-arranging the arrangement of the Y and CbCr
> planes so that in a double buffer (or more) situation all of the Y
> planes come first, followed by the CbCr planes, as it makes the panning
> calculations much simpler.
>
> I'll submit these all as a version 2 of this patch.
>> Thanks,
>>
>> / magnus
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ 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