AM62P: AM62P DSI driver changes

Part Number: AM62P

Hi Apps team, 

 

posting on customer behalv who is working on the bring up of the MIPI-DSI panel on an product with the AM62P using TI Linux 6.12.y. They previously had a working panel driver for the same dislpay on a different SOC, but on the AM62P they observe that the dislpay sporadically remains black after boot. Once the e2e Thread is assigned, I'll send you the files via e-mail. But here is the request: 

 

After making substantial changes to the panel driver and moving the panel DCS initialization into prepare(), we found that prepare-time direct DSI transfers were not reliable on our setup. As a result, the system could start the video pipeline while the panel remained uninitialized, leading to a black screen.

Our current understanding is that it cannot be solved from the display panel driver only. 

 

Our local Cadence-side change does the following:

  1. cdns_dsi_transfer(): pm_runtime_resume_and_get() -> cdns_dsi_init_link() -> cdns_dsi_hs_init() -> cdns_dsi_wait_for_lane_ready() -> transfer -> pm_runtime_put()
  2. cdns_dsi_hs_init() now returns int and propagates phy_init(), phy_configure(), and phy_power_on() failures
  3. PLL lock polling was extended
  4. atomic_pre_enable() now uses the same link/HS/lane-ready sequence
  5. runtime suspend powers off the PHY and clears phy_initialized / link_initialized

 

Without this ordering, the first prepare-time DSI commands did not reliably take effect on our setup, which could leave the panel uninitialized while video still started.

With the above changes and some major panel driver modifications, we were able to mitigate the issue fully.

 

Could you please advise:

  • Does this match a known issue or recommended sequencing in TI Linux 6.12.y for direct transfers before video enabled?
  • Do you see any concern or regression risk with this runtime PM / PHY / lane-ready handling?
  • If the approach looks correct, would TI prefer us to keep it downstream or send it as a patch series for the TI tree?

 

Please find our current drivers attached. 

I can send the Cadence host-side changes as a patch or with any other method if that is easier to review. And if anything, else is needed from our side feel free to reach me.

Thank you, 

Marinus 

  • Hi Marinus,
    On testing one of our internal panels supporting direct DCS writes, we needed the following changes upon 6.12, let me know if these align with yours: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0245.0001_2D00_Enable_2D00_Microtips_2D00_DSI_2D00_panel_2D00_on_2D00_6_5F00_12.patch

    There mostly are panel driver side changes, but a few changes on Cadence driver side as well. Let me know if Cadence driver side changes help your case as well, will make it easier to merge these changes. Also, is the customer panel based on ili9881c or some other controller chip?

  • Hi ,

    Thanks for sharing the patch and sorry for the late reply.

    I adapted the DSI-side changes from your patch on our side and also fixed up our panel integration together with the related panel driver modifications. With these changes, the display is now working properly on our setup.

    On the cdns-dsi-core side, the main changes I took over were:

    • moving the clock/data lane ready wait into cdns_dsi_hs_init()
    • calling cdns_dsi_hs_init() from the transfer path as well, so the PHY is initialized before direct commands
    • resetting the DCS write FIFO before sending direct commands
    • clearing link_initialized and phy_initialized during suspend so link/PHY setup is redone cleanly after resume

    I tried to keep the TI DSI driver delta as small as possible and stay aligned with your approach, while handling the panel-specific behavior in the panel driver.

    Could you let us know in which upcoming TI kernel release or kernel version you expect these changes to be merged? It would help us decide how long we should keep carrying the local adaptation.

    Thanks,
    Máté Szabó

  • Hi Máté,
    Great to know that this helped. We needed confirmations from customer side as well if this patch is working.
    We are hoping to make this patch included in our SDK hopefully in 12.01, or in worse case by 12.02 SDK release.