diff mbox

[drm/exynos-fimd] Display regression in v3.12-rc1

Message ID CAK9yfHzpPWNu9wOFPFt35+ErDdMztBq9L9t=gdY6ZbEDD4KFwQ@mail.gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Sachin Kamat Sept. 18, 2013, 8:15 a.m. UTC
Hi Andrzej,

Thanks for your quick response.
Removing display-timings::clock-frequency property from
arch/arm/boot/dts/exynos4210-origen.dts
fixed this issue. However, I also had to remove the same from
drivers/video/of_display_timing.c as
shown below, else probe fails. I will send a patch to fix the Origen
dts file. Thanks for your help.

8<-------------------------------------------------------------------------------------------

 --
With warm regards,
Sachin

On 18 September 2013 12:18, Andrzej Hajda <a.hajda@samsung.com> wrote:
> Hi Sachin,
>
> Could you test it with removed display-timings::clock-frequency property.
> Currently in arch/arm/boot/dts/exynos4210-origen.dts
> display-timings::clock-frequency is set to 50000,
> this is incorrect value. With the property removed fimd calculates
> clock-frequency from other properties with assumption of default
> 60Hz refresh rate.
>
> It could work before because of_get_fb_videomode calculated refresh rate
> from display-timings and with clock 50000, the result was 0(due to
> rounding down in some division),
> so fimd assumed he should use default refresh rate of 60Hz.
>
> Regards
> Andrzej
>
> On 09/18/2013 07:22 AM, Sachin Kamat wrote:
>> Hi Andrzej ,
>>
>> I was testing the latest Linux kernel release (v3.12-rc1) on
>> Exynos4210 based Origen board.
>> I found a display regression with that. I do not get any display on
>> the LCD (other than backlight) with the latest kernel. Git bisect
>> pointed me to the following commit:
>> 111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
>> struct fb_videomode with videomode"). Reverting this patch does not
>> cause the issue. Let me know if you need any other info to help
>> identify the problem.
>>
>

Comments

Andrzej Hajda Sept. 18, 2013, 8:31 a.m. UTC | #1
Hi,

You can just set this property to zero.
of_parse_display_timing will not complain and
you will have default settings.

Regards
Andrzej

On 09/18/2013 10:15 AM, Sachin Kamat wrote:
> Hi Andrzej,
>
> Thanks for your quick response.
> Removing display-timings::clock-frequency property from
> arch/arm/boot/dts/exynos4210-origen.dts
> fixed this issue. However, I also had to remove the same from
> drivers/video/of_display_timing.c as
> shown below, else probe fails. I will send a patch to fix the Origen
> dts file. Thanks for your help.
>
> 8<-------------------------------------------------------------------------------------------
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c
> index 171821d..4e991e1 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -72,7 +72,6 @@ static int of_parse_display_timing(const struct
> device_node *np,
>         ret |= parse_timing_property(np, "vfront-porch", &dt->vfront_porch);
>         ret |= parse_timing_property(np, "vactive", &dt->vactive);
>         ret |= parse_timing_property(np, "vsync-len", &dt->vsync_len);
> -       ret |= parse_timing_property(np, "clock-frequency", &dt->pixelclock);
>
>         dt->flags = 0;
>
>  --
> With warm regards,
> Sachin
>
> On 18 September 2013 12:18, Andrzej Hajda <a.hajda@samsung.com> wrote:
>> Hi Sachin,
>>
>> Could you test it with removed display-timings::clock-frequency property.
>> Currently in arch/arm/boot/dts/exynos4210-origen.dts
>> display-timings::clock-frequency is set to 50000,
>> this is incorrect value. With the property removed fimd calculates
>> clock-frequency from other properties with assumption of default
>> 60Hz refresh rate.
>>
>> It could work before because of_get_fb_videomode calculated refresh rate
>> from display-timings and with clock 50000, the result was 0(due to
>> rounding down in some division),
>> so fimd assumed he should use default refresh rate of 60Hz.
>>
>> Regards
>> Andrzej
>>
>> On 09/18/2013 07:22 AM, Sachin Kamat wrote:
>>> Hi Andrzej ,
>>>
>>> I was testing the latest Linux kernel release (v3.12-rc1) on
>>> Exynos4210 based Origen board.
>>> I found a display regression with that. I do not get any display on
>>> the LCD (other than backlight) with the latest kernel. Git bisect
>>> pointed me to the following commit:
>>> 111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
>>> struct fb_videomode with videomode"). Reverting this patch does not
>>> cause the issue. Let me know if you need any other info to help
>>> identify the problem.
>>>
Sachin Kamat Sept. 20, 2013, 6:42 a.m. UTC | #2
Hi,

On 18 September 2013 14:01, Andrzej Hajda <a.hajda@samsung.com> wrote:
> Hi,
>
> You can just set this property to zero.
> of_parse_display_timing will not complain and
> you will have default settings.

Yes, that works fine. Thanks.
diff mbox

Patch

diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index 171821d..4e991e1 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -72,7 +72,6 @@  static int of_parse_display_timing(const struct
device_node *np,
        ret |= parse_timing_property(np, "vfront-porch", &dt->vfront_porch);
        ret |= parse_timing_property(np, "vactive", &dt->vactive);
        ret |= parse_timing_property(np, "vsync-len", &dt->vsync_len);
-       ret |= parse_timing_property(np, "clock-frequency", &dt->pixelclock);

        dt->flags = 0;