Hi Archit,
Maybe the driver wasn't able to calculate 40.5 Mhz with CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4, the complete logs would help here.
Attached here the complete log. File: wtda2_log.txt
Kernel I am using don't have CONFIG_OMAP2_DSS_DEBUGFS, With CONFIG_OMAP2_DSS_DSI=y and CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4, getting NULL pointer dereference in kernel. Attached here the complete log. File: wtd3_log.txt.
Yes, this config (CONFIG_OMAP2_DSS_DSI) is needed to derive pixel clock from DSI PLL.
Is this config required for latest kernel or from the start DSI is a dependency for DPI?
Regards, Vikash
-----Original Message----- From: Archit Taneja [mailto:archit@ti.com] Sent: Friday, May 09, 2014 2:14 PM To: Patil, Vikash Cc: Valkeinen, Tomi; dri-devel@lists.freedesktop.org Subject: Re: OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
Hi,
On Friday 09 May 2014 02:07 PM, Patil, Vikash wrote:
Hi Archit,
With CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK to 4, mode becomes invalid and can't launch kmscube.
[ 0.847015] [drm:omap_connector_mode_valid], connector: mode invalid: 14:"1280x480" 60 40500 1280 1350 1365 1366 480 491 492 494 0x48 0x0 [ 0.847045] [drm:drm_mode_debug_printmodeline], Modeline 14:"1280x480" 60 40500 1280 1350 1365 1366 480 491 492 494 0x48 0x0 [ 0.847045] [drm:drm_mode_prune_invalid], Not using 1280x480 mode -2 [ 0.847076] No connectors reported connected with modes
Maybe the driver wasn't able to calculate 40.5 Mhz with CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4, the complete logs would help here.
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
Is this because CONFIG_OMAP2_DSS_DSI is not set? Not sure this also needs to enable as I am using 3.4.25 kernel.
Yes, this config is needed to derive pixel clock from DSI PLL.
Is there any dependencies with TDF19988 (HDMI converter)? Like missing support or driver?
A bad configuration of TDF19988 shouldn't result in a sync lost. Sync losts are more or less internal to the Display Controller(DISPC).
A dump of the DSS and DISPC registers will help here.
Could you set CONFIG_OMAP2_DSS_DEBUGFS to 'y', and share the output of the just after the error occurs?
cat /sys/kernel/debug/omapdss/dss cat /sys/kernel/debug/omapdss/dispc
Archit
Regards, Vikash
-----Original Message----- From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Archit Taneja Sent: Friday, May 09, 2014 12:09 PM To: Vikas Patil Cc: Valkeinen, Tomi; dri-devel@lists.freedesktop.org Subject: Re: OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
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/e7792ce2da5ded80861db787ace.... 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
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel