OMAP4460 MIPI DSI - "omapdss DSI error: Failed to complete previous l4 transfer"

Hi Jorge,

Thank you very much for the reply. When omap_dsi_update(...) is called, (dssdev->manager->caps & OMAP_DSS_OVL_MGR_CAP_DISPC) does return true and dsi_update_screen_dispc(...) does get called. However, I assume that when omap_dsi_update(...) is called for the first time, dsi->vc[0].mode contains the default value of 0, which represents DSI_VC_MODE_L4, and that's why when omap_dsi_update(...) ---> dsi_update_screen_dispc(...) ---> dsi_vc_config_vp(...) ---> dsi_sync_vc(...) is carried out, dsi_sync_vc_l4(...) gets called before dsi_vc_config_vp(...) has a chance to set dsi->vc[0].mode to DSI_VC_MODE_VP at the end. I will try to set dsi->vc[0].mode to DSI_VC_MODE_VP first before omap_dsi_update(...) gets called.

Commenting out the call to dsi_sync_vc(...) inside dsi_vc_config_vp(...) removes the "omap DSI error: Failed to complete previous l4 transfer" message for now. However, the "omap DSI error: vc(0) busy when trying to config for VP" message still exists. I tried commenting out the call to taal_set_update_window(...) inside the taal_update(...) function in drivers/video/omap2/displays/panel-taal.c as follows and this removes the "omap DSI error: vc(0) busy when trying to config for VP" message.

    r = omap_dsi_prepare_update(dssdev, &x, &y, &w, &h, true);
    if (r)
        goto err;
#if 0
    r = taal_set_update_window(td, x, y, w, h);
    if (r)
        goto err;
#endif
    if (td->te_enabled && panel_data->use_ext_te) {
        td->update_region.x = x;
        td->update_region.y = y;
        td->update_region.w = w;
        td->update_region.h = h;
        barrier();
        schedule_delayed_work(&td->te_timeout_work,
                msecs_to_jiffies(250));
        atomic_set(&td->do_update, 1);
    } else {
        r = omap_dsi_update(dssdev, td->channel, x, y, w, h,
                taal_framedone_cb, dssdev);
        if (r)
            goto err;
    }

With the above changes in place, each time the update function is called, the following messages show up. I am wondering if there are some settings that I might have overlooked that are causing these issues?

omapdss DSI error: TE not received for 250ms!

omapdss DSI error: Framedone not received for 250ms!

Scott Lin

Have you solved your issue already?

Checking further the code...

dsi_sync_vc (be it l4 or vp) is just making sure that the last transfer has finished. So it is fine if it is dsi_sync_vc_l4 even if calling dsi_vc_config_vp. In fact, seems like dsi_vc_config_vp/dsi_vc_config_l4 are always assuming that the config is being changed from l4 to vp, or from vp to l4, respectively. The dsi_sync_vc_l4 call that is failing for you, means that the last l4 packet requested to be sent has not been sent yet. The second error you were having, means the VC is still busy because it is still trying to send that packet, which most probably is related to the same issue. So the question is why your DSI Engine is not able to send that packet. I guess this packet is on your taal_set_update_window(...) function, and thats why when you comment out that function, the issue is gone. You cannot just comment out this function, because these two writes that happens there, configure your panel so that it knows when to send the TE signal after having gotten all the needed pixels for one frame (thats why you get that TE not received for 250ms errors). This function has two long packet writes and a bus-turnaround sync, I would suggest to figure out first which of these is making it fail - seems like this functions sends the first packets after having reconfigured the VC as high-speed (omapdss_dsi_vc_enable_hs(...)). It is hard to know whats your specific issue without further debugging, but here are some suggestions you can check:

1.- Is the DSI interface physically sending any data on the data lanes after having reconfigured the VC as high-sped? You could check with the scope.

2.- Is the DSI clock working after having reconfigured the VC as high-speed? You could check with the scope.

3.- Is the DSI TX FIFO changing at all?

4.- Can we put a sleep after sending the BTA sync on the taal_set_update_window(...) function (I doubt this works but I would make sure)?

5.- Check your board panel file configuration as there might be something related to clocks missing/miss-configured, since seems like Low-Power mode is working fine.

