Hi,
I am setting up a 480x800 MIPI DSI command mode panel in ICS (3.0.8 kernel) on the PandaBoard ES using the Taal driver (panel-taal.c). The panel is now basically working fine. However, I am seeing issues with the ICS display sometimes not being updated properly. It seems like the DSI subsystem is sometimes a few steps short when updating the display. There are no similar issues when using either a parallel RGB display or an HDMI display.
For examples, if you go into an app like Settings, the display will stop updating before its menu items are displayed. In other words, the Settings app is displayed with a blank content. In this case, if you just press and release at the top of the display (the Action Bar area), the Settings app will then finish updating the display of its menu items. Also, sometimes when the back button is pressed, part (or all) of the display will still show the previous screen. Again, if you then just press and release the Action Bar area, the display will then finish updating.
A section of the DSS debug log for updating the display is given below. Are there any particular areas that I should look at in the DSI subsystem to resolve this? Thank you.
[ 459.036621] omapdss OVERLAY: check_overlay 0: (0,0 480x800 -> 480x800) disp (480x800)[ 459.045928] omapdss MANAGER: omap_dss_mgr_apply(lcd)[ 459.051727] omapdss OVERLAY: check_overlay 0: (0,0 480x800 -> 480x800) disp (480x800)[ 459.060791] omapdss MANAGER: dispc_setup_partial_planes 0,0 480x800[ 459.067779] omapdss MANAGER: configure_overlay(0)[ 459.073181] omapdss DISPC: dispc_setup_plane 0, pa 7e000000, sw 480, 0,0, 480/1x800/1 -> 480p[ 459.087158] omapdss DISPC: calc_rot(0): scrw 480, 480x800[ 459.093261] omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1[ 459.100280] omapdss DISPC: 0,0 480*1x800*1 -> 480x800[ 459.106048] omapdss DISPC: fifo(0) low/high old 784/1279, new 784/1279[ 459.113189] omapdss DISPC: dispc_enable_plane 0, 1[ 459.118652] omapdss MANAGER: configure_overlay(1)[ 459.123840] omapdss DISPC: dispc_enable_plane 1, 0[ 459.129119] omapdss MANAGER: configure_overlay(2)[ 459.134460] omapdss DISPC: dispc_enable_plane 2, 0[ 459.139770] omapdss MANAGER: configure_overlay(3)[ 459.145111] omapdss DISPC: dispc_enable_plane 3, 0[ 459.150421] omapdss MANAGER: configure_manager(0)[ 459.155700] omapdss DSI: dsi_vc_config_l4(0)[ 459.160644] omapdss DSI: dsi_vc_enable channel 0, enable 0[ 459.166961] omapdss DSI: dsi_vc_enable channel 0, enable 1[ 459.173583] omapdss DSI: dsi_update_screen_dispc(0,0 480x800)[ 459.180267] omapdss DSI: dsi_vc_config_vp(0)[ 459.180664] omapdss DSI: dsi_vc_enable channel 0, enable 0[ 459.191406] omapdss DSI: dsi_vc_enable channel 0, enable 1
Scott
Hi Scott,
Could you please let us know which exact Android ICS release are your using? Is it 4AI.1.X ICS Release or L27.IS.X ICS Release?
Do you mean to say that the above DSS debug logs are observed when you press on the Action Bar Area which results in full update of the display panel?
Could you please share the full DSS debug logs in the case of working and non-working scenarios as you said that sometimes, the screen updates fine and sometimes does not update until triggered?
Thanks & Best Regards,
Venkat
Please click the Verify Answer button on this post if it answers your question_____________________________________________
Be sure to read the OMAP4 Forum Guidelines & FAQ-
Scott,
Is the above log posted by you is captured at the same time as issue appeared?
As you do not see this issue with RGB panel and HDMI the issue will be most likely in taal panel driver. Mostly the issue will not be in Android file system.
Regards,
Chintan
------------------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.------------------------------------------------------------------------------------------------------------------
Thank you for the reply. I followed the outlines given in http://omappedia.org/wiki/Android_Panda_Build_Source#Building_from_AOSP_master_branch and built the panda target off of the AOSP master branch to get Android 4.0.4.0.4.0.4 ICS. I am also using the 3.0.8 kernel that I built using the android-omap-panda-3.0 branch of the AOSP kernel source.
The file "settings.txt" shows the full DSS debug log when the Settings app button is pressed. This gives a display of the Settings app with very dim menu items. The file "action_bar.txt" shows the full DSS debug log when the Action Bar area is tapped. This renders a proper display of the Settings app.
2500.settings.txt
5125.action_bar.txt
Thanks for the logs. But unfortunately I do not see any useful information in the log provided. I see that the the disp plane 0 is getting assigned FB address alternatively 7e000000 & 7c000000. This looks like normal behavior only.
However I do not see any logs related to taal driver like taal_update() or taal_sched_update() in any of the above logs. Have you disabled those logs?
I also suggest that find out the path of FBPost to lcd update by putting dump_stack() in dsi_update_screen_dispc(). Once you get the path continue debug those lines to find why the lcd update is not initiated.
Hi Chintan,
Thank you for the reply. The files attached here represent the same scenarios as before but also contain the debug messages from the Taal driver. They look quite normal and no errors are produced by the Taal driver.
The execution path has been traced out as follows. Its execution looks normal for each run of display update. I will try to look further into it. If you have any suggestions, please let me know. Thank you.
dsscomp_gralloc_queue() -> dsscomp_delayed_apply() -> dsscomp_do_apply() -> dsscomp_apply() -> taal_update() -> omap_dsi_update() -> dsi_update_screen_dispc()
2063.settings.txt
1512.action_bar.txt
It is observed that, with DSS debug messaging enabled, if the Settings button is pressed soon after pressing the Apps button from the home screen (i.e. pressing the Settings button while the DSS debug messages for entering the Apps screen are still being printed), sometimes the Settings app can be displayed properly.
It is not possible get any more clues with the info/logs provided so far. You can also start looking at user-space if you have any debug pointers.
Also try with the attached patch where I have forced taal lcd update at fixed auto interval instead of manual update only when required. Please see if this helps.
3223.lcd-update-patch.txt
Thank you for the reply. I have tried the changes in the patch but I am getting the following messages in the log during initialization and there is no display on the LCD.
omapfb omapfb: failed to setup omapfb
omapfb: probe of omapfb failed with error -22
I think it could be because we are failing the call to taal_set_update_mode with -EINVAL as it tries to set the mode to OMAP_DSS_UPDATE_MANUAL (even though it later calls tall_get_update_mode and we return OMAP_DSS_UPDATE_AUTO). Perhaps there is something in addition that needs to be done in order to use auto mode? I will keep looking into it.
This patch I have used on one of the GB release earlier and it was working fine. So it does not work as it is then I do not recommend spending much time on this as the display design has changed significantly sin GB to ICS.
Dear Scott:
Nice to contact with you.I am trying to setting up MIPI DSI command mode panel in ICS(Linaro prebuid and kernel_3.4.0) on the PandaBoard ES,too.
And,I tried two lcd driver: panel-taal.c and panel-lg4591.c.
But,unfortunately,it doesn't work in my panel.Would you be kindly share your experience of modifying the kernel?I am trying to modify the files,including
1./arch/arm/mach-omap2/board-omap4panda.c
2./arch/arm/configs/linaro_kernel_defconfig
3./driver/video/omap2/displays/panel-lg4591.c
Could you share your step? and
1.How to add lcd _device in board-omap4panda.c?
2.Is there any other file need to be modified?
Thank you very much!!
RGB (DPI) and HDMI work because they usually driver automatic update panels, which means that the panel is being constantly refreshed on the same rate independently of the frame rate that the application layer on top of it is able to generate frames. On Manual Update panels (such as Taal as it is a DSI command mode panel), typically the application layer should make the update(...) call of the panel explicitly when it has a new frame to send to the Display Controller. Seems like in your case, for some reason the App is not triggering the update(...) call, so it is not propagating to the kernel level and thus the panel is not updating the image - I suspect this to be an app (androd level) issue rather than a kernel issue.
The call flow that you mentioned is what actually needs to be triggered:
For adding a new panel driver, you should add a new omap_dss_device on the corresponding board file (board-omap4panda.c for panda), add a new Kconfig for enabling that panel (and add to the corresponding Makefile), enable that config on the menuconfig, and add the panel(s) file(s). If you only want to use an existing panel driver, as it should be most of the cases, you should only add the corresponding omap_dss_device structure on the corresponding board file and enable it on the menuconfig - you seem to be on the right track. For Taal, you could take as reference the omap_dss_device structure configuration from blaze board file (board-4430sdp.c).
Jorge Bustamante
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question. ---------------------------------------------------------------------------------------------------------