* [PATCH V2 RESEND] video: s3c-fb: Add support EXYNOS5 FIMD
From: Jingoo Han @ 2012-03-06 6:53 UTC (permalink / raw)
To: linux-fbdev, 'Florian Tobias Schandinat'
Cc: linux-samsung-soc, 'Kukjin Kim', 'Jingoo Han'
This patch adds s3c_fb_driverdata s3c_fb_data_exynos5 for EXYNOS5
and adds extended timing control setting.
EXYNOS5 FIMD needs extended setting for video timing control.
Additional bits are added to VIDTCON2, VIDWxxADD2, VIDOSDxA and
VIDOSDxB registers in order to set timing value for lager resolution.
Also, address offset of VIDTCONx registers is changed from 0x0
to 0x20000, thus variable type should be changed to int type
to handle the address offset of VIDTCONx registers for EXYNOS5 FIMD.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
v2: fix commit message from VIDCONx to VIDTCONx.
arch/arm/plat-samsung/include/plat/regs-fb.h | 24 ++++++++----
drivers/video/s3c-fb.c | 52 +++++++++++++++++++++++--
2 files changed, 63 insertions(+), 13 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
index bbb16e0..9a78012 100644
--- a/arch/arm/plat-samsung/include/plat/regs-fb.h
+++ b/arch/arm/plat-samsung/include/plat/regs-fb.h
@@ -167,15 +167,17 @@
#define VIDTCON1_HSPW(_x) ((_x) << 0)
#define VIDTCON2 (0x18)
+#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
#define VIDTCON2_LINEVAL_SHIFT (11)
#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
-#define VIDTCON2_LINEVAL(_x) ((_x) << 11)
+#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
+#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
#define VIDTCON2_HOZVAL_SHIFT (0)
#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
-#define VIDTCON2_HOZVAL(_x) ((_x) << 0)
+#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
/* WINCONx */
@@ -231,25 +233,29 @@
/* Local input channels (windows 0-2) */
#define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win)))
+#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_X(_x) ((_x) << 11)
+#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_Y(_x) ((_x) << 0)
+#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
+#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_X(_x) ((_x) << 11)
+#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
+#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_Y(_x) ((_x) << 0)
+#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
/* For VIDOSD[1..4]C */
#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
@@ -281,15 +287,17 @@
#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
#define VIDW_BUF_SIZE(_buff) (0x100 + ((_buff) * 4))
+#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_OFFSET(_x) ((_x) << 13)
+#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
+#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_PAGEWIDTH(_x) ((_x) << 0)
+#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
/* Interrupt controls and status */
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 1fb7ddf..f310516 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -89,7 +89,7 @@ struct s3c_fb;
struct s3c_fb_variant {
unsigned int is_2443:1;
unsigned short nr_windows;
- unsigned short vidtcon;
+ unsigned int vidtcon;
unsigned short wincon;
unsigned short winmap;
unsigned short keycon;
@@ -568,7 +568,9 @@ static int s3c_fb_set_par(struct fb_info *info)
writel(data, regs + sfb->variant.vidtcon + 4);
data = VIDTCON2_LINEVAL(var->yres - 1) |
- VIDTCON2_HOZVAL(var->xres - 1);
+ VIDTCON2_HOZVAL(var->xres - 1) |
+ VIDTCON2_LINEVAL_E(var->yres - 1) |
+ VIDTCON2_HOZVAL_E(var->xres - 1);
writel(data, regs + sfb->variant.vidtcon + 8);
}
@@ -584,17 +586,23 @@ static int s3c_fb_set_par(struct fb_info *info)
pagewidth = (var->xres * var->bits_per_pixel) >> 3;
data = VIDW_BUF_SIZE_OFFSET(info->fix.line_length - pagewidth) |
- VIDW_BUF_SIZE_PAGEWIDTH(pagewidth);
+ VIDW_BUF_SIZE_PAGEWIDTH(pagewidth) |
+ VIDW_BUF_SIZE_OFFSET_E(info->fix.line_length - pagewidth) |
+ VIDW_BUF_SIZE_PAGEWIDTH_E(pagewidth);
writel(data, regs + sfb->variant.buf_size + (win_no * 4));
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0) |
+ VIDOSDxA_TOPLEFT_X_E(0) | VIDOSDxA_TOPLEFT_Y_E(0);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ VIDOSDxB_BOTRIGHT_Y(var->yres - 1) |
+ VIDOSDxB_BOTRIGHT_X_E(s3c_fb_align_word(var->bits_per_pixel,
+ var->xres - 1)) |
+ VIDOSDxB_BOTRIGHT_Y_E(var->yres - 1);
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -1903,6 +1911,37 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
.win[4] = &s3c_fb_data_s5p_wins[4],
};
+static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
+ .variant = {
+ .nr_windows = 5,
+ .vidtcon = VIDTCON0,
+ .wincon = WINCON(0),
+ .winmap = WINxMAP(0),
+ .keycon = WKEYCON,
+ .osd = VIDOSD_BASE,
+ .osd_stride = 16,
+ .buf_start = VIDW_BUF_START(0),
+ .buf_size = VIDW_BUF_SIZE(0),
+ .buf_end = VIDW_BUF_END(0),
+
+ .palette = {
+ [0] = 0x2400,
+ [1] = 0x2800,
+ [2] = 0x2c00,
+ [3] = 0x3000,
+ [4] = 0x3400,
+ },
+ .has_shadowcon = 1,
+ .has_blendcon = 1,
+ .has_fixvclk = 1,
+ },
+ .win[0] = &s3c_fb_data_s5p_wins[0],
+ .win[1] = &s3c_fb_data_s5p_wins[1],
+ .win[2] = &s3c_fb_data_s5p_wins[2],
+ .win[3] = &s3c_fb_data_s5p_wins[3],
+ .win[4] = &s3c_fb_data_s5p_wins[4],
+};
+
/* S3C2443/S3C2416 style hardware */
static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
.variant = {
@@ -1981,6 +2020,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
.name = "exynos4-fb",
.driver_data = (unsigned long)&s3c_fb_data_exynos4,
}, {
+ .name = "exynos5-fb",
+ .driver_data = (unsigned long)&s3c_fb_data_exynos5,
+ }, {
.name = "s3c2443-fb",
.driver_data = (unsigned long)&s3c_fb_data_s3c2443,
}, {
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
From: Thomas Abraham @ 2012-03-06 6:47 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
ben-linux, patches
In-Reply-To: <002101ccfb61$710d2c70$53278550$%han@samsung.com>
On 6 March 2012 11:52, Jingoo Han <jg1.han@samsung.com> wrote:
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Tuesday, March 06, 2012 2:26 PM
>> To: Jingoo Han
>> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org;
>> kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org
>> Subject: Re: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
>>
>> On 6 March 2012 10:15, Jingoo Han <jg1.han@samsung.com> wrote:
>>
>> >> -----Original Message-----
>> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> >> Sent: Sunday, March 04, 2012 12:50 AM
>> >> To: linux-fbdev@vger.kernel.org
>> >> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
>> >> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
>> >> Subject: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
>> >>
>> >> The video interface timing is independent of the window setup data.
>> >> The resolution of the window can be smaller than that of the lcd
>> >> panel to which the video data is output.
>> >>
>> >> So move the video timing data from the per-window setup data to the
>> >> platform specific section in the platform data. This also removes
>> >> the restriction that atleast one window should have the same
>> >> resolution as that of the panel attached.
>> >>
>> >> Cc: Ben Dooks <ben-linux@fluff.org>
>> >> Cc: Jingoo Han <jg1.han@samsung.com>
>> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> >> ---
>> >> arch/arm/plat-samsung/include/plat/fb.h | 9 ++-
>> >> drivers/video/s3c-fb.c | 106 +++++++++++++++++--------------
>> >> 2 files changed, 63 insertions(+), 52 deletions(-)
>> >>
>> >> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
>> >> index 0fedf47..39d6bd7 100644
>> >> --- a/arch/arm/plat-samsung/include/plat/fb.h
>> >> +++ b/arch/arm/plat-samsung/include/plat/fb.h
>> >> @@ -24,15 +24,16 @@
>> >>
>> >> /**
>> >> * struct s3c_fb_pd_win - per window setup data
>> >> - * @win_mode: The display parameters to initialise (not for window 0)
>> >> + * @xres : The window X size.
>> >> + * @yres : The window Y size.
>> >> * @virtual_x: The virtual X size.
>> >> * @virtual_y: The virtual Y size.
>> >> */
>> >> struct s3c_fb_pd_win {
>> >> - struct fb_videomode win_mode;
>> >> -
>> >> unsigned short default_bpp;
>> >> unsigned short max_bpp;
>> >> + unsigned short xres;
>> >> + unsigned short yres;
>> >> unsigned short virtual_x;
>> >> unsigned short virtual_y;
>> >> };
>> >> @@ -45,6 +46,7 @@ struct s3c_fb_pd_win {
>> >> * @default_win: default window layer number to be used for UI layer.
>> >> * @vidcon0: The base vidcon0 values to control the panel data format.
>> >> * @vidcon1: The base vidcon1 values to control the panel data output.
>> >> + * @vtiming: Video timing when connected to a RGB type panel.
>> >
>> > fb_videomode can be set, even if it is not RGB type panel.
>> > In my opinion, it would be better.
>> > + * @vtiming: The video timing values to set the interface timing of the panel.
>>
>> The other interface that is supported is the i80 interface. Can these
>> timing values be used for i80 interface as well ?
>
> No, you're right. The i80 is not supported.
> Please ignore my comment.
>
>>
>> >
>> >> * @win: The setup data for each hardware window, or NULL for unused.
>> >> * @display_mode: The LCD output display mode.
>> >> *
>> >> @@ -58,6 +60,7 @@ struct s3c_fb_platdata {
>> >> void (*setup_gpio)(void);
>> >>
>> >> struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
>> >> + struct fb_videomode *vtiming;
>> >>
>> >> u32 default_win;
>> >>
>> >> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> >> index 1fb7ddf..8e05d4d 100644
>> >> --- a/drivers/video/s3c-fb.c
>> >> +++ b/drivers/video/s3c-fb.c
>> >> @@ -495,7 +495,6 @@ static int s3c_fb_set_par(struct fb_info *info)
>> >> u32 alpha = 0;
>> >> u32 data;
>> >> u32 pagewidth;
>> >> - int clkdiv;
>> >>
>> >> dev_dbg(sfb->dev, "setting framebuffer parameters\n");
>> >>
>> >> @@ -532,46 +531,9 @@ static int s3c_fb_set_par(struct fb_info *info)
>> >> /* disable the window whilst we update it */
>> >> writel(0, regs + WINCON(win_no));
>> >>
>> >> - /* use platform specified window as the basis for the lcd timings */
>> >> -
>> >> - if (win_no = sfb->pdata->default_win) {
>> >> - clkdiv = s3c_fb_calc_pixclk(sfb, var->pixclock);
>> >> -
>> >> - data = sfb->pdata->vidcon0;
>> >> - data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
>> >> -
>> >> - if (clkdiv > 1)
>> >> - data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
>> >> - else
>> >> - data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
>> >> -
>> >> - /* write the timing data to the panel */
>> >> -
>> >> - if (sfb->variant.is_2443)
>> >> - data |= (1 << 5);
>> >> -
>> >> - writel(data, regs + VIDCON0);
>> >> -
>> >> + if (win_no = sfb->pdata->default_win)
>> >> s3c_fb_enable(sfb, 1);
>> >>
>> >> - data = VIDTCON0_VBPD(var->upper_margin - 1) |
>> >> - VIDTCON0_VFPD(var->lower_margin - 1) |
>> >> - VIDTCON0_VSPW(var->vsync_len - 1);
>> >> -
>> >> - writel(data, regs + sfb->variant.vidtcon);
>> >> -
>> >> - data = VIDTCON1_HBPD(var->left_margin - 1) |
>> >> - VIDTCON1_HFPD(var->right_margin - 1) |
>> >> - VIDTCON1_HSPW(var->hsync_len - 1);
>> >> -
>> >> - /* VIDTCON1 */
>> >> - writel(data, regs + sfb->variant.vidtcon + 4);
>> >> -
>> >> - data = VIDTCON2_LINEVAL(var->yres - 1) |
>> >> - VIDTCON2_HOZVAL(var->xres - 1);
>> >> - writel(data, regs + sfb->variant.vidtcon + 8);
>> >> - }
>> >> -
>> >
>> > It looks good.
>> > VIDTCON registers don't need to be written whenever s3c_fb_set_par is called.
>> >
>> >> /* write the buffer address */
>> >>
>> >> /* start and end registers stride is 8 */
>> >> @@ -1136,11 +1098,11 @@ static int __devinit s3c_fb_alloc_memory(struct s3c_fb *sfb,
>> >>
>> >> dev_dbg(sfb->dev, "allocating memory for display\n");
>> >>
>> >> - real_size = windata->win_mode.xres * windata->win_mode.yres;
>> >> + real_size = windata->xres * windata->yres;
>> >> virt_size = windata->virtual_x * windata->virtual_y;
>> >>
>> >> dev_dbg(sfb->dev, "real_size=%u (%u.%u), virt_size=%u (%u.%u)\n",
>> >> - real_size, windata->win_mode.xres, windata->win_mode.yres,
>> >> + real_size, windata->xres, windata->yres,
>> >> virt_size, windata->virtual_x, windata->virtual_y);
>> >>
>> >> size = (real_size > virt_size) ? real_size : virt_size;
>> >> @@ -1222,7 +1184,7 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
>> >> struct s3c_fb_win **res)
>> >> {
>> >> struct fb_var_screeninfo *var;
>> >> - struct fb_videomode *initmode;
>> >> + struct fb_videomode initmode;
>> >
>> > *initmode cannot be used???
>> > Can you tell me why pointer type should be changed?
>> >
>>
>> The initmode is used to pass video timing to the fb_videomode_to_var()
>> function. Each window setup data in platform data included video
>> timing information. Since, the video timing data is now moved out of
>> per-window data, the xres and yres values have to be setup based on
>> the window for which the fb_videomode_to_var() is called. Hence, the
>> common timing values is first copied into initmode and then the window
>> specific xres and yres are set. If initmode is a maintained as a
>> pointer (to the video timing data in platform data), then any xres and
>> yres update to initmode would overwrite the 'constant' video timing.
>
> My point is that variable type 'initmode' can be not changed by using pointer type as follows:
>
> @@ -1243,11 +1243,11 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> }
>
> windata = sfb->pdata->win[win_no];
> - initmode = &windata->win_mode;
> + initmode = sfb->pdata->vtiming;
In this case, initmode is not pointing to the 'constant' lcd panel
timing values.
>
> WARN_ON(windata->max_bpp = 0);
> - WARN_ON(windata->win_mode.xres = 0);
> - WARN_ON(windata->win_mode.yres = 0);
> + WARN_ON(windata->xres = 0);
> + WARN_ON(windata->yres = 0);
>
> win = fbinfo->par;
> *res = win;
> @@ -1286,6 +1286,8 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> }
>
> /* setup the initial video mode from the window */
> + initmode->xres = windata->xres;
> + initmode->yres = windata->yres;
And then here, the xres and yres of the 'constant' lcd panel timing
value will be changed.
But, we don't want to change the actual lcd panel timing value. That
is the reason to first copy the lcd panel timing value into a local
copy and then update the xres and yres and then pass this local copy
of the timing value to fb_videomode_to_var() function.
Thanks,
Thomas.
[...]
^ permalink raw reply
* RE: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
From: Jingoo Han @ 2012-03-06 6:22 UTC (permalink / raw)
To: 'Thomas Abraham'
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
ben-linux, patches, 'Jingoo Han'
In-Reply-To: <CAJuYYwToJDXujqjLcY_2cN0M-K0yGzzOcDaFeh+OT_Qx9pPCEQ@mail.gmail.com>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Tuesday, March 06, 2012 2:26 PM
> To: Jingoo Han
> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org;
> kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org
> Subject: Re: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
>
> On 6 March 2012 10:15, Jingoo Han <jg1.han@samsung.com> wrote:
>
> >> -----Original Message-----
> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >> Sent: Sunday, March 04, 2012 12:50 AM
> >> To: linux-fbdev@vger.kernel.org
> >> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
> >> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
> >> Subject: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
> >>
> >> The video interface timing is independent of the window setup data.
> >> The resolution of the window can be smaller than that of the lcd
> >> panel to which the video data is output.
> >>
> >> So move the video timing data from the per-window setup data to the
> >> platform specific section in the platform data. This also removes
> >> the restriction that atleast one window should have the same
> >> resolution as that of the panel attached.
> >>
> >> Cc: Ben Dooks <ben-linux@fluff.org>
> >> Cc: Jingoo Han <jg1.han@samsung.com>
> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> >> ---
> >> arch/arm/plat-samsung/include/plat/fb.h | 9 ++-
> >> drivers/video/s3c-fb.c | 106 +++++++++++++++++--------------
> >> 2 files changed, 63 insertions(+), 52 deletions(-)
> >>
> >> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
> >> index 0fedf47..39d6bd7 100644
> >> --- a/arch/arm/plat-samsung/include/plat/fb.h
> >> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> >> @@ -24,15 +24,16 @@
> >>
> >> /**
> >> * struct s3c_fb_pd_win - per window setup data
> >> - * @win_mode: The display parameters to initialise (not for window 0)
> >> + * @xres : The window X size.
> >> + * @yres : The window Y size.
> >> * @virtual_x: The virtual X size.
> >> * @virtual_y: The virtual Y size.
> >> */
> >> struct s3c_fb_pd_win {
> >> - struct fb_videomode win_mode;
> >> -
> >> unsigned short default_bpp;
> >> unsigned short max_bpp;
> >> + unsigned short xres;
> >> + unsigned short yres;
> >> unsigned short virtual_x;
> >> unsigned short virtual_y;
> >> };
> >> @@ -45,6 +46,7 @@ struct s3c_fb_pd_win {
> >> * @default_win: default window layer number to be used for UI layer.
> >> * @vidcon0: The base vidcon0 values to control the panel data format.
> >> * @vidcon1: The base vidcon1 values to control the panel data output.
> >> + * @vtiming: Video timing when connected to a RGB type panel.
> >
> > fb_videomode can be set, even if it is not RGB type panel.
> > In my opinion, it would be better.
> > + * @vtiming: The video timing values to set the interface timing of the panel.
>
> The other interface that is supported is the i80 interface. Can these
> timing values be used for i80 interface as well ?
No, you're right. The i80 is not supported.
Please ignore my comment.
>
> >
> >> * @win: The setup data for each hardware window, or NULL for unused.
> >> * @display_mode: The LCD output display mode.
> >> *
> >> @@ -58,6 +60,7 @@ struct s3c_fb_platdata {
> >> void (*setup_gpio)(void);
> >>
> >> struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
> >> + struct fb_videomode *vtiming;
> >>
> >> u32 default_win;
> >>
> >> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> >> index 1fb7ddf..8e05d4d 100644
> >> --- a/drivers/video/s3c-fb.c
> >> +++ b/drivers/video/s3c-fb.c
> >> @@ -495,7 +495,6 @@ static int s3c_fb_set_par(struct fb_info *info)
> >> u32 alpha = 0;
> >> u32 data;
> >> u32 pagewidth;
> >> - int clkdiv;
> >>
> >> dev_dbg(sfb->dev, "setting framebuffer parameters\n");
> >>
> >> @@ -532,46 +531,9 @@ static int s3c_fb_set_par(struct fb_info *info)
> >> /* disable the window whilst we update it */
> >> writel(0, regs + WINCON(win_no));
> >>
> >> - /* use platform specified window as the basis for the lcd timings */
> >> -
> >> - if (win_no = sfb->pdata->default_win) {
> >> - clkdiv = s3c_fb_calc_pixclk(sfb, var->pixclock);
> >> -
> >> - data = sfb->pdata->vidcon0;
> >> - data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
> >> -
> >> - if (clkdiv > 1)
> >> - data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
> >> - else
> >> - data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
> >> -
> >> - /* write the timing data to the panel */
> >> -
> >> - if (sfb->variant.is_2443)
> >> - data |= (1 << 5);
> >> -
> >> - writel(data, regs + VIDCON0);
> >> -
> >> + if (win_no = sfb->pdata->default_win)
> >> s3c_fb_enable(sfb, 1);
> >>
> >> - data = VIDTCON0_VBPD(var->upper_margin - 1) |
> >> - VIDTCON0_VFPD(var->lower_margin - 1) |
> >> - VIDTCON0_VSPW(var->vsync_len - 1);
> >> -
> >> - writel(data, regs + sfb->variant.vidtcon);
> >> -
> >> - data = VIDTCON1_HBPD(var->left_margin - 1) |
> >> - VIDTCON1_HFPD(var->right_margin - 1) |
> >> - VIDTCON1_HSPW(var->hsync_len - 1);
> >> -
> >> - /* VIDTCON1 */
> >> - writel(data, regs + sfb->variant.vidtcon + 4);
> >> -
> >> - data = VIDTCON2_LINEVAL(var->yres - 1) |
> >> - VIDTCON2_HOZVAL(var->xres - 1);
> >> - writel(data, regs + sfb->variant.vidtcon + 8);
> >> - }
> >> -
> >
> > It looks good.
> > VIDTCON registers don't need to be written whenever s3c_fb_set_par is called.
> >
> >> /* write the buffer address */
> >>
> >> /* start and end registers stride is 8 */
> >> @@ -1136,11 +1098,11 @@ static int __devinit s3c_fb_alloc_memory(struct s3c_fb *sfb,
> >>
> >> dev_dbg(sfb->dev, "allocating memory for display\n");
> >>
> >> - real_size = windata->win_mode.xres * windata->win_mode.yres;
> >> + real_size = windata->xres * windata->yres;
> >> virt_size = windata->virtual_x * windata->virtual_y;
> >>
> >> dev_dbg(sfb->dev, "real_size=%u (%u.%u), virt_size=%u (%u.%u)\n",
> >> - real_size, windata->win_mode.xres, windata->win_mode.yres,
> >> + real_size, windata->xres, windata->yres,
> >> virt_size, windata->virtual_x, windata->virtual_y);
> >>
> >> size = (real_size > virt_size) ? real_size : virt_size;
> >> @@ -1222,7 +1184,7 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> >> struct s3c_fb_win **res)
> >> {
> >> struct fb_var_screeninfo *var;
> >> - struct fb_videomode *initmode;
> >> + struct fb_videomode initmode;
> >
> > *initmode cannot be used???
> > Can you tell me why pointer type should be changed?
> >
>
> The initmode is used to pass video timing to the fb_videomode_to_var()
> function. Each window setup data in platform data included video
> timing information. Since, the video timing data is now moved out of
> per-window data, the xres and yres values have to be setup based on
> the window for which the fb_videomode_to_var() is called. Hence, the
> common timing values is first copied into initmode and then the window
> specific xres and yres are set. If initmode is a maintained as a
> pointer (to the video timing data in platform data), then any xres and
> yres update to initmode would overwrite the 'constant' video timing.
My point is that variable type 'initmode' can be not changed by using pointer type as follows:
@@ -1243,11 +1243,11 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
}
windata = sfb->pdata->win[win_no];
- initmode = &windata->win_mode;
+ initmode = sfb->pdata->vtiming;
WARN_ON(windata->max_bpp = 0);
- WARN_ON(windata->win_mode.xres = 0);
- WARN_ON(windata->win_mode.yres = 0);
+ WARN_ON(windata->xres = 0);
+ WARN_ON(windata->yres = 0);
win = fbinfo->par;
*res = win;
@@ -1286,6 +1286,8 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
}
/* setup the initial video mode from the window */
+ initmode->xres = windata->xres;
+ initmode->yres = windata->yres;
fb_videomode_to_var(&fbinfo->var, initmode);
fbinfo->fix.type = FB_TYPE_PACKED_PIXELS;
In this case, you don't need additional change such as following.
- struct fb_videomode *initmode;
+ struct fb_videomode initmode;
...
- fb_videomode_to_var(&fbinfo->var, initmode);
+ fb_videomode_to_var(&fbinfo->var, &initmode);
>
>
> >> struct s3c_fb_pd_win *windata;
> >> struct s3c_fb_win *win;
> >> struct fb_info *fbinfo;
> >> @@ -1243,11 +1205,11 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> >> }
> >>
> >> windata = sfb->pdata->win[win_no];
> >> - initmode = &windata->win_mode;
> >> + initmode = *sfb->pdata->vtiming;
> >>
> >> WARN_ON(windata->max_bpp = 0);
> >> - WARN_ON(windata->win_mode.xres = 0);
> >> - WARN_ON(windata->win_mode.yres = 0);
> >> + WARN_ON(windata->xres = 0);
> >> + WARN_ON(windata->yres = 0);
> >>
> >> win = fbinfo->par;
> >> *res = win;
> >> @@ -1286,7 +1248,9 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> >> }
> >>
> >> /* setup the initial video mode from the window */
> >> - fb_videomode_to_var(&fbinfo->var, initmode);
> >> + initmode.xres = windata->xres;
> >> + initmode.yres = windata->yres;
>
> Here, the xres and yres values are copied to initmode and described above.
>
> >> + fb_videomode_to_var(&fbinfo->var, &initmode);
> >>
> >> fbinfo->fix.type = FB_TYPE_PACKED_PIXELS;
> >> fbinfo->fix.accel = FB_ACCEL_NONE;
> >> @@ -1331,6 +1295,51 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> >> }
> >>
> >> /**
> >> + * s3c_fb_set_rgb_timing() - set video timing for rgb interface.
> >> + * @sfb: The base resources for the hardware.
> >> + *
> >> + * Set horizontal and vertical lcd rgb interface timing.
> >> + */
> >> +static void s3c_fb_set_rgb_timing(struct s3c_fb *sfb)
> >> +{
> >> + struct fb_videomode *vmode = sfb->pdata->vtiming;
> >> + void __iomem *regs = sfb->regs;
> >> + int clkdiv;
> >> + u32 data;
> >> +
> >> + if (!vmode->pixclock)
> >> + s3c_fb_missing_pixclock(vmode);
> >> +
> >> + clkdiv = s3c_fb_calc_pixclk(sfb, vmode->pixclock);
> >> +
> >> + data = sfb->pdata->vidcon0;
> >> + data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
> >> +
> >> + if (clkdiv > 1)
> >> + data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
> >> + else
> >> + data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
> >> +
> >> + if (sfb->variant.is_2443)
> >> + data |= (1 << 5);
> >> + writel(data, regs + VIDCON0);
> >> +
> >> + data = VIDTCON0_VBPD(vmode->upper_margin - 1) |
> >> + VIDTCON0_VFPD(vmode->lower_margin - 1) |
> >> + VIDTCON0_VSPW(vmode->vsync_len - 1);
> >> + writel(data, regs + sfb->variant.vidtcon);
> >> +
> >> + data = VIDTCON1_HBPD(vmode->left_margin - 1) |
> >> + VIDTCON1_HFPD(vmode->right_margin - 1) |
> >> + VIDTCON1_HSPW(vmode->hsync_len - 1);
> >> + writel(data, regs + sfb->variant.vidtcon + 4);
> >> +
> >> + data = VIDTCON2_LINEVAL(vmode->yres - 1) |
> >> + VIDTCON2_HOZVAL(vmode->xres - 1);
> >> + writel(data, regs + sfb->variant.vidtcon + 8);
> >> +}
> >> +
> >> +/**
> >> * s3c_fb_clear_win() - clear hardware window registers.
> >> * @sfb: The base resources for the hardware.
> >> * @win: The window to process.
> >> @@ -1473,15 +1482,14 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> >> writel(0xffffff, regs + WKEYCON1);
> >> }
> >>
> >> + s3c_fb_set_rgb_timing(sfb);
> >> +
> >
> > This s3c_fb_set_rgb_timing(sfb) should be added to s3c_fb_resume().
> > The timing registers should be set when s3c_fb_resume() is called.
> > If not, after resuming, timing registers such as VIDTCONx will not bet set.
>
> Yes, I missed that. I will add it in the resume path.
>
> Thanks for you comments. If you could let me know if i80 video timing
> values can be passed with 'struct fb_videomode', I will do the changes
> as you have suggested and quickly repost this patchset.
>
> Thanks,
> Thomas.
^ permalink raw reply
* Re: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
From: Thomas Abraham @ 2012-03-06 5:38 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
ben-linux, patches
In-Reply-To: <001f01ccfb53$f034ef00$d09ecd00$%han@samsung.com>
On 6 March 2012 10:15, Jingoo Han <jg1.han@samsung.com> wrote:
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Sunday, March 04, 2012 12:50 AM
>> To: linux-fbdev@vger.kernel.org
>> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
>> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
>> Subject: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
>>
>> The video interface timing is independent of the window setup data.
>> The resolution of the window can be smaller than that of the lcd
>> panel to which the video data is output.
>>
>> So move the video timing data from the per-window setup data to the
>> platform specific section in the platform data. This also removes
>> the restriction that atleast one window should have the same
>> resolution as that of the panel attached.
>>
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Jingoo Han <jg1.han@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> arch/arm/plat-samsung/include/plat/fb.h | 9 ++-
>> drivers/video/s3c-fb.c | 106 +++++++++++++++++--------------
>> 2 files changed, 63 insertions(+), 52 deletions(-)
>>
>> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
>> index 0fedf47..39d6bd7 100644
>> --- a/arch/arm/plat-samsung/include/plat/fb.h
>> +++ b/arch/arm/plat-samsung/include/plat/fb.h
>> @@ -24,15 +24,16 @@
>>
>> /**
>> * struct s3c_fb_pd_win - per window setup data
>> - * @win_mode: The display parameters to initialise (not for window 0)
>> + * @xres : The window X size.
>> + * @yres : The window Y size.
>> * @virtual_x: The virtual X size.
>> * @virtual_y: The virtual Y size.
>> */
>> struct s3c_fb_pd_win {
>> - struct fb_videomode win_mode;
>> -
>> unsigned short default_bpp;
>> unsigned short max_bpp;
>> + unsigned short xres;
>> + unsigned short yres;
>> unsigned short virtual_x;
>> unsigned short virtual_y;
>> };
>> @@ -45,6 +46,7 @@ struct s3c_fb_pd_win {
>> * @default_win: default window layer number to be used for UI layer.
>> * @vidcon0: The base vidcon0 values to control the panel data format.
>> * @vidcon1: The base vidcon1 values to control the panel data output.
>> + * @vtiming: Video timing when connected to a RGB type panel.
>
> fb_videomode can be set, even if it is not RGB type panel.
> In my opinion, it would be better.
> + * @vtiming: The video timing values to set the interface timing of the panel.
The other interface that is supported is the i80 interface. Can these
timing values be used for i80 interface as well ?
>
>> * @win: The setup data for each hardware window, or NULL for unused.
>> * @display_mode: The LCD output display mode.
>> *
>> @@ -58,6 +60,7 @@ struct s3c_fb_platdata {
>> void (*setup_gpio)(void);
>>
>> struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
>> + struct fb_videomode *vtiming;
>>
>> u32 default_win;
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 1fb7ddf..8e05d4d 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -495,7 +495,6 @@ static int s3c_fb_set_par(struct fb_info *info)
>> u32 alpha = 0;
>> u32 data;
>> u32 pagewidth;
>> - int clkdiv;
>>
>> dev_dbg(sfb->dev, "setting framebuffer parameters\n");
>>
>> @@ -532,46 +531,9 @@ static int s3c_fb_set_par(struct fb_info *info)
>> /* disable the window whilst we update it */
>> writel(0, regs + WINCON(win_no));
>>
>> - /* use platform specified window as the basis for the lcd timings */
>> -
>> - if (win_no = sfb->pdata->default_win) {
>> - clkdiv = s3c_fb_calc_pixclk(sfb, var->pixclock);
>> -
>> - data = sfb->pdata->vidcon0;
>> - data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
>> -
>> - if (clkdiv > 1)
>> - data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
>> - else
>> - data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
>> -
>> - /* write the timing data to the panel */
>> -
>> - if (sfb->variant.is_2443)
>> - data |= (1 << 5);
>> -
>> - writel(data, regs + VIDCON0);
>> -
>> + if (win_no = sfb->pdata->default_win)
>> s3c_fb_enable(sfb, 1);
>>
>> - data = VIDTCON0_VBPD(var->upper_margin - 1) |
>> - VIDTCON0_VFPD(var->lower_margin - 1) |
>> - VIDTCON0_VSPW(var->vsync_len - 1);
>> -
>> - writel(data, regs + sfb->variant.vidtcon);
>> -
>> - data = VIDTCON1_HBPD(var->left_margin - 1) |
>> - VIDTCON1_HFPD(var->right_margin - 1) |
>> - VIDTCON1_HSPW(var->hsync_len - 1);
>> -
>> - /* VIDTCON1 */
>> - writel(data, regs + sfb->variant.vidtcon + 4);
>> -
>> - data = VIDTCON2_LINEVAL(var->yres - 1) |
>> - VIDTCON2_HOZVAL(var->xres - 1);
>> - writel(data, regs + sfb->variant.vidtcon + 8);
>> - }
>> -
>
> It looks good.
> VIDTCON registers don't need to be written whenever s3c_fb_set_par is called.
>
>> /* write the buffer address */
>>
>> /* start and end registers stride is 8 */
>> @@ -1136,11 +1098,11 @@ static int __devinit s3c_fb_alloc_memory(struct s3c_fb *sfb,
>>
>> dev_dbg(sfb->dev, "allocating memory for display\n");
>>
>> - real_size = windata->win_mode.xres * windata->win_mode.yres;
>> + real_size = windata->xres * windata->yres;
>> virt_size = windata->virtual_x * windata->virtual_y;
>>
>> dev_dbg(sfb->dev, "real_size=%u (%u.%u), virt_size=%u (%u.%u)\n",
>> - real_size, windata->win_mode.xres, windata->win_mode.yres,
>> + real_size, windata->xres, windata->yres,
>> virt_size, windata->virtual_x, windata->virtual_y);
>>
>> size = (real_size > virt_size) ? real_size : virt_size;
>> @@ -1222,7 +1184,7 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
>> struct s3c_fb_win **res)
>> {
>> struct fb_var_screeninfo *var;
>> - struct fb_videomode *initmode;
>> + struct fb_videomode initmode;
>
> *initmode cannot be used???
> Can you tell me why pointer type should be changed?
>
The initmode is used to pass video timing to the fb_videomode_to_var()
function. Each window setup data in platform data included video
timing information. Since, the video timing data is now moved out of
per-window data, the xres and yres values have to be setup based on
the window for which the fb_videomode_to_var() is called. Hence, the
common timing values is first copied into initmode and then the window
specific xres and yres are set. If initmode is a maintained as a
pointer (to the video timing data in platform data), then any xres and
yres update to initmode would overwrite the 'constant' video timing.
>> struct s3c_fb_pd_win *windata;
>> struct s3c_fb_win *win;
>> struct fb_info *fbinfo;
>> @@ -1243,11 +1205,11 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
>> }
>>
>> windata = sfb->pdata->win[win_no];
>> - initmode = &windata->win_mode;
>> + initmode = *sfb->pdata->vtiming;
>>
>> WARN_ON(windata->max_bpp = 0);
>> - WARN_ON(windata->win_mode.xres = 0);
>> - WARN_ON(windata->win_mode.yres = 0);
>> + WARN_ON(windata->xres = 0);
>> + WARN_ON(windata->yres = 0);
>>
>> win = fbinfo->par;
>> *res = win;
>> @@ -1286,7 +1248,9 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
>> }
>>
>> /* setup the initial video mode from the window */
>> - fb_videomode_to_var(&fbinfo->var, initmode);
>> + initmode.xres = windata->xres;
>> + initmode.yres = windata->yres;
Here, the xres and yres values are copied to initmode and described above.
>> + fb_videomode_to_var(&fbinfo->var, &initmode);
>>
>> fbinfo->fix.type = FB_TYPE_PACKED_PIXELS;
>> fbinfo->fix.accel = FB_ACCEL_NONE;
>> @@ -1331,6 +1295,51 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
>> }
>>
>> /**
>> + * s3c_fb_set_rgb_timing() - set video timing for rgb interface.
>> + * @sfb: The base resources for the hardware.
>> + *
>> + * Set horizontal and vertical lcd rgb interface timing.
>> + */
>> +static void s3c_fb_set_rgb_timing(struct s3c_fb *sfb)
>> +{
>> + struct fb_videomode *vmode = sfb->pdata->vtiming;
>> + void __iomem *regs = sfb->regs;
>> + int clkdiv;
>> + u32 data;
>> +
>> + if (!vmode->pixclock)
>> + s3c_fb_missing_pixclock(vmode);
>> +
>> + clkdiv = s3c_fb_calc_pixclk(sfb, vmode->pixclock);
>> +
>> + data = sfb->pdata->vidcon0;
>> + data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
>> +
>> + if (clkdiv > 1)
>> + data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
>> + else
>> + data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
>> +
>> + if (sfb->variant.is_2443)
>> + data |= (1 << 5);
>> + writel(data, regs + VIDCON0);
>> +
>> + data = VIDTCON0_VBPD(vmode->upper_margin - 1) |
>> + VIDTCON0_VFPD(vmode->lower_margin - 1) |
>> + VIDTCON0_VSPW(vmode->vsync_len - 1);
>> + writel(data, regs + sfb->variant.vidtcon);
>> +
>> + data = VIDTCON1_HBPD(vmode->left_margin - 1) |
>> + VIDTCON1_HFPD(vmode->right_margin - 1) |
>> + VIDTCON1_HSPW(vmode->hsync_len - 1);
>> + writel(data, regs + sfb->variant.vidtcon + 4);
>> +
>> + data = VIDTCON2_LINEVAL(vmode->yres - 1) |
>> + VIDTCON2_HOZVAL(vmode->xres - 1);
>> + writel(data, regs + sfb->variant.vidtcon + 8);
>> +}
>> +
>> +/**
>> * s3c_fb_clear_win() - clear hardware window registers.
>> * @sfb: The base resources for the hardware.
>> * @win: The window to process.
>> @@ -1473,15 +1482,14 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>> writel(0xffffff, regs + WKEYCON1);
>> }
>>
>> + s3c_fb_set_rgb_timing(sfb);
>> +
>
> This s3c_fb_set_rgb_timing(sfb) should be added to s3c_fb_resume().
> The timing registers should be set when s3c_fb_resume() is called.
> If not, after resuming, timing registers such as VIDTCONx will not bet set.
Yes, I missed that. I will add it in the resume path.
Thanks for you comments. If you could let me know if i80 video timing
values can be passed with 'struct fb_videomode', I will do the changes
as you have suggested and quickly repost this patchset.
Thanks,
Thomas.
^ permalink raw reply
* RE: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
From: Jingoo Han @ 2012-03-06 4:45 UTC (permalink / raw)
To: 'Thomas Abraham', linux-fbdev
Cc: FlorianSchandinat, linux-samsung-soc, kgene.kim, ben-linux,
patches, 'Jingoo Han'
In-Reply-To: <1330789808-8253-2-git-send-email-thomas.abraham@linaro.org>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Sunday, March 04, 2012 12:50 AM
> To: linux-fbdev@vger.kernel.org
> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
> Subject: [PATCH 1/3] video: s3c-fb: move video interface timing out of window setup data
>
> The video interface timing is independent of the window setup data.
> The resolution of the window can be smaller than that of the lcd
> panel to which the video data is output.
>
> So move the video timing data from the per-window setup data to the
> platform specific section in the platform data. This also removes
> the restriction that atleast one window should have the same
> resolution as that of the panel attached.
>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 9 ++-
> drivers/video/s3c-fb.c | 106 +++++++++++++++++--------------
> 2 files changed, 63 insertions(+), 52 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
> index 0fedf47..39d6bd7 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -24,15 +24,16 @@
>
> /**
> * struct s3c_fb_pd_win - per window setup data
> - * @win_mode: The display parameters to initialise (not for window 0)
> + * @xres : The window X size.
> + * @yres : The window Y size.
> * @virtual_x: The virtual X size.
> * @virtual_y: The virtual Y size.
> */
> struct s3c_fb_pd_win {
> - struct fb_videomode win_mode;
> -
> unsigned short default_bpp;
> unsigned short max_bpp;
> + unsigned short xres;
> + unsigned short yres;
> unsigned short virtual_x;
> unsigned short virtual_y;
> };
> @@ -45,6 +46,7 @@ struct s3c_fb_pd_win {
> * @default_win: default window layer number to be used for UI layer.
> * @vidcon0: The base vidcon0 values to control the panel data format.
> * @vidcon1: The base vidcon1 values to control the panel data output.
> + * @vtiming: Video timing when connected to a RGB type panel.
fb_videomode can be set, even if it is not RGB type panel.
In my opinion, it would be better.
+ * @vtiming: The video timing values to set the interface timing of the panel.
> * @win: The setup data for each hardware window, or NULL for unused.
> * @display_mode: The LCD output display mode.
> *
> @@ -58,6 +60,7 @@ struct s3c_fb_platdata {
> void (*setup_gpio)(void);
>
> struct s3c_fb_pd_win *win[S3C_FB_MAX_WIN];
> + struct fb_videomode *vtiming;
>
> u32 default_win;
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 1fb7ddf..8e05d4d 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -495,7 +495,6 @@ static int s3c_fb_set_par(struct fb_info *info)
> u32 alpha = 0;
> u32 data;
> u32 pagewidth;
> - int clkdiv;
>
> dev_dbg(sfb->dev, "setting framebuffer parameters\n");
>
> @@ -532,46 +531,9 @@ static int s3c_fb_set_par(struct fb_info *info)
> /* disable the window whilst we update it */
> writel(0, regs + WINCON(win_no));
>
> - /* use platform specified window as the basis for the lcd timings */
> -
> - if (win_no = sfb->pdata->default_win) {
> - clkdiv = s3c_fb_calc_pixclk(sfb, var->pixclock);
> -
> - data = sfb->pdata->vidcon0;
> - data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
> -
> - if (clkdiv > 1)
> - data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
> - else
> - data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
> -
> - /* write the timing data to the panel */
> -
> - if (sfb->variant.is_2443)
> - data |= (1 << 5);
> -
> - writel(data, regs + VIDCON0);
> -
> + if (win_no = sfb->pdata->default_win)
> s3c_fb_enable(sfb, 1);
>
> - data = VIDTCON0_VBPD(var->upper_margin - 1) |
> - VIDTCON0_VFPD(var->lower_margin - 1) |
> - VIDTCON0_VSPW(var->vsync_len - 1);
> -
> - writel(data, regs + sfb->variant.vidtcon);
> -
> - data = VIDTCON1_HBPD(var->left_margin - 1) |
> - VIDTCON1_HFPD(var->right_margin - 1) |
> - VIDTCON1_HSPW(var->hsync_len - 1);
> -
> - /* VIDTCON1 */
> - writel(data, regs + sfb->variant.vidtcon + 4);
> -
> - data = VIDTCON2_LINEVAL(var->yres - 1) |
> - VIDTCON2_HOZVAL(var->xres - 1);
> - writel(data, regs + sfb->variant.vidtcon + 8);
> - }
> -
It looks good.
VIDTCON registers don't need to be written whenever s3c_fb_set_par is called.
> /* write the buffer address */
>
> /* start and end registers stride is 8 */
> @@ -1136,11 +1098,11 @@ static int __devinit s3c_fb_alloc_memory(struct s3c_fb *sfb,
>
> dev_dbg(sfb->dev, "allocating memory for display\n");
>
> - real_size = windata->win_mode.xres * windata->win_mode.yres;
> + real_size = windata->xres * windata->yres;
> virt_size = windata->virtual_x * windata->virtual_y;
>
> dev_dbg(sfb->dev, "real_size=%u (%u.%u), virt_size=%u (%u.%u)\n",
> - real_size, windata->win_mode.xres, windata->win_mode.yres,
> + real_size, windata->xres, windata->yres,
> virt_size, windata->virtual_x, windata->virtual_y);
>
> size = (real_size > virt_size) ? real_size : virt_size;
> @@ -1222,7 +1184,7 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> struct s3c_fb_win **res)
> {
> struct fb_var_screeninfo *var;
> - struct fb_videomode *initmode;
> + struct fb_videomode initmode;
*initmode cannot be used???
Can you tell me why pointer type should be changed?
> struct s3c_fb_pd_win *windata;
> struct s3c_fb_win *win;
> struct fb_info *fbinfo;
> @@ -1243,11 +1205,11 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> }
>
> windata = sfb->pdata->win[win_no];
> - initmode = &windata->win_mode;
> + initmode = *sfb->pdata->vtiming;
>
> WARN_ON(windata->max_bpp = 0);
> - WARN_ON(windata->win_mode.xres = 0);
> - WARN_ON(windata->win_mode.yres = 0);
> + WARN_ON(windata->xres = 0);
> + WARN_ON(windata->yres = 0);
>
> win = fbinfo->par;
> *res = win;
> @@ -1286,7 +1248,9 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> }
>
> /* setup the initial video mode from the window */
> - fb_videomode_to_var(&fbinfo->var, initmode);
> + initmode.xres = windata->xres;
> + initmode.yres = windata->yres;
> + fb_videomode_to_var(&fbinfo->var, &initmode);
>
> fbinfo->fix.type = FB_TYPE_PACKED_PIXELS;
> fbinfo->fix.accel = FB_ACCEL_NONE;
> @@ -1331,6 +1295,51 @@ static int __devinit s3c_fb_probe_win(struct s3c_fb *sfb, unsigned int win_no,
> }
>
> /**
> + * s3c_fb_set_rgb_timing() - set video timing for rgb interface.
> + * @sfb: The base resources for the hardware.
> + *
> + * Set horizontal and vertical lcd rgb interface timing.
> + */
> +static void s3c_fb_set_rgb_timing(struct s3c_fb *sfb)
> +{
> + struct fb_videomode *vmode = sfb->pdata->vtiming;
> + void __iomem *regs = sfb->regs;
> + int clkdiv;
> + u32 data;
> +
> + if (!vmode->pixclock)
> + s3c_fb_missing_pixclock(vmode);
> +
> + clkdiv = s3c_fb_calc_pixclk(sfb, vmode->pixclock);
> +
> + data = sfb->pdata->vidcon0;
> + data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
> +
> + if (clkdiv > 1)
> + data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
> + else
> + data &= ~VIDCON0_CLKDIR; /* 1:1 clock */
> +
> + if (sfb->variant.is_2443)
> + data |= (1 << 5);
> + writel(data, regs + VIDCON0);
> +
> + data = VIDTCON0_VBPD(vmode->upper_margin - 1) |
> + VIDTCON0_VFPD(vmode->lower_margin - 1) |
> + VIDTCON0_VSPW(vmode->vsync_len - 1);
> + writel(data, regs + sfb->variant.vidtcon);
> +
> + data = VIDTCON1_HBPD(vmode->left_margin - 1) |
> + VIDTCON1_HFPD(vmode->right_margin - 1) |
> + VIDTCON1_HSPW(vmode->hsync_len - 1);
> + writel(data, regs + sfb->variant.vidtcon + 4);
> +
> + data = VIDTCON2_LINEVAL(vmode->yres - 1) |
> + VIDTCON2_HOZVAL(vmode->xres - 1);
> + writel(data, regs + sfb->variant.vidtcon + 8);
> +}
> +
> +/**
> * s3c_fb_clear_win() - clear hardware window registers.
> * @sfb: The base resources for the hardware.
> * @win: The window to process.
> @@ -1473,15 +1482,14 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> writel(0xffffff, regs + WKEYCON1);
> }
>
> + s3c_fb_set_rgb_timing(sfb);
> +
This s3c_fb_set_rgb_timing(sfb) should be added to s3c_fb_resume().
The timing registers should be set when s3c_fb_resume() is called.
If not, after resuming, timing registers such as VIDTCONx will not bet set.
> /* we have the register setup, start allocating framebuffers */
>
> for (win = 0; win < fbdrv->variant.nr_windows; win++) {
> if (!pd->win[win])
> continue;
>
> - if (!pd->win[win]->win_mode.pixclock)
> - s3c_fb_missing_pixclock(&pd->win[win]->win_mode);
> -
> ret = s3c_fb_probe_win(sfb, win, fbdrv->win[win],
> &sfb->windows[win]);
> if (ret < 0) {
> --
> 1.6.6.rc2
^ permalink raw reply
* [PATCH] MAINTAINERS: add entry for exynos mipi display drivers
From: Donghwa Lee @ 2012-03-06 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F2667EE.2090902@samsung.com>
Hi, I'd like to add Inki Dae, Donghwa Lee and Kyungmin Park as
maintainers who developers for exynos mipi display drivers for
video/driver/exynos/exynos_mipi* and include/video/exynos_mipi*.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
MAINTAINERS | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b087b3bc..eb5fbcb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2351,6 +2351,15 @@ S: Supported
F: drivers/gpu/drm/exynos
F: include/drm/exynos*
+EXYNOS MIPI DISPLAY DRIVERS
+M: Inki Dae <inki.dae@samsung.com>
+M: Donghwa Lee <dh09.lee@samsung.com>
+M: Kyungmin Park <kyungmin.park@samsung.com>
+L: linux-fbdev@vger.kernel.org
+S: Maintained
+F: drivers/video/exynos/exynos_mipi*
+F: include/video/exynos_mipi*
+
DSCC4 DRIVER
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-06 1:23 UTC (permalink / raw)
To: linux-fbdev
MERAM can be used for other IP blocks as well in the future.
It doesn't necessarily mean that the MERAM driver depends on the LCDC.
This patch corrects dependency.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v2 -> v3
- move config FB_SH_MOBILE_MERAM out of "choice"
drivers/video/Kconfig | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8951cbd..36e8b06 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
---help---
Driver for the on-chip SH-Mobile HDMI controller.
-config FB_SH_MOBILE_MERAM
- tristate "SuperH Mobile MERAM read ahead support for LCDC"
- depends on FB_SH_MOBILE_LCDC
- default y
- ---help---
- Enable MERAM support for the SH-Mobile LCD controller.
-
- This will allow for caching of the framebuffer to provide more
- reliable access under heavy main memory bus traffic situations.
- Up to 4 memory channels can be configured, allowing 4 RGB or
- 2 YCbCr framebuffers to be configured.
-
config FB_TMIO
tristate "Toshiba Mobile IO FrameBuffer support"
depends on FB && MFD_CORE
@@ -2332,6 +2320,17 @@ config FB_MB862XX_LIME
endchoice
+config FB_SH_MOBILE_MERAM
+ tristate "SuperH Mobile MERAM read ahead support"
+ depends on (SUPERH || ARCH_SHMOBILE)
+ ---help---
+ Enable MERAM support for the SuperH controller.
+
+ This will allow for caching of the framebuffer to provide more
+ reliable access under heavy main memory bus traffic situations.
+ Up to 4 memory channels can be configured, allowing 4 RGB or
+ 2 YCbCr framebuffers to be configured.
+
config FB_MB862XX_I2C
bool "Support I2C bus on MB862XX GDC"
depends on FB_MB862XX && I2C
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-06 1:14 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87fwdmwozi.wl%kuninori.morimoto.gx@renesas.com>
Hi
I'm so sorry.
This patch breaks menuconfig.
Please give me v3 chance
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> This patch is v2 of [PATCH] fbdev: remove "default y" from FB_SH_MOBILE_MERAM
>
> v1 -> v2
> - corrects dependency
> - modify transfate and help too
>
> drivers/video/Kconfig | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 6ca0c40..11594ea 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2002,11 +2002,10 @@ config FB_SH_MOBILE_HDMI
> Driver for the on-chip SH-Mobile HDMI controller.
>
> config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> + Enable MERAM support for the SuperH controller.
>
> This will allow for caching of the framebuffer to provide more
> reliable access under heavy main memory bus traffic situations.
> --
> 1.7.5.4
>
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH v2] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-06 0:29 UTC (permalink / raw)
To: linux-fbdev
MERAM can be used for other IP blocks as well in the future.
It doesn't necessarily mean that the MERAM driver depends on the LCDC.
This patch corrects dependency.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
This patch is v2 of [PATCH] fbdev: remove "default y" from FB_SH_MOBILE_MERAM
v1 -> v2
- corrects dependency
- modify transfate and help too
drivers/video/Kconfig | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6ca0c40..11594ea 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2002,11 +2002,10 @@ config FB_SH_MOBILE_HDMI
Driver for the on-chip SH-Mobile HDMI controller.
config FB_SH_MOBILE_MERAM
- tristate "SuperH Mobile MERAM read ahead support for LCDC"
- depends on FB_SH_MOBILE_LCDC
- default y
+ tristate "SuperH Mobile MERAM read ahead support"
+ depends on (SUPERH || ARCH_SHMOBILE)
---help---
- Enable MERAM support for the SH-Mobile LCD controller.
+ Enable MERAM support for the SuperH controller.
This will allow for caching of the framebuffer to provide more
reliable access under heavy main memory bus traffic situations.
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] fbdev: remove "default y" from FB_SH_MOBILE_MERAM
From: Kuninori Morimoto @ 2012-03-06 0:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nu7bcd3.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent, Hayama-san
Thank you for your advice
> > On Friday 02 March 2012 01:06:53 Kuninori Morimoto wrote:
> >> "default y" of FB_SH_MOBILE_MERAM was overkill option.
> >> "depends on FB_SH_MOBILE_LCDC" is very enough here.
> >
> > Actually the sh_mobile_meram driver doesn't depend on the LCDC driver. What
> > would you think about removing both the dependency and the default=y ?
>
> I agree with Laurent here. MERAM can be used for other IP blocks as well
> in the future, e.g. the CEU driver. The LCDC was the only driver using
> it, but doesn't necessarily mean that the MERAM driver depends on the
> LCDC. In some case, you might even want to disable MERAM for the LCDC if
> there's not enough memory on MERAM.
Thanks.
I send v2 patch.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH] fbdev: remove "default y" from FB_SH_MOBILE_MERAM
From: Takanari Hayama @ 2012-03-05 22:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nu7bcd3.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent and Morimoto-san,
On 3/6/12 12:11 AM, Laurent Pinchart wrote:
> On Friday 02 March 2012 01:06:53 Kuninori Morimoto wrote:
>> "default y" of FB_SH_MOBILE_MERAM was overkill option.
>> "depends on FB_SH_MOBILE_LCDC" is very enough here.
>
> Actually the sh_mobile_meram driver doesn't depend on the LCDC driver. What
> would you think about removing both the dependency and the default=y ?
I agree with Laurent here. MERAM can be used for other IP blocks as well
in the future, e.g. the CEU driver. The LCDC was the only driver using
it, but doesn't necessarily mean that the MERAM driver depends on the
LCDC. In some case, you might even want to disable MERAM for the LCDC if
there's not enough memory on MERAM.
>
>> This patch remove it.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>> drivers/video/Kconfig | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 549b960..dfec9b7 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -1994,7 +1994,6 @@ config FB_SH_MOBILE_HDMI
>> config FB_SH_MOBILE_MERAM
>> tristate "SuperH Mobile MERAM read ahead support for LCDC"
>> depends on FB_SH_MOBILE_LCDC
>> - default y
>> ---help---
>> Enable MERAM support for the SH-Mobile LCD controller.
>
Takanari Hayama, Ph.D. (taki@igel.co.jp)
IGEL Co.,Ltd.
http://www.igel.co.jp/
^ permalink raw reply
* Re: [PATCH] fbdev: remove "default y" from FB_SH_MOBILE_MERAM
From: Laurent Pinchart @ 2012-03-05 15:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <874nu7bcd3.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thanks for the patch.
On Friday 02 March 2012 01:06:53 Kuninori Morimoto wrote:
> "default y" of FB_SH_MOBILE_MERAM was overkill option.
> "depends on FB_SH_MOBILE_LCDC" is very enough here.
Actually the sh_mobile_meram driver doesn't depend on the LCDC driver. What
would you think about removing both the dependency and the default=y ?
> This patch remove it.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> drivers/video/Kconfig | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 549b960..dfec9b7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1994,7 +1994,6 @@ config FB_SH_MOBILE_HDMI
> config FB_SH_MOBILE_MERAM
> tristate "SuperH Mobile MERAM read ahead support for LCDC"
> depends on FB_SH_MOBILE_LCDC
> - default y
> ---help---
> Enable MERAM support for the SH-Mobile LCD controller.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] fbdev: sh_mobile_meram: Implement system suspend/resume
From: Laurent Pinchart @ 2012-03-05 15:06 UTC (permalink / raw)
To: linux-fbdev
Supporting runtime PM is very nice, but that's not a reason not to
implement system suspend/resume properly.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
Thanks to Guennadi for telling me about UNIVERSAL_DEV_PM_OPS.
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index d9f7a44..82ba830 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -539,7 +539,7 @@ static struct sh_mobile_meram_ops sh_mobile_meram_ops = {
* Power management
*/
-static int sh_mobile_meram_runtime_suspend(struct device *dev)
+static int sh_mobile_meram_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct sh_mobile_meram_priv *priv = platform_get_drvdata(pdev);
@@ -563,7 +563,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
return 0;
}
-static int sh_mobile_meram_runtime_resume(struct device *dev)
+static int sh_mobile_meram_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct sh_mobile_meram_priv *priv = platform_get_drvdata(pdev);
@@ -582,10 +582,9 @@ static int sh_mobile_meram_runtime_resume(struct device *dev)
return 0;
}
-static const struct dev_pm_ops sh_mobile_meram_dev_pm_ops = {
- .runtime_suspend = sh_mobile_meram_runtime_suspend,
- .runtime_resume = sh_mobile_meram_runtime_resume,
-};
+static UNIVERSAL_DEV_PM_OPS(sh_mobile_meram_dev_pm_ops,
+ sh_mobile_meram_suspend,
+ sh_mobile_meram_resume, NULL);
/* -----------------------------------------------------------------------------
* Probe/remove and driver init/exit
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH] fbdev: sh_mobile_meram: Implement system suspend/resume
From: Laurent Pinchart @ 2012-03-05 14:53 UTC (permalink / raw)
To: linux-fbdev
Supporting runtime PM is very nice, but that's not a reason not to
implement system suspend/resume properly.
Reported-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/sh_mobile_meram.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
I'll add this patch to my LCDC patch series.
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index d9f7a44..0d9bc2d 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -539,7 +539,7 @@ static struct sh_mobile_meram_ops sh_mobile_meram_ops = {
* Power management
*/
-static int sh_mobile_meram_runtime_suspend(struct device *dev)
+static int sh_mobile_meram_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct sh_mobile_meram_priv *priv = platform_get_drvdata(pdev);
@@ -563,7 +563,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
return 0;
}
-static int sh_mobile_meram_runtime_resume(struct device *dev)
+static int sh_mobile_meram_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct sh_mobile_meram_priv *priv = platform_get_drvdata(pdev);
@@ -583,8 +583,10 @@ static int sh_mobile_meram_runtime_resume(struct device *dev)
}
static const struct dev_pm_ops sh_mobile_meram_dev_pm_ops = {
- .runtime_suspend = sh_mobile_meram_runtime_suspend,
- .runtime_resume = sh_mobile_meram_runtime_resume,
+ .suspend = sh_mobile_meram_suspend,
+ .resume = sh_mobile_meram_resume,
+ .runtime_suspend = sh_mobile_meram_suspend,
+ .runtime_resume = sh_mobile_meram_resume,
};
/* -----------------------------------------------------------------------------
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
From: Thomas Abraham @ 2012-03-05 8:24 UTC (permalink / raw)
To: Jingoo Han
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
ben-linux, patches
In-Reply-To: <006f01ccfaa1$b6ff11f0$24fd35d0$%han@samsung.com>
On 5 March 2012 12:59, Jingoo Han <jg1.han@samsung.com> wrote:
>
>
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Sunday, March 04, 2012 12:50 AM
>> To: linux-fbdev@vger.kernel.org
>> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
>> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
>> Subject: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
>>
>> This patchset rearranges the elements in the platform data of the s3c-fb
>> driver with the intent of adding device tree support to the driver in
>> subsequent patches.
>>
>> The first patch moves the video timing information from the individual window
>> setup data into the platform specific configuration section in the platform
>> data. The video timing is independent of the window setup. The resolution of
>> the window could be smaller than that of the lcd panel attached. So the video
>> timing data is removed from window configuration data.
>
> Hi, Thomas.
>
> OK, I know what you have done.
> Actually, it was my long concern.
>
> Current s3c-fb driver needs lcd panel resolutions, since each window's
> xres, yres values can be changed by fb driver or user application.
> Therefore, additional 'costant' lcd panel resolutions are necessary in order to
> set timing values.
>
> I'll review your patch.
> Thank you.
Thanks. Please let me know if you have any comments.
Regards,
Thomas.
[...]
^ permalink raw reply
* RE: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
From: Jingoo Han @ 2012-03-05 7:29 UTC (permalink / raw)
To: 'Thomas Abraham', linux-fbdev
Cc: FlorianSchandinat, linux-samsung-soc, kgene.kim, ben-linux,
patches, 'Jingoo Han'
In-Reply-To: <1330789808-8253-1-git-send-email-thomas.abraham@linaro.org>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Sunday, March 04, 2012 12:50 AM
> To: linux-fbdev@vger.kernel.org
> Cc: FlorianSchandinat@gmx.de; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com;
> jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org
> Subject: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
>
> This patchset rearranges the elements in the platform data of the s3c-fb
> driver with the intent of adding device tree support to the driver in
> subsequent patches.
>
> The first patch moves the video timing information from the individual window
> setup data into the platform specific configuration section in the platform
> data. The video timing is independent of the window setup. The resolution of
> the window could be smaller than that of the lcd panel attached. So the video
> timing data is removed from window configuration data.
Hi, Thomas.
OK, I know what you have done.
Actually, it was my long concern.
Current s3c-fb driver needs lcd panel resolutions, since each window's
xres, yres values can be changed by fb driver or user application.
Therefore, additional 'costant' lcd panel resolutions are necessary in order to
set timing values.
I'll review your patch.
Thank you.
Best regards,
Jingoo Han
>
> The second patch removes the need for the 'default_win' element in the
> platform data. This element was used to decide whether the video data
> output from the controller should be enabled or disabled when the window
> specified by 'default_win' is enabled or disabled. With the first patch
> removing the need for atleast one window to be of the same resolution as
> that of the lcd panel, it is now possible to decide when to enable/disable
> the video data output based on the state of each window. If any of the
> window is active, the lcd data output is enabled. Otherwise, the lcd data
> output is disabled. Hence, the 'default_win' parameter from the platform
> data can be removed, which anyways cannot be specified when using
> device tree.
>
> The third patch reworks the platform data of the display controller based
> on the changes introduced in the first two patches.
>
> The patchset does not include the rework of platform data of all the other
> boards which have platform data for the s3c-fb driver. I am posting this
> patchset to know if the the changes are conceptually correct. If the first
> two patches are acceptable, I will resubmit this patchset with changes to
> the platform data for all boards which have s3c-fb platform data.
>
> Thomas Abraham (3):
> video: s3c-fb: move video interface timing out of window setup data
> video: s3c-fb: remove 'default_win' element from platform data
> ARM: Exynos: Rework platform data for lcd controller for Origen board
>
> arch/arm/mach-exynos/mach-origen.c | 24 ++++---
> arch/arm/plat-samsung/include/plat/fb.h | 11 ++-
> drivers/video/s3c-fb.c | 128 ++++++++++++++----------------
> 3 files changed, 80 insertions(+), 83 deletions(-)
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Wang YanQing @ 2012-03-05 7:25 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel, spock
In-Reply-To: <4F54669E.6080009@gmx.de>
On Mon, Mar 05, 2012 at 07:09:18AM +0000, Florian Tobias Schandinat wrote:
> Hi,
>
> On 03/05/2012 12:52 AM, Wang YanQing wrote:
> > On Fri, Mar 02, 2012 at 08:48:50AM +0800, Wang YanQing wrote:
> >>
> >> Ok! I think I have learned to make thing simple and send to the right people:)
>
> That's right.
>
> >> This patch try to fix the oops below that catched in my machine
>
> This sounds like you didn't test it. I assume you did? So just write
> "This patch fixes the oops below"
Yes, I had tested it on three machines.
I think I have got a good lesson, thanks so much!
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Florian Tobias Schandinat @ 2012-03-05 7:09 UTC (permalink / raw)
To: Wang YanQing, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120305005250.GA17071@udknight>
Hi,
On 03/05/2012 12:52 AM, Wang YanQing wrote:
> On Fri, Mar 02, 2012 at 08:48:50AM +0800, Wang YanQing wrote:
>>
>> Ok! I think I have learned to make thing simple and send to the right people:)
That's right.
>> This patch try to fix the oops below that catched in my machine
This sounds like you didn't test it. I assume you did? So just write
"This patch fixes the oops below"
>>
>> [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
>> [ 81.609384] uvesafb: protected mode interface info at c000:d350
>> [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
>> [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
>> [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
>> [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
>> [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtualI15
>> [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
>> [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
>> [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
>> [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
>> [ 81.744171] Oops: 0011 [#1] SMP
>> [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
>> [ 81.744178]
>> [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
>> [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
>> [ 81.744187] EIP is at 0xc00cd3b3
>> [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
>> [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
>> [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> [ 81.744195] Process modprobe (pid: 3497, tiõ7f2000 task÷48c600 task.tiõ7f2000)
>> [ 81.744196] Stack:
>> [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
>> [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
>> [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
>> [ 81.744210] Call Trace:
>> [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
>> [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
>> [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
>> [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
>> [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
>> [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
>> [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
>> [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
>> [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
>> [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
>> [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
>> [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
>> [ 81.744258] [<c129b378>] visual_init+0xb8/0x150
>> [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
>> [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
>> [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
>> [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
>> [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
>> [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
>> [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
>> [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
>> [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
>> [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
>> [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
>> [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
>> [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
>> [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
>> [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
>> [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
>> [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
>> [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
>> [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
>> [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
>> [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
>> [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
>> [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
>> [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
>> [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
>> [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
>> [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
>> [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
>> [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
>> [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
>> [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
>> [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
>> [ 81.744391] CR2: 00000000c00cd3b3
>> [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
>>
>> Signed-off-by: Wang YanQing <udknight@gmail.com>
>> ---
>> drivers/video/uvesafb.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
>> index e7f69ef..f9a670d 100644
>> --- a/drivers/video/uvesafb.c
>> +++ b/drivers/video/uvesafb.c
>> @@ -23,6 +23,7 @@
>> #include <video/uvesafb.h>
>> #ifdef CONFIG_X86
>> #include <video/vga.h>
>> +#include <linux/pci.h>
>> #endif
>> #ifdef CONFIG_MTRR
>> #include <asm/mtrr.h>
>> @@ -815,8 +816,15 @@ static int __devinit uvesafb_vbe_init(struct fb_info *info)
>> par->pmi_setpal = pmi_setpal;
>> par->ypan = ypan;
>>
>> - if (par->pmi_setpal || par->ypan)
>> - uvesafb_vbe_getpmi(task, par);
>> + if (par->pmi_setpal || par->ypan) {
>> + if (pcibios_enabled) {
>> + uvesafb_vbe_getpmi(task, par);
>> + } else {
>> + par->pmi_setpal = par->ypan = 0;
>> + printk(KERN_WARNING "uvesafb: PCI BIOS area is NX."
>> + "Can't use protected mode interface\n");
>> + }
>> + }
>> #else
>> /* The protected mode interface is not available on non-x86. */
>> par->pmi_setpal = par->ypan = 0;
>> --
>> 1.7.9.2.315.g25a78
>
> Ok! Can anybody tell me why this patch had been ignored by community?
> I try to find out what's wrong with this patch, but I failed to find it out.
> So any comment is welcome.Thanks
Patch looks okay to me. I will wait a few days to give Michal a chance to
comment on it.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* [GIT PULL] udlfb patches for fbdev-next
From: Bernie Thompson @ 2012-03-05 2:33 UTC (permalink / raw)
To: linux-fbdev
Hi Florian,
These are udlfb patches for fbdev-next (assume 3.4; compatible with 3.3)
Testing use of github to try to make patch submission easier. 1st
time. Be kind.
Not yet on git 1.7.9 for signed requests. Happy to send github pull requests.
All 5 patches are independent of each other. Feedback welcome.
The following changes since commit 327e27681c27d3ed5ea470ec483904d1a318cb7f:
video: s3c-fb: use devm_request_irq() (2012-02-24 00:50:07 +0000)
are available in the git repository at:
git@github.com:bernieplug/linux-2.6.git fbdev-next
Ben Collins (2):
udlfb: Make sure to get correct endian keys from vendor descriptor
udlfb: Add module_param to allow forcing pixel_limit
Bernie Thompson (2):
udlfb: add maintainer
udlfb: fix hcd_buffer_free panic on unplug/replug
Martin Decky (1):
udlfb: Improve debugging printouts with refresh rate
MAINTAINERS | 9 +++
drivers/video/udlfb.c | 163 ++++++++++++++++++++++++++++--------------------
include/video/udlfb.h | 1 +
3 files changed, 105 insertions(+), 68 deletions(-)
^ permalink raw reply
* RE: [patch] backlight: s6e63m0: corruption storing gamma mode
From: Inki Dae @ 2012-03-05 1:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20120302065620.GC24508@elgon.mountain>
Acked-by: Inki Dae <inki.dae@samsung.com>
Thanks.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of Dan Carpenter
> Sent: Friday, March 02, 2012 3:56 PM
> To: Richard Purdie; InKi Dae
> Cc: Florian Tobias Schandinat; linux-fbdev@vger.kernel.org; kernel-
> janitors@vger.kernel.org
> Subject: [patch] backlight: s6e63m0: corruption storing gamma mode
>
> strict_strtoul() writes a long but ->gamma_mode only has space to store
> an int, so on 64 bit systems we end up scribbling over
> ->gamma_table_count as well. I've changed it to use kstrtouint()
> instead.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/video/backlight/s6e63m0.c
> b/drivers/video/backlight/s6e63m0.c
> index 9b0092e..e264f55 100644
> --- a/drivers/video/backlight/s6e63m0.c
> +++ b/drivers/video/backlight/s6e63m0.c
> @@ -690,7 +690,7 @@ static ssize_t s6e63m0_sysfs_store_gamma_mode(struct
> device *dev,
> struct backlight_device *bd = NULL;
> int brightness, rc;
>
> - rc = strict_strtoul(buf, 0, (unsigned long *)&lcd->gamma_mode);
> + rc = kstrtouint(buf, 0, &lcd->gamma_mode);
> if (rc < 0)
> return rc;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Wang YanQing @ 2012-03-05 0:52 UTC (permalink / raw)
To: FlorianSchandinat, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120302004850.GA4139@udknight>
On Fri, Mar 02, 2012 at 08:48:50AM +0800, Wang YanQing wrote:
>
> Ok! I think I have learned to make thing simple and send to the right people:)
> This patch try to fix the oops below that catched in my machine
>
> [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
> [ 81.609384] uvesafb: protected mode interface info at c000:d350
> [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
> [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
> [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
> [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
> [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtualI15
> [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
> [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
> [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
> [ 81.744171] Oops: 0011 [#1] SMP
> [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
> [ 81.744178]
> [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
> [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
> [ 81.744187] EIP is at 0xc00cd3b3
> [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
> [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
> [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 81.744195] Process modprobe (pid: 3497, tiõ7f2000 task÷48c600 task.tiõ7f2000)
> [ 81.744196] Stack:
> [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
> [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
> [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
> [ 81.744210] Call Trace:
> [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
> [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
> [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
> [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
> [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
> [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
> [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
> [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
> [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
> [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
> [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
> [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
> [ 81.744258] [<c129b378>] visual_init+0xb8/0x150
> [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
> [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
> [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
> [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
> [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
> [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
> [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
> [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
> [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
> [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
> [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
> [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
> [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
> [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
> [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
> [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
> [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
> [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
> [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
> [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
> [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
> [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
> [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
> [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
> [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
> [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
> [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
> [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
> [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
> [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
> [ 81.744391] CR2: 00000000c00cd3b3
> [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/uvesafb.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index e7f69ef..f9a670d 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -23,6 +23,7 @@
> #include <video/uvesafb.h>
> #ifdef CONFIG_X86
> #include <video/vga.h>
> +#include <linux/pci.h>
> #endif
> #ifdef CONFIG_MTRR
> #include <asm/mtrr.h>
> @@ -815,8 +816,15 @@ static int __devinit uvesafb_vbe_init(struct fb_info *info)
> par->pmi_setpal = pmi_setpal;
> par->ypan = ypan;
>
> - if (par->pmi_setpal || par->ypan)
> - uvesafb_vbe_getpmi(task, par);
> + if (par->pmi_setpal || par->ypan) {
> + if (pcibios_enabled) {
> + uvesafb_vbe_getpmi(task, par);
> + } else {
> + par->pmi_setpal = par->ypan = 0;
> + printk(KERN_WARNING "uvesafb: PCI BIOS area is NX."
> + "Can't use protected mode interface\n");
> + }
> + }
> #else
> /* The protected mode interface is not available on non-x86. */
> par->pmi_setpal = par->ypan = 0;
> --
> 1.7.9.2.315.g25a78
Ok! Can anybody tell me why this patch had been ignored by community?
I try to find out what's wrong with this patch, but I failed to find it out.
So any comment is welcome.Thanks
^ permalink raw reply
* Re: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
From: Thomas Abraham @ 2012-03-03 16:57 UTC (permalink / raw)
To: Mark Brown
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
jg1.han, ben-linux, patches
In-Reply-To: <20120303163000.GA1495@sirena.org.uk>
On 3 March 2012 22:00, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Mar 03, 2012 at 09:20:05PM +0530, Thomas Abraham wrote:
>> This patchset rearranges the elements in the platform data of the s3c-fb
>> driver with the intent of adding device tree support to the driver in
>> subsequent patches.
>
> It seems somewhat surprising that none of these updates touch any
> platform data for any existing machines - are no machines using any of
> the features being updated?
The third patch in this series includes platform data updates for the
Exynos4210 based Origen board. If the first two patches in this series
are acceptable, I will submit another version of this patchset which
would include updates to all existing machines that have platform data
for s3c-fb driver. I did not want to modify all the existing machines
without being sure of the acceptance of the first two patches.
Thanks,
Thomas.
^ permalink raw reply
* Re: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
From: Mark Brown @ 2012-03-03 16:49 UTC (permalink / raw)
To: Thomas Abraham
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
jg1.han, ben-linux, patches
In-Reply-To: <CAJuYYwRnB=6S6DmtMrX-S_LF9ayjFSHT=p5J8S1YyGMZkpaG9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 713 bytes --]
On Sat, Mar 03, 2012 at 10:15:32PM +0530, Thomas Abraham wrote:
> The third patch in this series includes platform data updates for the
> Exynos4210 based Origen board. If the first two patches in this series
> are acceptable, I will submit another version of this patchset which
> would include updates to all existing machines that have platform data
> for s3c-fb driver. I did not want to modify all the existing machines
> without being sure of the acceptance of the first two patches.
OK, it'd have been good to highlight that more strongly so that the
patches don't just get applied if they look OK - you did mention it but
it was buried quite far down in the cover letter and would be very easy
to miss.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] video: s3c-fb: Rearrange the elements in platform data
From: Mark Brown @ 2012-03-03 16:30 UTC (permalink / raw)
To: Thomas Abraham
Cc: linux-fbdev, FlorianSchandinat, linux-samsung-soc, kgene.kim,
jg1.han, ben-linux, patches
In-Reply-To: <1330789808-8253-1-git-send-email-thomas.abraham@linaro.org>
On Sat, Mar 03, 2012 at 09:20:05PM +0530, Thomas Abraham wrote:
> This patchset rearranges the elements in the platform data of the s3c-fb
> driver with the intent of adding device tree support to the driver in
> subsequent patches.
It seems somewhat surprising that none of these updates touch any
platform data for any existing machines - are no machines using any of
the features being updated?
^ permalink raw reply
* [PATCH 3/3] ARM: Exynos: Rework platform data for lcd controller for Origen board
From: Thomas Abraham @ 2012-03-03 15:46 UTC (permalink / raw)
To: linux-fbdev
Cc: FlorianSchandinat, linux-samsung-soc, kgene.kim, jg1.han,
ben-linux, patches
In-Reply-To: <1330789808-8253-1-git-send-email-thomas.abraham@linaro.org>
The 'default_win' element in the platform data is removed and the lcd panel
video timing values are moved out of individual window configuration data.
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
index f57aed4..dc4ecc3 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -583,22 +583,26 @@ static struct platform_device origen_lcd_hv070wsa = {
};
static struct s3c_fb_pd_win origen_fb_win0 = {
- .win_mode = {
- .left_margin = 64,
- .right_margin = 16,
- .upper_margin = 64,
- .lower_margin = 16,
- .hsync_len = 48,
- .vsync_len = 3,
- .xres = 1024,
- .yres = 600,
- },
+ .xres = 512,
+ .yres = 300,
.max_bpp = 32,
.default_bpp = 24,
};
+static struct fb_videomode lcd_hv070wsa_timing = {
+ .left_margin = 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+};
+
static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
.win[0] = &origen_fb_win0,
+ .vtiming = &lcd_hv070wsa_timing,
.vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
.vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC |
VIDCON1_INV_VCLK,
--
1.6.6.rc2
^ permalink raw reply related
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