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.