* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-15 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F60E5C8.3040804@gmail.com>
> -----Original Message-----
> From: Darius Augulis [mailto:augulis.darius@gmail.com]
> Sent: Thursday, March 15, 2012 3:39 AM
> To: Jingoo Han
> Cc: 'Thomas Abraham'; linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-
> linux@fluff.org; patches@linaro.org; 'Kyungmin Park'; 'JeongHyeon Kim'; 'Heiko Stuebner'; 'Kwangwoo Lee';
> 'Mark Brown'; 'Peter Korsgaard'; 'Maurus Cuelenaere'
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On 03/14/2012 03:51 AM, Jingoo Han wrote:
> >> -----Original Message-----
> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >> Sent: Tuesday, March 13, 2012 7:11 PM
> >> To: Jingoo Han
> >> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org;
> linux-
> >> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
> >> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis;
> Maurus
> >> Cuelenaere
> >> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>
> >> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
> >>>> -----Original Message-----
> >>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >>>> Sent: Tuesday, March 13, 2012 6:00 AM
> >>>> To: linux-fbdev@vger.kernel.org
> >>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-
> soc@vger.kernel.org;
> >>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
> >>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> >>>> Cuelenaere
> >>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>>>
> >>>> For all the Samsung SoC based boards which have the platform data for
> >>>> s3c-fb driver, 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: Jingoo Han<jg1.han@samsung.com>
> >>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
> >>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
> >>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
> >>>> Cc: Heiko Stuebner<heiko@sntech.de>
> >>>> Cc: Ben Dooks<ben-linux@fluff.org>
> >>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
> >>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
> >>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
> >>>> Cc: Darius Augulis<augulis.darius@gmail.com>
> >>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
> >>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
> >>>> ---
> >>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
> >>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
> >>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
> >>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
> >>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
> >>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
> >>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
> >>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
> >>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
> >>>> 19 files changed, 285 insertions(+), 238 deletions(-)
> >>>>
> >>> [.....]
> >>>
> >>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> index c34c2ab..24dcdc9 100644
> >>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
> >>>>
> >>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
> >>>> {
> >>>> - .win_mode = { /* 4.3" 480x272 */
> >>>> - .left_margin = 3,
> >>>> - .right_margin = 2,
> >>>> - .upper_margin = 1,
> >>>> - .lower_margin = 1,
> >>>> - .hsync_len = 40,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 480,
> >>>> - .yres = 272,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 480,
> >>>> + .yres = 272,
> >>>> }, {
> >>>> - .win_mode = { /* 7.0" 800x480 */
> >>>> - .left_margin = 8,
> >>>> - .right_margin = 13,
> >>>> - .upper_margin = 7,
> >>>> - .lower_margin = 5,
> >>>> - .hsync_len = 3,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 800,
> >>>> - .yres = 480,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> },
> >>>> };
> >>>>
> >>>> +static struct fb_videomode mini6410_lcd_timing = {
> >>>> + .left_margin = 8,
> >>>> + .right_margin = 13,
> >>>> + .upper_margin = 7,
> >>>> + .lower_margin = 5,
> >>>> + .hsync_len = 3,
> >>>> + .vsync_len = 1,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> +};
> >>>> +
> >>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
> >>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> >>>> + .vtiming =&mini6410_lcd_timing,
> >>>> .win[0] =&mini6410_fb_win[0],
> >>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> >>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> >>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
> >>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
> >>>>
> >>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
> >>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
> >>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
> >>>> + mini6410_lcd_pdata.win[0]->xres,
> >>>> + mini6410_lcd_pdata.win[0]->yres);
> >>>>
> >>>> s3c_nand_set_platdata(&mini6410_nand_info);
> >>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
> >>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> index be2a9a2..41e4f74 100644
> >>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
> >>>>
> >>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
> >>>> {
> >>>> - .win_mode = { /* 4.3" 480x272 */
> >>>> - .left_margin = 3,
> >>>> - .right_margin = 2,
> >>>> - .upper_margin = 1,
> >>>> - .lower_margin = 1,
> >>>> - .hsync_len = 40,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 480,
> >>>> - .yres = 272,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 480,
> >>>> + .yres = 272,
> >>>> }, {
> >>>> - .win_mode = { /* 7.0" 800x480 */
> >>>> - .left_margin = 8,
> >>>> - .right_margin = 13,
> >>>> - .upper_margin = 7,
> >>>> - .lower_margin = 5,
> >>>> - .hsync_len = 3,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 800,
> >>>> - .yres = 480,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> },
> >>>> };
> >>>>
> >>>> +static struct fb_videomode real6410_lcd_timing = {
> >>>> + .left_margin = 3,
> >>>> + .right_margin = 2,
> >>>> + .upper_margin = 1,
> >>>> + .lower_margin = 1,
> >>>> + .hsync_len = 40,
> >>>> + .vsync_len = 1,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> +};
> >>>
> >>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
> >>> In my opinion, it would be good as follows:
> >>>
> >>> +static struct fb_videomode real6410_lcd_timing = {
> >>> + .left_margin = 8,
> >>> + .right_margin = 13,
> >>> + .upper_margin = 7,
> >>> + .lower_margin = 5,
> >>> + .hsync_len = 3,
> >>> + .vsync_len = 1,
> >>> + .xres = 800,
> >>> + .yres = 480,
> >>> +};
> >>>
> >>>
> >> Before this patch series, both real6410 and mini6410 had 'default_win'
> >> = 0 in the platform data. And, the s3c-fb driver selected the video
> >> timing from the window selected by the default_win parameter in s3c-fb
> >> platform data, i.e window 0 for both mini6440 and real6410. So, in
> >> this patch, while moving the timing values out of window data, the
> >> timing values for window 0 was selected.
> >>
> >> The timing value for window 1 was never used on mini6410 and real6410.
> >> So I would suggest to use timing value of window 0 in this patch.
> > OK, I see.
> > Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
> > Also, the mini6410 should use the timing value for window 0 as below.
> >
> > Also, this timing value is used for 4.3" 480x272 LCD.
> > So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
> >
> > The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
> > Please refer to 'http://www.friendlyarm.net/products/mini6410'.
> >
> > Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
> > http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
> >
> > Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
> >
> > +static struct fb_videomode mini6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 480,
> > + .yres = 272,
> > +};
> >
> > +static struct fb_videomode real6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 480,
> > + .yres = 272,
> > +};
> >
> > Darius Augulis, can you confirm it?
> > (Darius Augulis is a maintainer for real6410 and mini6410 boards.)
>
> Are you going to leave only single LCD resolution for every of two
> boards? If so, then my answer is no.
Yes, only single LCD resolution will be left.
> I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
> we have possibility to choose LCD size dynamically - leave it there.
> What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
> by board sellers - I've bought it.
OK, I see.
Both mini6410 and real6410 provide both 4.3" and 7" LCDs,
so you needs to select both LCDs.
Um, usually, single LCD is provided on the single board.
Also, the daughter board with another kind LCD can be connected to the board.
However, .win_mode is used not for LCD, but for windows of FIMD IP.
Actually, our current framework does not support to choose multi LCD,
so, I understand that you use .win_mode[1] as second LCD.
However, that's not accurate way to select multi LCD.
Thomas, can you consider Augulis's opinion?
I think that the method to select multi LCDs is necessary.
Ideal process is such as:
1. add the patch to support to select multi LCDs
2. apply above patch to make the mini6410 and real6410 to select multi LCDs.
3. apply Thomas's patchset to remove timing value from .win_mode variable.
Best regards,
Jingoo Han
>
> regards,
> Darius Augulis
>
> >
> > Best regards,
> > Jingoo Han
> >
> >> Thanks for your comments.
> >>
> >> Regards,
> >> Thomas.
> >
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-14 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSUf-gsVesduMggSuues9OLOR6DUDAAMg_tL=e3=3c0tQ@mail.gmail.com>
On 03/13/2012 12:10 PM, Thomas Abraham wrote:
> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
>>> -----Original Message-----
>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>>> Sent: Tuesday, March 13, 2012 6:00 AM
>>> To: linux-fbdev@vger.kernel.org
>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>>> Cuelenaere
>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>>
>>> For all the Samsung SoC based boards which have the platform data for
>>> s3c-fb driver, 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: Jingoo Han<jg1.han@samsung.com>
>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>> Cc: Heiko Stuebner<heiko@sntech.de>
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
>>> Cc: Darius Augulis<augulis.darius@gmail.com>
>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
>>> ---
>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
>>> 19 files changed, 285 insertions(+), 238 deletions(-)
>>>
>> [.....]
>>
>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> index c34c2ab..24dcdc9 100644
>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>>>
>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
>>> {
>>> - .win_mode = { /* 4.3" 480x272 */
>>> - .left_margin = 3,
>>> - .right_margin = 2,
>>> - .upper_margin = 1,
>>> - .lower_margin = 1,
>>> - .hsync_len = 40,
>>> - .vsync_len = 1,
>>> - .xres = 480,
>>> - .yres = 272,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 480,
>>> + .yres = 272,
>>> }, {
>>> - .win_mode = { /* 7.0" 800x480 */
>>> - .left_margin = 8,
>>> - .right_margin = 13,
>>> - .upper_margin = 7,
>>> - .lower_margin = 5,
>>> - .hsync_len = 3,
>>> - .vsync_len = 1,
>>> - .xres = 800,
>>> - .yres = 480,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 800,
>>> + .yres = 480,
>>> },
>>> };
>>>
>>> +static struct fb_videomode mini6410_lcd_timing = {
>>> + .left_margin = 8,
>>> + .right_margin = 13,
>>> + .upper_margin = 7,
>>> + .lower_margin = 5,
>>> + .hsync_len = 3,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>> +
>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>> + .vtiming =&mini6410_lcd_timing,
>>> .win[0] =&mini6410_fb_win[0],
>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
>>>
>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
>>> + mini6410_lcd_pdata.win[0]->xres,
>>> + mini6410_lcd_pdata.win[0]->yres);
>>>
>>> s3c_nand_set_platdata(&mini6410_nand_info);
>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
>>> index be2a9a2..41e4f74 100644
>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>>>
>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
>>> {
>>> - .win_mode = { /* 4.3" 480x272 */
>>> - .left_margin = 3,
>>> - .right_margin = 2,
>>> - .upper_margin = 1,
>>> - .lower_margin = 1,
>>> - .hsync_len = 40,
>>> - .vsync_len = 1,
>>> - .xres = 480,
>>> - .yres = 272,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 480,
>>> + .yres = 272,
>>> }, {
>>> - .win_mode = { /* 7.0" 800x480 */
>>> - .left_margin = 8,
>>> - .right_margin = 13,
>>> - .upper_margin = 7,
>>> - .lower_margin = 5,
>>> - .hsync_len = 3,
>>> - .vsync_len = 1,
>>> - .xres = 800,
>>> - .yres = 480,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 800,
>>> + .yres = 480,
>>> },
>>> };
>>>
>>> +static struct fb_videomode real6410_lcd_timing = {
>>> + .left_margin = 3,
>>> + .right_margin = 2,
>>> + .upper_margin = 1,
>>> + .lower_margin = 1,
>>> + .hsync_len = 40,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>
>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
>> In my opinion, it would be good as follows:
>>
>> +static struct fb_videomode real6410_lcd_timing = {
>> + .left_margin = 8,
>> + .right_margin = 13,
>> + .upper_margin = 7,
>> + .lower_margin = 5,
>> + .hsync_len = 3,
>> + .vsync_len = 1,
>> + .xres = 800,
>> + .yres = 480,
>> +};
>>
>>
> Before this patch series, both real6410 and mini6410 had 'default_win'
> = 0 in the platform data. And, the s3c-fb driver selected the video
> timing from the window selected by the default_win parameter in s3c-fb
> platform data, i.e window 0 for both mini6440 and real6410. So, in
> this patch, while moving the timing values out of window data, the
> timing values for window 0 was selected.
>
> The timing value for window 1 was never used on mini6410 and real6410.
> So I would suggest to use timing value of window 0 in this patch.
You are wrong. Please see mini6410_parse_features(). Please do not
remove second window because it could be selected via kernel parameters
dinamically. It's very useful and I spend my hours to create it.
>
> Thanks for your comments.
>
> Regards,
> Thomas.
>
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000501cd0184$f088cb20$d19a6160$%han@samsung.com>
On 03/14/2012 03:51 AM, Jingoo Han wrote:
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Tuesday, March 13, 2012 7:11 PM
>> To: Jingoo Han
>> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-
>> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
>> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>> Cuelenaere
>> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>
>> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
>>>> -----Original Message-----
>>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>>>> Sent: Tuesday, March 13, 2012 6:00 AM
>>>> To: linux-fbdev@vger.kernel.org
>>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
>>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>>>> Cuelenaere
>>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>>>
>>>> For all the Samsung SoC based boards which have the platform data for
>>>> s3c-fb driver, 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: Jingoo Han<jg1.han@samsung.com>
>>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
>>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>> Cc: Heiko Stuebner<heiko@sntech.de>
>>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
>>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
>>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
>>>> Cc: Darius Augulis<augulis.darius@gmail.com>
>>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
>>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
>>>> ---
>>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
>>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
>>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
>>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
>>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
>>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
>>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
>>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
>>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
>>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
>>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
>>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
>>>> 19 files changed, 285 insertions(+), 238 deletions(-)
>>>>
>>> [.....]
>>>
>>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> index c34c2ab..24dcdc9 100644
>>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>>>>
>>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
>>>> {
>>>> - .win_mode = { /* 4.3" 480x272 */
>>>> - .left_margin = 3,
>>>> - .right_margin = 2,
>>>> - .upper_margin = 1,
>>>> - .lower_margin = 1,
>>>> - .hsync_len = 40,
>>>> - .vsync_len = 1,
>>>> - .xres = 480,
>>>> - .yres = 272,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 480,
>>>> + .yres = 272,
>>>> }, {
>>>> - .win_mode = { /* 7.0" 800x480 */
>>>> - .left_margin = 8,
>>>> - .right_margin = 13,
>>>> - .upper_margin = 7,
>>>> - .lower_margin = 5,
>>>> - .hsync_len = 3,
>>>> - .vsync_len = 1,
>>>> - .xres = 800,
>>>> - .yres = 480,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> },
>>>> };
>>>>
>>>> +static struct fb_videomode mini6410_lcd_timing = {
>>>> + .left_margin = 8,
>>>> + .right_margin = 13,
>>>> + .upper_margin = 7,
>>>> + .lower_margin = 5,
>>>> + .hsync_len = 3,
>>>> + .vsync_len = 1,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> +};
>>>> +
>>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
>>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>>> + .vtiming =&mini6410_lcd_timing,
>>>> .win[0] =&mini6410_fb_win[0],
>>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
>>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
>>>>
>>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
>>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
>>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
>>>> + mini6410_lcd_pdata.win[0]->xres,
>>>> + mini6410_lcd_pdata.win[0]->yres);
>>>>
>>>> s3c_nand_set_platdata(&mini6410_nand_info);
>>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
>>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> index be2a9a2..41e4f74 100644
>>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>>>>
>>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
>>>> {
>>>> - .win_mode = { /* 4.3" 480x272 */
>>>> - .left_margin = 3,
>>>> - .right_margin = 2,
>>>> - .upper_margin = 1,
>>>> - .lower_margin = 1,
>>>> - .hsync_len = 40,
>>>> - .vsync_len = 1,
>>>> - .xres = 480,
>>>> - .yres = 272,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 480,
>>>> + .yres = 272,
>>>> }, {
>>>> - .win_mode = { /* 7.0" 800x480 */
>>>> - .left_margin = 8,
>>>> - .right_margin = 13,
>>>> - .upper_margin = 7,
>>>> - .lower_margin = 5,
>>>> - .hsync_len = 3,
>>>> - .vsync_len = 1,
>>>> - .xres = 800,
>>>> - .yres = 480,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> },
>>>> };
>>>>
>>>> +static struct fb_videomode real6410_lcd_timing = {
>>>> + .left_margin = 3,
>>>> + .right_margin = 2,
>>>> + .upper_margin = 1,
>>>> + .lower_margin = 1,
>>>> + .hsync_len = 40,
>>>> + .vsync_len = 1,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> +};
>>>
>>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
>>> In my opinion, it would be good as follows:
>>>
>>> +static struct fb_videomode real6410_lcd_timing = {
>>> + .left_margin = 8,
>>> + .right_margin = 13,
>>> + .upper_margin = 7,
>>> + .lower_margin = 5,
>>> + .hsync_len = 3,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>>
>>>
>> Before this patch series, both real6410 and mini6410 had 'default_win'
>> = 0 in the platform data. And, the s3c-fb driver selected the video
>> timing from the window selected by the default_win parameter in s3c-fb
>> platform data, i.e window 0 for both mini6440 and real6410. So, in
>> this patch, while moving the timing values out of window data, the
>> timing values for window 0 was selected.
>>
>> The timing value for window 1 was never used on mini6410 and real6410.
>> So I would suggest to use timing value of window 0 in this patch.
> OK, I see.
> Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
> Also, the mini6410 should use the timing value for window 0 as below.
>
> Also, this timing value is used for 4.3" 480x272 LCD.
> So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
>
> The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
> Please refer to 'http://www.friendlyarm.net/products/mini6410'.
>
> Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
> http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
>
> Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
>
> +static struct fb_videomode mini6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 480,
> + .yres = 272,
> +};
>
> +static struct fb_videomode real6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 480,
> + .yres = 272,
> +};
>
> Darius Augulis, can you confirm it?
> (Darius Augulis is a maintainer for real6410 and mini6410 boards.)
Are you going to leave only single LCD resolution for every of two
boards? If so, then my answer is no.
I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
we have possibility to choose LCD size dynamically - leave it there.
What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
by board sellers - I've bought it.
regards,
Darius Augulis
>
> Best regards,
> Jingoo Han
>
>> Thanks for your comments.
>>
>> Regards,
>> Thomas.
>
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Grazvydas Ignotas @ 2012-03-14 16:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1331724142.2386.25.camel@deskari>
On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
>> With this we can eliminate some duplicate code in panel drivers.
>> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
>> tpo-td043mtea1 gain support of timings control over sysfs.
>
> I don't like this patch.
>
> Panels usually have a single, fixed timing configuration that should be
> used, like the ones you mention above. There's no need to alter the
> timings.
But they often have a range of timings they can tolerate, and that can
be used to alter refresh rate, for example. We do that on pandora to
match graphics drawing rate (or multiples of it) to create a feeling
smoothness.
> But it's true that there's some duplicate code currently in the panel
> drivers. However, adding just simple funcs like you did in this patch
> doesn't work quite properly. There should be locking (for example to
> prevent disabling the panel while timings are being set), and currently
> the locking is panel driver specific.
ok, what about a version of this with .get_timings only then?
This should not need a lock unless panel has a set function, but in
that case panel will be expected to provide safe version of .get and
.set itself.
--
Gražvydas
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Tomi Valkeinen @ 2012-03-14 11:22 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1331551631-11420-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Hi,
On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of timings control over sysfs.
I don't like this patch.
Panels usually have a single, fixed timing configuration that should be
used, like the ones you mention above. There's no need to alter the
timings.
But it's true that there's some duplicate code currently in the panel
drivers. However, adding just simple funcs like you did in this patch
doesn't work quite properly. There should be locking (for example to
prevent disabling the panel while timings are being set), and currently
the locking is panel driver specific.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Alan Cox @ 2012-03-14 11:21 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: H. Peter Anvin, Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, linux-fbdev, x86, Andrew Morton, Wang YanQing
In-Reply-To: <4F607A18.8080004@gmx.de>
> > uvesafb could look for any PCI vga class device - which I suspect is
> > what it *should* be doing ?
>
> Would this really change depending on whether the page is NX-protected
> or not?
> Your suggestion sounds like it is about detecting whether there is any
> graphic chip present or not while the patch is about fixing an oops
> caused by NX-protection of the BIOS.
Right yes.. I misunderstood what you are trying to do. I'd assumed you
wanted to find the ROM and thus set it to the right mapping mode.
You can use set_memory_x() to mark memory executable (and _nx to set it back).
If you really need to know if NX is being used then the check
if (__supported_pte_mask & PTE_NX)
will do the trick and the variable is exported.
I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
in the arch headers.
If you go poking around pcibios values you are going to get burned if
someone is ever bored enough to make NX and PCIBIOS work together
differently.
Alan
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Florian Tobias Schandinat @ 2012-03-14 10:59 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, linux-fbdev, x86, Andrew Morton, Wang YanQing
In-Reply-To: <20120314092955.2250a782@pyramind.ukuu.org.uk>
[CC'ing Wang YanQing, the author of the patch requiring it]
On 03/14/2012 09:29 AM, Alan Cox wrote:
>>>
>>> int pcibios_enabled;
>>> +EXPORT_SYMBOL(pcibios_enabled);
>>>
>>> /* According to the BIOS specification at:
>>> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
>>
>> I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
>> symbol with a very high likelihood to be abused in strange ways.
>
> We don't need to expose it anyway
>
> uvesafb could look for any PCI vga class device - which I suspect is
> what it *should* be doing ?
Would this really change depending on whether the page is NX-protected
or not?
Your suggestion sounds like it is about detecting whether there is any
graphic chip present or not while the patch is about fixing an oops
caused by NX-protection of the BIOS.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Alan Cox @ 2012-03-14 9:29 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton
In-Reply-To: <4F5FE9AD.7000204@zytor.com>
> >
> > int pcibios_enabled;
> > +EXPORT_SYMBOL(pcibios_enabled);
> >
> > /* According to the BIOS specification at:
> > * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
>
> I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
> symbol with a very high likelihood to be abused in strange ways.
We don't need to expose it anyway
uvesafb could look for any PCI vga class device - which I suspect is
what it *should* be doing ?
Alan
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-14 6:29 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331704278.10557.190.camel@linux-s257.site>
On Wed, Mar 14, 2012 at 11:21 AM, joeyli <jlee@suse.com> wrote:
> 於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
>> Hi Joey ,
>>
>> > Per my understood, EC firmware should change brightness but didn't do
>> > that, another
>> > way is touch i915 register in _BCM.
>>
>> how do we do this ? you mean change the _BCM implementation ?
>
> "BIOS guy" should do something like this:
>
> Method (AINT, 2, NotSerialized)
> {
> ...
> If (LEqual (Arg0, One))
> {
> Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
> Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
> Store (0x02, ASLC)
> }
>
> Method (_BCM, 1, NotSerialized)
> {
> If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
> {
> AINT (One, Arg0) <== call AINT method
> Store (Arg0, BRTL)
> }
> }
>
>
> Just for reference, they should do that when EC didn't wire to
> backlight.
>
>> >
>> > Acer machine provide a broken _BCM implementation and they didn't test
>> > it.
>> >
>> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
>> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
>> > > > > directly . I will try that also.
>> > > >
>> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
>> > > > nothing?
>> > >
>> > >
>> > > No change in value when writing
>> > > to /sys/class/backlight/acpi_video0/brightness.
>> > >
>> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
>> > > in new kernel (3.3.0-rc7) , it shows following messages ,
>> > >
>> > > [ 8.350825] wmi: Mapper loaded
>> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
>> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
>> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
>> > > driver
>> > >
>> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
>> > >
>> >
>> > Yes, acer_wmi support backlight control with AMW0 interface, your
>> > machine didn't have AMW0 interface.
>> >
>> > Normally, backlight should control by standard acpi interface.
>> >
>> > > I also tried writing directly to Embedded controller register .But no
>> > > change.
>> >
>> > The machine has broken _BCM method, because EC should do something after
>> > _BCM changed EC register.
>>
>> Thanks ,
>>
>> Pradeep Subrahmanion
>
> Why they didn't find _BCM not work?
>
> My guess is:
>
> Because the backlight control is through WDDM driver on Windows platform
> but not through standard ACPI method _BCM. They only test Windows
> platform, so, they didn't find _BCM broken.
>
> And, they also didn't really follow Microsoft WDDM spec:
>
> http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
>
> Per spec,
> ODM should keep _BCM works fine for any other OS didn't support WDDM
> driver, but they didn't.
>
> At last year, I told Acer PM one time for this issue, they said will
> check but finally didn't response me.
>
>
> Thanks
> Joey Lee
>
So touching the PCI LBB register is the only feasible solution now
(even though it may not be a clean method) ?
Thanks,
Pradeep Subrahmanion
--
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] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-14 5:51 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331692996.3052.8.camel@debian.Gayathri>
於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
> Hi Joey ,
>
> > Per my understood, EC firmware should change brightness but didn't do
> > that, another
> > way is touch i915 register in _BCM.
>
> how do we do this ? you mean change the _BCM implementation ?
"BIOS guy" should do something like this:
Method (AINT, 2, NotSerialized)
{
...
If (LEqual (Arg0, One))
{
Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
Store (0x02, ASLC)
}
Method (_BCM, 1, NotSerialized)
{
If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
{
AINT (One, Arg0) <== call AINT method
Store (Arg0, BRTL)
}
}
Just for reference, they should do that when EC didn't wire to
backlight.
> >
> > Acer machine provide a broken _BCM implementation and they didn't test
> > it.
> >
> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > > > directly . I will try that also.
> > > >
> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > > > nothing?
> > >
> > >
> > > No change in value when writing
> > > to /sys/class/backlight/acpi_video0/brightness.
> > >
> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> > > in new kernel (3.3.0-rc7) , it shows following messages ,
> > >
> > > [ 8.350825] wmi: Mapper loaded
> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> > > driver
> > >
> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
> > >
> >
> > Yes, acer_wmi support backlight control with AMW0 interface, your
> > machine didn't have AMW0 interface.
> >
> > Normally, backlight should control by standard acpi interface.
> >
> > > I also tried writing directly to Embedded controller register .But no
> > > change.
> >
> > The machine has broken _BCM method, because EC should do something after
> > _BCM changed EC register.
>
> Thanks ,
>
> Pradeep Subrahmanion
Why they didn't find _BCM not work?
My guess is:
Because the backlight control is through WDDM driver on Windows platform
but not through standard ACPI method _BCM. They only test Windows
platform, so, they didn't find _BCM broken.
And, they also didn't really follow Microsoft WDDM spec:
http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
Per spec,
ODM should keep _BCM works fine for any other OS didn't support WDDM
driver, but they didn't.
At last year, I told Acer PM one time for this issue, they said will
check but finally didn't response me.
Thanks
Joey Lee
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-14 2:55 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331680373.10557.169.camel@linux-s257.site>
Hi Joey ,
> Per my understood, EC firmware should change brightness but didn't do
> that, another
> way is touch i915 register in _BCM.
how do we do this ? you mean change the _BCM implementation ?
>
> Acer machine provide a broken _BCM implementation and they didn't test
> it.
>
> > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > > directly . I will try that also.
> > >
> > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > > nothing?
> >
> >
> > No change in value when writing
> > to /sys/class/backlight/acpi_video0/brightness.
> >
> > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> > in new kernel (3.3.0-rc7) , it shows following messages ,
> >
> > [ 8.350825] wmi: Mapper loaded
> > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> > driver
> >
> > Also there was no interface inside /sys/class/backlight for acer_wmi.
> >
>
> Yes, acer_wmi support backlight control with AMW0 interface, your
> machine didn't have AMW0 interface.
>
> Normally, backlight should control by standard acpi interface.
>
> > I also tried writing directly to Embedded controller register .But no
> > change.
>
> The machine has broken _BCM method, because EC should do something after
> _BCM changed EC register.
Thanks ,
Pradeep Subrahmanion
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-14 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSUf-gsVesduMggSuues9OLOR6DUDAAMg_tL=e3=3c0tQ@mail.gmail.com>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Tuesday, March 13, 2012 7:11 PM
> To: Jingoo Han
> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> Cuelenaere
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On 13 March 2012 15:17, Jingoo Han <jg1.han@samsung.com> wrote:
> >> -----Original Message-----
> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >> Sent: Tuesday, March 13, 2012 6:00 AM
> >> To: linux-fbdev@vger.kernel.org
> >> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> >> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
> >> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> >> Cuelenaere
> >> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>
> >> For all the Samsung SoC based boards which have the platform data for
> >> s3c-fb driver, 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: Jingoo Han <jg1.han@samsung.com>
> >> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> >> Cc: JeongHyeon Kim <jhkim@insignal.co.kr>
> >> Cc: Kukjin Kim <kgene.kim@samsung.com>
> >> Cc: Heiko Stuebner <heiko@sntech.de>
> >> Cc: Ben Dooks <ben-linux@fluff.org>
> >> Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com>
> >> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> >> Cc: Peter Korsgaard <jacmet@sunsite.dk>
> >> Cc: Darius Augulis <augulis.darius@gmail.com>
> >> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com>
> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> >> ---
> >> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
> >> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
> >> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
> >> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
> >> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
> >> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
> >> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
> >> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
> >> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
> >> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
> >> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
> >> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
> >> 19 files changed, 285 insertions(+), 238 deletions(-)
> >>
> >
> > [.....]
> >
> >> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> index c34c2ab..24dcdc9 100644
> >> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
> >>
> >> static struct s3c_fb_pd_win mini6410_fb_win[] = {
> >> {
> >> - .win_mode = { /* 4.3" 480x272 */
> >> - .left_margin = 3,
> >> - .right_margin = 2,
> >> - .upper_margin = 1,
> >> - .lower_margin = 1,
> >> - .hsync_len = 40,
> >> - .vsync_len = 1,
> >> - .xres = 480,
> >> - .yres = 272,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 480,
> >> + .yres = 272,
> >> }, {
> >> - .win_mode = { /* 7.0" 800x480 */
> >> - .left_margin = 8,
> >> - .right_margin = 13,
> >> - .upper_margin = 7,
> >> - .lower_margin = 5,
> >> - .hsync_len = 3,
> >> - .vsync_len = 1,
> >> - .xres = 800,
> >> - .yres = 480,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 800,
> >> + .yres = 480,
> >> },
> >> };
> >>
> >> +static struct fb_videomode mini6410_lcd_timing = {
> >> + .left_margin = 8,
> >> + .right_margin = 13,
> >> + .upper_margin = 7,
> >> + .lower_margin = 5,
> >> + .hsync_len = 3,
> >> + .vsync_len = 1,
> >> + .xres = 800,
> >> + .yres = 480,
> >> +};
> >> +
> >> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
> >> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> >> + .vtiming = &mini6410_lcd_timing,
> >> .win[0] = &mini6410_fb_win[0],
> >> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> >> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> >> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
> >> mini6410_lcd_pdata.win[0] = &mini6410_fb_win[features.lcd_index];
> >>
> >> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
> >> - mini6410_lcd_pdata.win[0]->win_mode.xres,
> >> - mini6410_lcd_pdata.win[0]->win_mode.yres);
> >> + mini6410_lcd_pdata.win[0]->xres,
> >> + mini6410_lcd_pdata.win[0]->yres);
> >>
> >> s3c_nand_set_platdata(&mini6410_nand_info);
> >> s3c_fb_set_platdata(&mini6410_lcd_pdata);
> >> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
> >> index be2a9a2..41e4f74 100644
> >> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> >> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> >> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
> >>
> >> static struct s3c_fb_pd_win real6410_fb_win[] = {
> >> {
> >> - .win_mode = { /* 4.3" 480x272 */
> >> - .left_margin = 3,
> >> - .right_margin = 2,
> >> - .upper_margin = 1,
> >> - .lower_margin = 1,
> >> - .hsync_len = 40,
> >> - .vsync_len = 1,
> >> - .xres = 480,
> >> - .yres = 272,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 480,
> >> + .yres = 272,
> >> }, {
> >> - .win_mode = { /* 7.0" 800x480 */
> >> - .left_margin = 8,
> >> - .right_margin = 13,
> >> - .upper_margin = 7,
> >> - .lower_margin = 5,
> >> - .hsync_len = 3,
> >> - .vsync_len = 1,
> >> - .xres = 800,
> >> - .yres = 480,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 800,
> >> + .yres = 480,
> >> },
> >> };
> >>
> >> +static struct fb_videomode real6410_lcd_timing = {
> >> + .left_margin = 3,
> >> + .right_margin = 2,
> >> + .upper_margin = 1,
> >> + .lower_margin = 1,
> >> + .hsync_len = 40,
> >> + .vsync_len = 1,
> >> + .xres = 800,
> >> + .yres = 480,
> >> +};
> >
> >
> > What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
> > In my opinion, it would be good as follows:
> >
> > +static struct fb_videomode real6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 800,
> > + .yres = 480,
> > +};
> >
> >
>
> Before this patch series, both real6410 and mini6410 had 'default_win'
> = 0 in the platform data. And, the s3c-fb driver selected the video
> timing from the window selected by the default_win parameter in s3c-fb
> platform data, i.e window 0 for both mini6440 and real6410. So, in
> this patch, while moving the timing values out of window data, the
> timing values for window 0 was selected.
>
> The timing value for window 1 was never used on mini6410 and real6410.
> So I would suggest to use timing value of window 0 in this patch.
OK, I see.
Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
Also, the mini6410 should use the timing value for window 0 as below.
Also, this timing value is used for 4.3" 480x272 LCD.
So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
Please refer to 'http://www.friendlyarm.net/products/mini6410'.
Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
+static struct fb_videomode mini6410_lcd_timing = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 480,
+ .yres = 272,
+};
+static struct fb_videomode real6410_lcd_timing = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 480,
+ .yres = 272,
+};
Darius Augulis, can you confirm it?
(Darius Augulis is a maintainer for real6410 and mini6410 boards.)
Best regards,
Jingoo Han
>
> Thanks for your comments.
>
> Regards,
> Thomas.
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: H. Peter Anvin @ 2012-03-14 0:43 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Michal Januszewski,
Florian Tobias Schandinat, linux-fbdev, x86, Andrew Morton
In-Reply-To: <4F5FAE63.3090908@xenotime.net>
On 03/13/2012 01:30 PM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Export 'pcibios_enabled' so that when uvesafb is built as a
> loadable module (on X86_32), the build will succeed.
>
> ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Michal Januszewski <spock@gentoo.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: x86@kernel.org
> ---
> Applies to mainline; found in linux-next.
>
> arch/x86/pci/pcbios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> +++ linux-next-20120313/arch/x86/pci/pcbios.c
> @@ -27,6 +27,7 @@
> #define PCIBIOS_HW_TYPE2_SPEC 0x20
>
> int pcibios_enabled;
> +EXPORT_SYMBOL(pcibios_enabled);
>
> /* According to the BIOS specification at:
> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
symbol with a very high likelihood to be abused in strange ways.
-hpa
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-13 23:12 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331688294.2577.19.camel@debian.Gayathri>
Hi Pradeep,
於 二，2012-03-13 於 21:24 -0400，Pradeep Subrahmanion 提到：
> On Tue, 2012-03-13 at 13:34 +0000, Matthew Garrett wrote:
> > On Tue, Mar 13, 2012 at 06:56:16PM +0530, Pradeep Subrahmanion wrote:
> > > I tried giving acpi_backlight = vendor . In that case hot key for
> > > brightness control is working. But i think , it is not calculating the
> > > correct value for brightness because increasing brightness after maximum
> > > level gives blank screen .
> >
> > Which backlight device appears then?
> >
>
> 'intel_backlight' appears when i gave option acpi_backlight = vendor. Writing to /sys/class/backlight/intel_backlight/brightness
>
> does not cause any change in brightness.
>
The above command not work, that means EC didn't change backlight
value:
Method (_BCM, 1, NotSerialized)
{
Divide (Arg0, 0x0A, Local0, Local1)
Decrement (Local1)
Store (Local1, ^^^^LPC.EC0.BRTS) <== write backlight value to EC
register
}
Per my understood, EC firmware should change brightness but didn't do
that, another
way is touch i915 register in _BCM.
Acer machine provide a broken _BCM implementation and they didn't test
it.
> > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > directly . I will try that also.
> >
> > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > nothing?
>
>
> No change in value when writing
> to /sys/class/backlight/acpi_video0/brightness.
>
> Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> in new kernel (3.3.0-rc7) , it shows following messages ,
>
> [ 8.350825] wmi: Mapper loaded
> [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> driver
>
> Also there was no interface inside /sys/class/backlight for acer_wmi.
>
Yes, acer_wmi support backlight control with AMW0 interface, your
machine didn't have AMW0 interface.
Normally, backlight should control by standard acpi interface.
> I also tried writing directly to Embedded controller register .But no
> change.
The machine has broken _BCM method, because EC should do something after
_BCM changed EC register.
> ----
>
> Thanks ,
>
> Pradeep Subrahmanion
>
Thanks a lot!
Joey Lee
^ permalink raw reply
* [PATCH] x86: export 'pcibios_enabled'
From: Randy Dunlap @ 2012-03-13 20:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, Michal Januszewski, Florian Tobias Schandinat,
linux-fbdev, x86, Andrew Morton
In-Reply-To: <20120313204114.e160849af7dbe5a4b4e5c0ad@canb.auug.org.au>
From: Randy Dunlap <rdunlap@xenotime.net>
Export 'pcibios_enabled' so that when uvesafb is built as a
loadable module (on X86_32), the build will succeed.
ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Michal Januszewski <spock@gentoo.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: x86@kernel.org
---
Applies to mainline; found in linux-next.
arch/x86/pci/pcbios.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20120313.orig/arch/x86/pci/pcbios.c
+++ linux-next-20120313/arch/x86/pci/pcbios.c
@@ -27,6 +27,7 @@
#define PCIBIOS_HW_TYPE2_SPEC 0x20
int pcibios_enabled;
+EXPORT_SYMBOL(pcibios_enabled);
/* According to the BIOS specification at:
* http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-13 15:49 UTC (permalink / raw)
To: Matthew Garrett
Cc: rpurdie, FlorianSchandinat, akpm, linux-fbdev, linux-kernel
In-Reply-To: <20120313133458.GA11574@srcf.ucam.org>
On Tue, 2012-03-13 at 13:34 +0000, Matthew Garrett wrote:
> On Tue, Mar 13, 2012 at 06:56:16PM +0530, Pradeep Subrahmanion wrote:
> > I tried giving acpi_backlight = vendor . In that case hot key for
> > brightness control is working. But i think , it is not calculating the
> > correct value for brightness because increasing brightness after maximum
> > level gives blank screen .
>
> Which backlight device appears then?
>
'intel_backlight' appears when i gave option acpi_backlight = vendor. Writing to /sys/class/backlight/intel_backlight/brightness
does not cause any change in brightness.
> > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > directly . I will try that also.
>
> So writing values into /sys/class/backlight/acpi_video0/brightness does
> nothing?
No change in value when writing
to /sys/class/backlight/acpi_video0/brightness.
Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
in new kernel (3.3.0-rc7) , it shows following messages ,
[ 8.350825] wmi: Mapper loaded
[ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
[ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
[ 10.396385] acer_wmi: Brightness must be controlled by generic video
driver
Also there was no interface inside /sys/class/backlight for acer_wmi.
I also tried writing directly to Embedded controller register .But no
change.
----
Thanks ,
Pradeep Subrahmanion
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-13 13:41 UTC (permalink / raw)
To: Matthew Garrett
Cc: rpurdie, FlorianSchandinat, akpm, linux-fbdev, linux-kernel
In-Reply-To: <20120313124738.GB10822@srcf.ucam.org>
I tried giving acpi_backlight = vendor . In that case hot key for
brightness control is working. But i think , it is not calculating
the correct value for brightness because increasing brightness after
maximum level gives blank screen .
I also had tried 'acpi_backlight = acer_wmi' as the boot parameter
earlier . In that case , the driver cannot find any acpi_wmi device
(showed error while booting).
By ' ACPI interface' , I mean 'acpi_video0' inside the
/sys/class/backlight. I havn't tried the /sys/class/backlight
interface directly . I will try that also.
Thanks ,
Pradeep Subrahmanion.
On Tue, Mar 13, 2012 at 6:17 PM, Matthew Garrett <mjg@redhat.com> wrote:
>
> On Tue, Mar 13, 2012 at 08:09:52AM -0400, Pradeep Subrahmanion wrote:
> > Before taking this approach , I had a look at the WMI interface.But I found from acer-acpi site that , the 4730 series
> > is using new WMI interface which needs to be reverse engineered.
> > As far as acpi interface is concerned , by default it is not at all causing any change in brightness.
> > When 'acpi_osi=Linux' was added to the boot grub config , the brightness control with hot key started to work .
> > But it was not changing to correct values. Increasing brightness after maximum level gives blank screen.
>
> That page was last updated in 2009. Have you tried the current acer-wmi
> code? You'd probably need to pass backlight=vendor if there's a
> non-working ACPI interface.
>
> When you say the ACPI interface doesn't work, what do you mean? Have you
> tried using the /sys/class/backlight interface directly?
>
> --
> Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Matthew Garrett @ 2012-03-13 13:34 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: rpurdie, FlorianSchandinat, akpm, linux-fbdev, linux-kernel
In-Reply-To: <CABNxG=Dqg26EHmC3vibf3-SjVhby1qgQfMniQObUeh9eJ6SwEw@mail.gmail.com>
On Tue, Mar 13, 2012 at 06:56:16PM +0530, Pradeep Subrahmanion wrote:
> I tried giving acpi_backlight = vendor . In that case hot key for
> brightness control is working. But i think , it is not calculating the
> correct value for brightness because increasing brightness after maximum
> level gives blank screen .
Which backlight device appears then?
> By ' ACPI interface' , I mean 'acpi_video0' inside the
> /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> directly . I will try that also.
So writing values into /sys/class/backlight/acpi_video0/brightness does
nothing?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH v2 2/2] fbdev: da8xx: add support for SP10Q010 display
From: Anatolij Gustschin @ 2012-03-13 13:13 UTC (permalink / raw)
To: linux-fbdev
Add timing data for Hitachi SP10Q010 display and allow configuration
of the 4bpp palette. For 4bpp framebuffer enable reversed order of
pixels in a byte. This requires defining FB_CFB_REV_PIXELS_IN_BYTE
and additionally setting var.nonstd to the value FB_NONSTD_REV_PIX_IN_B.
Note that it is not enough to set da8xx_fb_var.nonstd to this value
statically, since FBIOPUT_VSCREENINFO ioctl might pass var struct with
.nonstd field set to zero or another value. Therefore this setting must
be adjusted in fb_check_var() according to the requested bpp value.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Manjunathappa, Prakash <prakash.pm@ti.com>
---
v2:
- rebased on fbdev-next branch
drivers/video/Kconfig | 1 +
drivers/video/da8xx-fb.c | 38 +++++++++++++++++++++++++++++++++++++-
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8951cbd..58ea0be 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2245,6 +2245,7 @@ config FB_DA8XX
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_CFB_REV_PIXELS_IN_BYTE
---help---
This is the frame buffer device driver for the TI LCD controller
found on DA8xx/OMAP-L1xx SoCs.
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 8f7e051..47118c7 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -239,6 +239,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 7833600,
.invert_pxl_clk = 0,
},
+ [2] = {
+ /* Hitachi SP10Q010 */
+ .name = "SP10Q010",
+ .width = 320,
+ .height = 240,
+ .hfp = 10,
+ .hbp = 10,
+ .hsw = 10,
+ .vfp = 10,
+ .vbp = 10,
+ .vsw = 10,
+ .pxl_clk = 7833600,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
@@ -547,7 +561,26 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
if (info->fix.visual = FB_VISUAL_DIRECTCOLOR)
return 1;
- if (info->var.bits_per_pixel = 8) {
+ if (info->var.bits_per_pixel = 4) {
+ if (regno > 15)
+ return 1;
+
+ if (info->var.grayscale) {
+ pal = regno;
+ } else {
+ red >>= 4;
+ green >>= 8;
+ blue >>= 12;
+
+ pal = (red & 0x0f00);
+ pal |= (green & 0x00f0);
+ pal |= (blue & 0x000f);
+ }
+ if (regno = 0)
+ pal |= 0x2000;
+ palette[regno] = pal;
+
+ } else if (info->var.bits_per_pixel = 8) {
red >>= 4;
green >>= 8;
blue >>= 12;
@@ -802,6 +835,7 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->blue.length = 8;
var->transp.offset = 0;
var->transp.length = 0;
+ var->nonstd = 0;
break;
case 4:
var->red.offset = 0;
@@ -812,6 +846,7 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->blue.length = 4;
var->transp.offset = 0;
var->transp.length = 0;
+ var->nonstd = FB_NONSTD_REV_PIX_IN_B;
break;
case 16: /* RGB 565 */
var->red.offset = 11;
@@ -822,6 +857,7 @@ static int fb_check_var(struct fb_var_screeninfo *var,
var->blue.length = 5;
var->transp.offset = 0;
var->transp.length = 0;
+ var->nonstd = 0;
break;
default:
err = -EINVAL;
--
1.7.1
^ permalink raw reply related
* [PATCH v2 1/2] fbdev: da8xx:: fix reporting of the display timing info
From: Anatolij Gustschin @ 2012-03-13 13:13 UTC (permalink / raw)
To: linux-fbdev
Timing info is not properly reported by the driver, e.g.:
$ fbset -i
mode "480x272-35"
# D: 7.895 MHz, H: 12.165 kHz, V: 35.158 Hz
geometry 480 272 480 544 16
timings 126666 64 64 32 32 41 10
According to the timing values defined for LK043T1DG01 display
it should be reported as:
mode "480x272-53"
# D: 7.895 MHz, H: 15.038 kHz, V: 52.579 Hz
geometry 480 272 480 544 16
timings 126666 2 2 2 2 41 10
Initialize additional fb_var_screeninfo fields so fix this problem.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Manjunathappa, Prakash <prakash.pm@ti.com>
---
v2:
- removed pixclock setting as it is already done in fbdev-next
- rebased on fbdev-next branch
drivers/video/da8xx-fb.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index dd80386..8f7e051 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1231,6 +1231,10 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_var.hsync_len = lcdc_info->hsw;
da8xx_fb_var.vsync_len = lcdc_info->vsw;
+ da8xx_fb_var.right_margin = lcdc_info->hfp;
+ da8xx_fb_var.left_margin = lcdc_info->hbp;
+ da8xx_fb_var.lower_margin = lcdc_info->vfp;
+ da8xx_fb_var.upper_margin = lcdc_info->vbp;
da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
/* Initialize fbinfo */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Matthew Garrett @ 2012-03-13 12:47 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: rpurdie, FlorianSchandinat, akpm, linux-fbdev, linux-kernel
In-Reply-To: <1331640592.3485.50.camel@debian.Gayathri>
On Tue, Mar 13, 2012 at 08:09:52AM -0400, Pradeep Subrahmanion wrote:
> Before taking this approach , I had a look at the WMI interface.But I found from acer-acpi site that , the 4730 series
> is using new WMI interface which needs to be reverse engineered.
> As far as acpi interface is concerned , by default it is not at all causing any change in brightness.
> When 'acpi_osi=Linux' was added to the boot grub config , the brightness control with hot key started to work .
> But it was not changing to correct values. Increasing brightness after maximum level gives blank screen.
That page was last updated in 2009. Have you tried the current acer-wmi
code? You'd probably need to pass backlight=vendor if there's a
non-working ACPI interface.
When you say the ACPI interface doesn't work, what do you mean? Have you
tried using the /sys/class/backlight interface directly?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Archit Taneja @ 2012-03-13 12:25 UTC (permalink / raw)
To: Grazvydas Ignotas, Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1331551631-11420-1-git-send-email-notasas@gmail.com>
On Monday 12 March 2012 04:57 PM, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of timings control over sysfs.
>
> Signed-off-by: Grazvydas Ignotas<notasas@gmail.com>
> ---
> drivers/video/omap2/displays/panel-acx565akm.c | 15 -------------
> drivers/video/omap2/displays/panel-generic-dpi.c | 22 -------------------
> drivers/video/omap2/displays/panel-n8x0.c | 8 -------
> drivers/video/omap2/displays/panel-taal.c | 8 -------
> drivers/video/omap2/dss/core.c | 6 +++++
> drivers/video/omap2/dss/display.c | 25 ++++++++++++++++++++++
> drivers/video/omap2/dss/venc.c | 7 ------
> include/video/omapdss.h | 6 +++++
> 8 files changed, 37 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
> index dbd59b8..be83eed 100644
> --- a/drivers/video/omap2/displays/panel-acx565akm.c
> +++ b/drivers/video/omap2/displays/panel-acx565akm.c
> @@ -738,19 +738,6 @@ static void acx_panel_set_timings(struct omap_dss_device *dssdev,
> }
> }
>
> -static void acx_panel_get_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - *timings = dssdev->panel.timings;
> -}
> -
> -static int acx_panel_check_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - return 0;
> -}
> -
> -
> static struct omap_dss_driver acx_panel_driver = {
> .probe = acx_panel_probe,
> .remove = acx_panel_remove,
> @@ -761,8 +748,6 @@ static struct omap_dss_driver acx_panel_driver = {
> .resume = acx_panel_resume,
>
> .set_timings = acx_panel_set_timings,
> - .get_timings = acx_panel_get_timings,
> - .check_timings = acx_panel_check_timings,
>
> .get_recommended_bpp = acx_get_recommended_bpp,
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
> index 519c47d..45a46af 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -454,24 +454,6 @@ static int generic_dpi_panel_resume(struct omap_dss_device *dssdev)
> return 0;
> }
>
> -static void generic_dpi_panel_set_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - dpi_set_timings(dssdev, timings);
> -}
> -
> -static void generic_dpi_panel_get_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - *timings = dssdev->panel.timings;
> -}
> -
> -static int generic_dpi_panel_check_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - return dpi_check_timings(dssdev, timings);
> -}
> -
> static struct omap_dss_driver dpi_driver = {
> .probe = generic_dpi_panel_probe,
> .remove = __exit_p(generic_dpi_panel_remove),
> @@ -481,10 +463,6 @@ static struct omap_dss_driver dpi_driver = {
> .suspend = generic_dpi_panel_suspend,
> .resume = generic_dpi_panel_resume,
>
> - .set_timings = generic_dpi_panel_set_timings,
> - .get_timings = generic_dpi_panel_get_timings,
> - .check_timings = generic_dpi_panel_check_timings,
> -
> .driver = {
> .name = "generic_dpi_panel",
> .owner = THIS_MODULE,
> diff --git a/drivers/video/omap2/displays/panel-n8x0.c b/drivers/video/omap2/displays/panel-n8x0.c
> index 150e8ba..eba98a0 100644
> --- a/drivers/video/omap2/displays/panel-n8x0.c
> +++ b/drivers/video/omap2/displays/panel-n8x0.c
> @@ -610,12 +610,6 @@ static int n8x0_panel_resume(struct omap_dss_device *dssdev)
> return 0;
> }
>
> -static void n8x0_panel_get_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - *timings = dssdev->panel.timings;
> -}
> -
> static void n8x0_panel_get_resolution(struct omap_dss_device *dssdev,
> u16 *xres, u16 *yres)
> {
> @@ -678,8 +672,6 @@ static struct omap_dss_driver n8x0_panel_driver = {
> .get_resolution = n8x0_panel_get_resolution,
> .get_recommended_bpp = omapdss_default_get_recommended_bpp,
>
> - .get_timings = n8x0_panel_get_timings,
> -
> .driver = {
> .name = "n8x0_panel",
> .owner = THIS_MODULE,
> diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c
> index 80c3f6a..174c004 100644
> --- a/drivers/video/omap2/displays/panel-taal.c
> +++ b/drivers/video/omap2/displays/panel-taal.c
> @@ -583,12 +583,6 @@ static const struct backlight_ops taal_bl_ops = {
> .update_status = taal_bl_update_status,
> };
>
> -static void taal_get_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - *timings = dssdev->panel.timings;
> -}
> -
> static void taal_get_resolution(struct omap_dss_device *dssdev,
> u16 *xres, u16 *yres)
> {
> @@ -1899,8 +1893,6 @@ static struct omap_dss_driver taal_driver = {
> .run_test = taal_run_test,
> .memory_read = taal_memory_read,
>
> - .get_timings = taal_get_timings,
> -
> .driver = {
> .name = "taal",
> .owner = THIS_MODULE,
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 86ec12e..9dc0c10 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -434,6 +434,12 @@ int omap_dss_register_driver(struct omap_dss_driver *dssdriver)
> if (dssdriver->get_recommended_bpp = NULL)
> dssdriver->get_recommended_bpp > omapdss_default_get_recommended_bpp;
> + if (dssdriver->set_timings = NULL)
> + dssdriver->set_timings = omapdss_default_set_timings;
> + if (dssdriver->get_timings = NULL)
> + dssdriver->get_timings = omapdss_default_get_timings;
> + if (dssdriver->check_timings = NULL)
> + dssdriver->check_timings = omapdss_default_check_timings;
>
> return driver_register(&dssdriver->driver);
> }
> diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
> index be331dc..0d724a4 100644
> --- a/drivers/video/omap2/dss/display.c
> +++ b/drivers/video/omap2/dss/display.c
> @@ -318,6 +318,31 @@ int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev)
> }
> EXPORT_SYMBOL(omapdss_default_get_recommended_bpp);
>
> +void omapdss_default_set_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings)
> +{
> + if (dssdev->type = OMAP_DISPLAY_TYPE_DPI)
> + dpi_set_timings(dssdev, timings);
> +}
> +EXPORT_SYMBOL(omapdss_default_set_timings);
> +
> +void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings)
> +{
> + *timings = dssdev->panel.timings;
> +}
> +EXPORT_SYMBOL(omapdss_default_get_timings);
> +
> +int omapdss_default_check_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings)
> +{
> + if (dssdev->type = OMAP_DISPLAY_TYPE_DPI)
> + return dpi_check_timings(dssdev, timings);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(omapdss_default_check_timings);
This looks fine to me. We could add check/set timings for other
interfaces, if needed. Ack from me. Tomi needs to have a look at it.
Archit
> +
> /* Checks if replication logic should be used. Only use for active matrix,
> * when overlay is in RGB12U or RGB16 mode, and LCD interface is
> * 18bpp or 24bpp */
> diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
> index 7bb6219..dee2ec4 100644
> --- a/drivers/video/omap2/dss/venc.c
> +++ b/drivers/video/omap2/dss/venc.c
> @@ -557,12 +557,6 @@ static int venc_panel_resume(struct omap_dss_device *dssdev)
> return venc_panel_enable(dssdev);
> }
>
> -static void venc_get_timings(struct omap_dss_device *dssdev,
> - struct omap_video_timings *timings)
> -{
> - *timings = dssdev->panel.timings;
> -}
> -
> static void venc_set_timings(struct omap_dss_device *dssdev,
> struct omap_video_timings *timings)
> {
> @@ -641,7 +635,6 @@ static struct omap_dss_driver venc_driver = {
> .get_resolution = omapdss_default_get_resolution,
> .get_recommended_bpp = omapdss_default_get_recommended_bpp,
>
> - .get_timings = venc_get_timings,
> .set_timings = venc_set_timings,
> .check_timings = venc_check_timings,
>
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 378c7ed..ff1dacd 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -646,6 +646,12 @@ struct omap_overlay *omap_dss_get_overlay(int num);
> void omapdss_default_get_resolution(struct omap_dss_device *dssdev,
> u16 *xres, u16 *yres);
> int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);
> +void omapdss_default_set_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings);
> +void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings);
> +int omapdss_default_check_timings(struct omap_dss_device *dssdev,
> + struct omap_video_timings *timings);
>
> typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
> int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Thomas Abraham @ 2012-03-13 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002f01cd00fe$5df84fa0$19e8eee0$%han@samsung.com>
On 13 March 2012 15:17, Jingoo Han <jg1.han@samsung.com> wrote:
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Tuesday, March 13, 2012 6:00 AM
>> To: linux-fbdev@vger.kernel.org
>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>> Cuelenaere
>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>
>> For all the Samsung SoC based boards which have the platform data for
>> s3c-fb driver, 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: Jingoo Han <jg1.han@samsung.com>
>> Cc: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: JeongHyeon Kim <jhkim@insignal.co.kr>
>> Cc: Kukjin Kim <kgene.kim@samsung.com>
>> Cc: Heiko Stuebner <heiko@sntech.de>
>> Cc: Ben Dooks <ben-linux@fluff.org>
>> Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com>
>> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
>> Cc: Peter Korsgaard <jacmet@sunsite.dk>
>> Cc: Darius Augulis <augulis.darius@gmail.com>
>> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com>
>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>> ---
>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
>> 19 files changed, 285 insertions(+), 238 deletions(-)
>>
>
> [.....]
>
>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
>> index c34c2ab..24dcdc9 100644
>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>>
>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
>> {
>> - .win_mode = { /* 4.3" 480x272 */
>> - .left_margin = 3,
>> - .right_margin = 2,
>> - .upper_margin = 1,
>> - .lower_margin = 1,
>> - .hsync_len = 40,
>> - .vsync_len = 1,
>> - .xres = 480,
>> - .yres = 272,
>> - },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> + .xres = 480,
>> + .yres = 272,
>> }, {
>> - .win_mode = { /* 7.0" 800x480 */
>> - .left_margin = 8,
>> - .right_margin = 13,
>> - .upper_margin = 7,
>> - .lower_margin = 5,
>> - .hsync_len = 3,
>> - .vsync_len = 1,
>> - .xres = 800,
>> - .yres = 480,
>> - },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> + .xres = 800,
>> + .yres = 480,
>> },
>> };
>>
>> +static struct fb_videomode mini6410_lcd_timing = {
>> + .left_margin = 8,
>> + .right_margin = 13,
>> + .upper_margin = 7,
>> + .lower_margin = 5,
>> + .hsync_len = 3,
>> + .vsync_len = 1,
>> + .xres = 800,
>> + .yres = 480,
>> +};
>> +
>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>> + .vtiming = &mini6410_lcd_timing,
>> .win[0] = &mini6410_fb_win[0],
>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
>> mini6410_lcd_pdata.win[0] = &mini6410_fb_win[features.lcd_index];
>>
>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
>> + mini6410_lcd_pdata.win[0]->xres,
>> + mini6410_lcd_pdata.win[0]->yres);
>>
>> s3c_nand_set_platdata(&mini6410_nand_info);
>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
>> index be2a9a2..41e4f74 100644
>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>>
>> static struct s3c_fb_pd_win real6410_fb_win[] = {
>> {
>> - .win_mode = { /* 4.3" 480x272 */
>> - .left_margin = 3,
>> - .right_margin = 2,
>> - .upper_margin = 1,
>> - .lower_margin = 1,
>> - .hsync_len = 40,
>> - .vsync_len = 1,
>> - .xres = 480,
>> - .yres = 272,
>> - },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> + .xres = 480,
>> + .yres = 272,
>> }, {
>> - .win_mode = { /* 7.0" 800x480 */
>> - .left_margin = 8,
>> - .right_margin = 13,
>> - .upper_margin = 7,
>> - .lower_margin = 5,
>> - .hsync_len = 3,
>> - .vsync_len = 1,
>> - .xres = 800,
>> - .yres = 480,
>> - },
>> .max_bpp = 32,
>> .default_bpp = 16,
>> + .xres = 800,
>> + .yres = 480,
>> },
>> };
>>
>> +static struct fb_videomode real6410_lcd_timing = {
>> + .left_margin = 3,
>> + .right_margin = 2,
>> + .upper_margin = 1,
>> + .lower_margin = 1,
>> + .hsync_len = 40,
>> + .vsync_len = 1,
>> + .xres = 800,
>> + .yres = 480,
>> +};
>
>
> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
> In my opinion, it would be good as follows:
>
> +static struct fb_videomode real6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 800,
> + .yres = 480,
> +};
>
>
Before this patch series, both real6410 and mini6410 had 'default_win'
= 0 in the platform data. And, the s3c-fb driver selected the video
timing from the window selected by the default_win parameter in s3c-fb
platform data, i.e window 0 for both mini6440 and real6410. So, in
this patch, while moving the timing values out of window data, the
timing values for window 0 was selected.
The timing value for window 1 was never used on mini6410 and real6410.
So I would suggest to use timing value of window 0 in this patch.
Thanks for your comments.
Regards,
Thomas.
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-13 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1331585999-8604-4-git-send-email-thomas.abraham@linaro.org>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Tuesday, March 13, 2012 6:00 AM
> To: linux-fbdev@vger.kernel.org
> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> Cuelenaere
> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> For all the Samsung SoC based boards which have the platform data for
> s3c-fb driver, 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: Jingoo Han <jg1.han@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: JeongHyeon Kim <jhkim@insignal.co.kr>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Peter Korsgaard <jacmet@sunsite.dk>
> Cc: Darius Augulis <augulis.darius@gmail.com>
> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
> 19 files changed, 285 insertions(+), 238 deletions(-)
>
[.....]
> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
> index c34c2ab..24dcdc9 100644
> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>
> static struct s3c_fb_pd_win mini6410_fb_win[] = {
> {
> - .win_mode = { /* 4.3" 480x272 */
> - .left_margin = 3,
> - .right_margin = 2,
> - .upper_margin = 1,
> - .lower_margin = 1,
> - .hsync_len = 40,
> - .vsync_len = 1,
> - .xres = 480,
> - .yres = 272,
> - },
> .max_bpp = 32,
> .default_bpp = 16,
> + .xres = 480,
> + .yres = 272,
> }, {
> - .win_mode = { /* 7.0" 800x480 */
> - .left_margin = 8,
> - .right_margin = 13,
> - .upper_margin = 7,
> - .lower_margin = 5,
> - .hsync_len = 3,
> - .vsync_len = 1,
> - .xres = 800,
> - .yres = 480,
> - },
> .max_bpp = 32,
> .default_bpp = 16,
> + .xres = 800,
> + .yres = 480,
> },
> };
>
> +static struct fb_videomode mini6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 800,
> + .yres = 480,
> +};
> +
> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> + .vtiming = &mini6410_lcd_timing,
> .win[0] = &mini6410_fb_win[0],
> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
> mini6410_lcd_pdata.win[0] = &mini6410_fb_win[features.lcd_index];
>
> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
> - mini6410_lcd_pdata.win[0]->win_mode.xres,
> - mini6410_lcd_pdata.win[0]->win_mode.yres);
> + mini6410_lcd_pdata.win[0]->xres,
> + mini6410_lcd_pdata.win[0]->yres);
>
> s3c_nand_set_platdata(&mini6410_nand_info);
> s3c_fb_set_platdata(&mini6410_lcd_pdata);
> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
> index be2a9a2..41e4f74 100644
> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>
> static struct s3c_fb_pd_win real6410_fb_win[] = {
> {
> - .win_mode = { /* 4.3" 480x272 */
> - .left_margin = 3,
> - .right_margin = 2,
> - .upper_margin = 1,
> - .lower_margin = 1,
> - .hsync_len = 40,
> - .vsync_len = 1,
> - .xres = 480,
> - .yres = 272,
> - },
> .max_bpp = 32,
> .default_bpp = 16,
> + .xres = 480,
> + .yres = 272,
> }, {
> - .win_mode = { /* 7.0" 800x480 */
> - .left_margin = 8,
> - .right_margin = 13,
> - .upper_margin = 7,
> - .lower_margin = 5,
> - .hsync_len = 3,
> - .vsync_len = 1,
> - .xres = 800,
> - .yres = 480,
> - },
> .max_bpp = 32,
> .default_bpp = 16,
> + .xres = 800,
> + .yres = 480,
> },
> };
>
> +static struct fb_videomode real6410_lcd_timing = {
> + .left_margin = 3,
> + .right_margin = 2,
> + .upper_margin = 1,
> + .lower_margin = 1,
> + .hsync_len = 40,
> + .vsync_len = 1,
> + .xres = 800,
> + .yres = 480,
> +};
What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
In my opinion, it would be good as follows:
+static struct fb_videomode real6410_lcd_timing = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 800,
+ .yres = 480,
+};
> +
> static struct s3c_fb_platdata real6410_lcd_pdata __initdata = {
> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> + .vtiming = &real6410_lcd_timing,
> .win[0] = &real6410_fb_win[0],
> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> @@ -291,8 +287,8 @@ static void __init real6410_machine_init(void)
> real6410_lcd_pdata.win[0] = &real6410_fb_win[features.lcd_index];
>
> printk(KERN_INFO "REAL6410: selected LCD display is %dx%d\n",
> - real6410_lcd_pdata.win[0]->win_mode.xres,
> - real6410_lcd_pdata.win[0]->win_mode.yres);
> + real6410_lcd_pdata.win[0]->xres,
> + real6410_lcd_pdata.win[0]->yres);
>
> s3c_fb_set_platdata(&real6410_lcd_pdata);
> s3c_nand_set_platdata(&real6410_nand_info);
[.....]
^ permalink raw reply
* Re: [PATCH 1/2] fbdev: da8xx:: fix reporting of the display timing info
From: Anatolij Gustschin @ 2012-03-13 9:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331305336-32644-2-git-send-email-agust@denx.de>
Hi,
On Mon, 12 Mar 2012 05:19:54 +0000
"Manjunathappa, Prakash" <prakash.pm@ti.com> wrote:
...
> > +static inline unsigned long hz_to_ps(unsigned long hz_val)
> > +{
> > + unsigned long long num = 1000000000000ULL;
> > +
> > + do_div(num, hz_val);
> > + return (unsigned long)num;
> > +}
> > +
>
> I have patch to take care of this:
>
> http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-v2-video-da8xx-fb-calculate-pixel-clock-period-for-the-panel-tt7268377.html#none
Okay, thanks for the info! I'll rebase my patches and then resubmit.
Thanks,
Anatolij
^ 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