6.- Your panel might be doing something wrong with BTA so that OMAP cannot send any data after that... can you try disabling the BTA sync?

Hi Jorge,

As you indicated, it is the long packet writes inside the taal_set_update_window(...) function that are causing the issues. Adding a sleep after the BTA sync does not help. Disabling the BTA sync does not help, either. If both long packet writes are disabled, then I don't see those l4 transfer and VC busy errors. If either one of those long packet writes is enabled, then those l4 transfer and VC busy errors show up.

The Truly DSI panel that I am trying to bring up uses two data lanes in addition to the clock lane. The panel has an 864 x 480 resolution, which is the same as what the Taal panel has. As a result, I am using the Taal panel settings listed below in my board file.

    .phy.dsi        = {
        .clk_lane    = 1,
        .clk_pol    = 0,
        .data1_lane    = 2,
        .data1_pol    = 0,
        .data2_lane    = 3,
        .data2_pol    = 0,
    },

    .clocks = {
        .dispc = {
            .channel = {
                .lck_div    = 1,    /* Logic Clock = 172.8 MHz */
                .pck_div    = 5,    /* Pixel Clock = 34.56 MHz */
                .lcd_clk_src    = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,
            },
            .dispc_fclk_src    = OMAP_DSS_CLK_SRC_FCK,
        },

        .dsi = {
            .regn        = 16,    /* Fint = 2.4 MHz */
            .regm        = 180,    /* DDR Clock = 216 MHz */
            .regm_dispc    = 5,    /* PLL1_CLK1 = 172.8 MHz */
            .regm_dsi    = 5,    /* PLL1_CLK2 = 172.8 MHz */

            .lp_clk_div    = 10,    /* LP Clock = 8.64 MHz */
            .dsi_fclk_src    = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI,
        },
    },

    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;
    omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);

Low power mode operation seems to be working fine as the panel revision ID's can be read during initialization. Traffic on data lane 0 can be seen on the scope after switching to high speed mode. However, only pulses at around 38.5kHz can be observed on the clock lane and data lane 1. There should be come configuration settings that I may have missed?

Regards,

Scott Lin

Some additional information. By making changes to the settings inside .phy.dsi{}, each of the 3 physical lanes has been verified on the scope as being able to operate as data lane 0 in low power mode. Right before the two long packet writes inside taal_set_update_window(...), the DSI_VC_CTRL_0 register reads as 0x20808781. According to this, the VC is set up to operate in high-speed command mode. By the way, as for the Taal panel driver, the use of the external TE signal has been disabled.

Scott Lin

Hi Jorge,

As before, the issue now boils down to the long packet writes (dsi_vc_send_long(...)) issued in taal_set_update_window(...) not being able to complete the job. For the short packet writes (dsi_vc_send_short(...)) issued previously in taal_power_on(...), the TX FIFO is always emptied (TX_FIFO_NOT_EMPTY = 0 in DSI_VC_CTRL_0) after each write and so there is no problem there. Both dsi_vc_send_short(...) and dsi_vc_send_long(...) configure the VC to use L4 and fill up their respective header (and payload for long packet writes) registers. But for some reason, the packet is not sent out and TX_FIFO_NOT_EMPTY remains set for the long packet writes. I tried removing the enabling of high-speed mode at the end of taal_power_on(...) so that the long packet writes run in low-power state as the short packet writes, but this did not help. Do you have any suggestion on what to check or adjust? Thank you in advance.

Regards,

Scott Lin

Just for investigation, I tried using buffers of different sizes (from 3 to 12) for the two long packet writes in taal_set_update_window(...). When the size was 3, 6, or 9, the TX FIFO could be emptied and there was no subsequent "omapdss DSI error: Failed to complete previous l4 transfer" error message further down the line. However, the error message showed up for all the other sizes.

Below are some register values captured at the beginning of the dsi_vc_write_nosync(...) function. Any suggestion or advice is appreciated. Thanks.

DSI_CTRL - 0x0008609F

DSI_GNQ - 0x01926936

DSI_TX_FIFO_VC_SIZE - 0x13121110

Regards,

Scott Lin