LCD2 not detected on Blaze board (SEVM4430G, non-tablet) when using prebuilt 4AI.1.4-P1

Martin,

Which release have you used earlier? Please have a look at the board file for Blaze. Now the board file only contains two devices lcd and hdmi. It does not include lcd2 anymore.

If you want to add support for lcd2 you need to change the board file accordingly.

Regards,

Chintan

Hi Chintan,

Thanks for the feedback.

I am not aware of the exact release however it was for certain Gingerbread based. Which board file are you referring to? I can see that the 'device/ti/init.omap4blazeboard.rc' no longer 'chown's all the omapdss devices - is this what you are referring to?

Regards,

Martin

Thanks I now have the device appearing - I appreciate your support.

Regards,

Martin

Hi Martin,

Thanks for the update. Did you extend the omap_dss_devices structure similar to Gingerbread in the board file to include the secondary lcd i.e., LCD2 display also. Please share if any other changes other than the board file was necessary to address the issue as it would be useful information.

Thanks & Best Regards,

Venkat

Hi Venkat,

Hi Martin,

Thanks for sharing the update and the procedure you followed to extend support for LCD2. Could you please share the log in a new post  if you need some guidance with respect to crash when display1 is enabled.

Best Regards,

Venkat

Thanks Venkat, I will do that after looking a bit further into it.

Regards,

Martin

Hi Venkat,

Hi Martin,

I cannot access the logs loaded at the http://pastebin.com site as the website is blocked. Could you please upload the log files to the forum for further analysis and guidance.

You are right that both LCD's should not map to the same DSI. It does not seem to be correct.

Thanks & Best Regards,

Venkat

Hi,

Sorry about that - files are now uploaded to the forum.

I realized that the 'omap_dss_dsi_type' structure has a 'module' element which is not assigned, hence this is probably the reason that both LCD devices accesses module 0. I just tried assigning the values '0' and '1' respectively however the compiled kernel does not event boot - nothing is printed through the serial connection and the device reboots after a while to uBoot and further into Fastboot mode.

From the 'sdp4430_lcd_init()' function I noticed that the DSI1 module is initialized and I am wondering if the DSI2 module needs to be initialized here as well?

Regards,

Martin

Hi Martin,

Definitely, we need to initialize both DSI1 and DSI2 modules. You can refer to the existing board file of 4AI.1.4 i.e., board-4430sdp.c and extend it accordingly for LCD2 and DSI2.

Could you please update the sdp4430_lcd_init() by extending it to DSI2 panel initialization by starting the base code as that of 4AI.1.4  at

http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-4430sdp.c;h=eeb49336aca10c9a4c7ea7ae06d276204f804d35;hb=refs/heads/p-android-omap-3.0

Also, can you delete the "Enable LCD2" code in omap_4430sdp_display_init(void) which is not in accordance with 4AI.1.4 base code.

Please let me know your observations after trying the above changes.

Thanks & Best Regards,

Venkat

Hi Venkat,

According to your advice I extended sdp4430_lcd_init() to the following initialization:

/* Enable 3 lanes in DSI1 module, disable pull down */
reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
reg &= ~OMAP4_DSI1_LANEENABLE_MASK;
reg |= 0x7 << OMAP4_DSI1_LANEENABLE_SHIFT;
reg &= ~OMAP4_DSI1_PIPD_MASK;
reg |= 0x7 << OMAP4_DSI1_PIPD_SHIFT;
reg &= ~OMAP4_DSI2_LANEENABLE_MASK;
reg |= 0x7 << OMAP4_DSI2_LANEENABLE_SHIFT;
reg &= ~OMAP4_DSI2_PIPD_MASK;
reg |= 0x7 << OMAP4_DSI2_PIPD_SHIFT;
omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);

/* Panel Taal reset and backlight GPIO init */
status = gpio_request_one(dsi1_panel.reset_gpio, GPIOF_DIR_OUT,
"lcd_reset_gpio");
if (status)
pr_err("%s: Could not get lcd_reset_gpio\n", __func__);

if (dsi1_panel.use_ext_te) {
status = omap_mux_init_signal("gpmc_ncs4.gpio_101",
OMAP_PIN_INPUT_PULLUP);
if (status)
pr_err("%s: Could not get ext_te gpio\n", __func__);
}

/* Panel Taal reset and backlight GPIO init */
status = gpio_request_one(dsi2_panel.reset_gpio, GPIOF_DIR_OUT,
"lcd2_reset_gpio");
if (status)
pr_err("%s: Could not get lcd2_reset_gpio\n", __func__);

which however leads to the same crash as previous, as the primary DSI module is (incorrectly) re-initialised when secondary LCD is enabled:

omapdss DSI: Ixo: dsi_display_init_dsi() - dssdev->name: lcd2, dsidev->name: omapdss_dsi1, dsi_module: 0

The following fragment present in the 2.6.35 code base seems related to DSI init which is not at all present in the 3.0 code base:

phymux_base = ioremap(0x4A100000, 0x1000);

/* Turning on DSI PHY Mux*/
__raw_writel(val, phymux_base + 0x618);

/* Set mux to choose GPIO 101 for Taal 1 ext te line*/
val = __raw_readl(phymux_base + 0x90);
val = (val & 0xFFFFFFE0) | 0x11B;
__raw_writel(val, phymux_base + 0x90);

/* Set mux to choose GPIO 103 for Taal 2 ext te line*/
val = __raw_readl(phymux_base + 0x94);
val = (val & 0xFFFFFFE0) | 0x11B;
__raw_writel(val, phymux_base + 0x94);

iounmap(phymux_base);

It is my assumption that this is replaced by the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY register access in the 3.0 code base and thus no longer applicable - can you please confirm this?

Looking into the 3.0 code base, the omap_dss_device.dsi has a 'module' element which is not present in the 2.6.35 code base. It seems added in this commit: http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a72b64b99918ee801a3a6abf5391e356752bcad0. In my perspective it looks like we need to take this into consideration when porting the 2.6.35 LCD2 support - what is your oppinion?

Thanks,
Martin