Re: OMAPDSS: omap5 SYNC_LOST error with DPI/LCD

* Re: OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
       [not found] ` <CA+kt3u2Otxv49sgS6WiOq1Eeh-tezRRtAhYwWcFRSTfjjhJ9EA@mail.gmail.com>
@ 2014-05-09  6:38   ` Archit Taneja
  2014-05-09  8:37     ` Patil, Vikash
  0 siblings, 1 reply; 12+ messages in thread
From: Archit Taneja @ 2014-05-09  6:38 UTC (permalink / raw)
  To: Vikas Patil; +Cc: Valkeinen, Tomi, dri-devel@lists.freedesktop.org

Hi Vikas,

On Friday 09 May 2014 11:54 AM, Vikas Patil wrote:
> Hi,
>
> Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI
> conversion.
> I have build the driver for it from
> https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c.
> Is this the correct driver for it? Also I am trying to use the
> generic-dpi-panel driver for this. it seems I also need to add support
> for TDF19988 somewhere in omapdrm or lcd/panel driver by calling
> drm_i2c_encoder_init. Could you please give inputs, how should I proceed
> further?
>
> Thanks & Regards,
> Vikash
>
>
>
> On Thu, May 8, 2014 at 3:37 PM, Vikas Patil <vikasmpatil@gmail.com
> <mailto:vikasmpatil@gmail.com>> wrote:
>
>     Hi,
>
>     I am working on to enable the second display output for customized
>     OMAP5 based platform and linux 3.4.25. First display which is
>     HDMI/tv is working fine. Second display out is coming via DPI
>     interface. To enable DPI interface I enabled CONFIG_OMAP2_DSS_DPI
>     and CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and
>     omap_dss_board_info and removed the HDMI device and disabled
>     CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting
>     correctly, however when I try to run kmscube app and it seems to be
>     running, noticing following error and till now nothing on display.
>
>     Could you give some inputs to debug this? Is this following error
>     due to which not getting anything on display?

 From the logs, one thing which looks like a problem is that the DPI 
driver isn't using a DSI PLL to generate a pixel clock of 40.5 Mhz for 
the 1280x480 panel. It's trying to change DSS_FCK to get the desired 
clock. This won't work well if we start doing scaling. And in genral, 
it's always good to have DSS_FCK a bit higher than the pixel clocks of 
all the panels connected to DSS.

Could you try to set the value of CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to 4, 
and tell what happens? The correct solution would be to figure out why 
it isn't using the DSI PLL, but we could start with changing the config 
above.

Archit

^ permalink raw reply	[flat|nested] 12+ messages in thread