| Message ID | 1475166715-7857-5-git-send-email-bgolaszewski@baylibre.com |
|---|---|
| State | New |
| Headers | show |
2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>: > Hi, > > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote: >> Add svga timings for 1024x768 resolution to the da850-lcdk >> device tree. >> > [snip] > > Why do you also call 1024x768 svga ? > Thanks, should have been xga. will fix in v2. > I don't think the LCDK can cope with this resolution at this frequency > (in terms of mem bandwidth), at least that's what I observed back in > August. If confirmed I think it is worth mentioning in the log at least, > but then I doubt adding this config would be useful. > Thanks for the heads up. How would that manifest itself? This seems to work fine for me - I'm not getting any warnings on a simple system - maybe if I added some additional memory load it would complain. Thanks, Bartosz
On Friday 30 September 2016 03:07 PM, Bartosz Golaszewski wrote: > 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>: >> Hi, >> >> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote: >>> Add svga timings for 1024x768 resolution to the da850-lcdk >>> device tree. >>> >> > > [snip] > >> >> Why do you also call 1024x768 svga ? >> > > Thanks, should have been xga. will fix in v2. When you send the v2, can you please include the driver folks too. I am no expert on DRM and LCDC and would like to ensure they had a look at the dts patches too. Thanks, Sekhar
On Friday 30 September 2016 07:18 PM, Bartosz Golaszewski wrote: > 2016-09-30 14:49 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>: >> On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote: >>> 2016-09-29 20:58 GMT+02:00 Karl Beldan <karl.beldan@gmail.com>: >>>> Hi, >>>> >>>> On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote: >>>>> Add svga timings for 1024x768 resolution to the da850-lcdk >>>>> device tree. >>>>> >>>> >>> >>> [snip] >>> >>>> >>>> Why do you also call 1024x768 svga ? >>>> >>> >>> Thanks, should have been xga. will fix in v2. >>> >>>> I don't think the LCDK can cope with this resolution at this frequency >>>> (in terms of mem bandwidth), at least that's what I observed back in >>>> August. If confirmed I think it is worth mentioning in the log at least, >>>> but then I doubt adding this config would be useful. >>>> >>> >>> Thanks for the heads up. How would that manifest itself? This seems to >>> work fine for me - I'm not getting any warnings on a simple system - >>> maybe if I added some additional memory load it would complain. >>> >> >> A mere dmesg > /dev/tty0 (or repeatedly cat-ting a file to /dev/tty0) >> should suffice to make the issue visible and trigger FIFO underflows. >> > > Thanks, this is correct unfortunately. The OMAP-L138 datasheet documents 37.5 MHz as the maximum pixel clock possible on the device. Looks like you need 72MHz pixel clock for 1024x768 which is definitely out of spec. Thanks, Sekhar
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts index 6ca5d48..6e4288c 100644 --- a/arch/arm/boot/dts/da850-lcdk.dts +++ b/arch/arm/boot/dts/da850-lcdk.dts @@ -70,8 +70,8 @@ }; display-timings { - native-mode = <&svga_timings>; - svga_timings: 800x600 { + native-mode = <&svga_timing0>; + svga_timing0: 800x600 { clock-frequency = <37500000>; hactive = <800>; hback-porch = <140>; @@ -82,6 +82,17 @@ vfront-porch = <1>; vsync-len = <4>; }; + svga_timing1: 1024x768 { + clock-frequency = <72000000>; + hactive = <1024>; + hback-porch = <140>; + hfront-porch = <40>; + hsync-len = <128>; + vactive = <768>; + vback-porch = <23>; + vfront-porch = <1>; + vsync-len = <4>; + }; }; }; };
Add svga timings for 1024x768 resolution to the da850-lcdk device tree. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> --- arch/arm/boot/dts/da850-lcdk.dts | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 2.7.4