• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 747 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM5728: Linux/AM5728: U-boot logo color changes

AM5728: Boot splash with omapdrm resets during kernel init

Zane Cersovsky
Prodigy 220 points

Part Number: AM5728

I am attempting to use the information/patches from https://www.ti.com/lit/an/sprac49/sprac49.pdf, however, this document is severely out of date. The document covers changes to U-boot and the Linux kernel. I managed to get the U-boot changes adjusted for my hardware and a splash screen does appear correctly until the kernel takes over. At this point, the document becomes mostly useless since dra7/am57xx has moved from the omapfb driver to omapdrm and there have been numerous changes to hwmod and other init-related systems.

The gist of the document is that U-boot sets up DSS plane VIDEO3 and the minimum required settings to drive the LCD then various hacks to the kernel keep omapfb from resetting VIDEO3 until a user application disables it with a register write via /dev/mem. This sort of approach should work with omapdrm, though not in the exact same way.

Observations:

1. VIDEO3 gets reset even if omapdrm isn't loaded. Maybe by hwmod? All of the VIDEO3-specific registers are at their reset values after Linux boots.

2. Putting "ti,no-reset-on-init"/"ti,no-idle-on-init" in the device tree nodes for DSS and DISPC has no effect.

3. Returning early out of omap_dss_reset (hwmod function related to DSS) has no effect.

Questions:

1. Where is the DSS reset during Linux init?

2. How can I stop DSS/DISPC VIDEO3 from being reset during init?

3. Would it be possible to update SPRAC49?

I am using PHY-TEC's 4.19.79-derived kernel, which is a derivative of TI's 4.19 kernel (TISDK v06.02.00.81).

  • 0
    TI__Expert 5970 points

    Hi Zane Cersovsky,

    In order to get early boot splash to work, you need to make kernel DSS Driver changes as well to avoid kernel driver resetting the DSS/LCD again.

    Along with DT changes, you would need to modify the driver to exclude display init routines completely.

    Yes, the patch set is for omapfb and you can use it as a reference and make similar changes on omapdrm driver. 

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 220 points

    Sunita,

    I'm aware of the general approach (as outlined in my original question), I was looking for specific details/places to start looking.

    What's particularly interesting is that Linux seems to do a soft reset of the DSS even if omapdrm isn't loaded during boot. If I can find where that happens, I should be able to work through the rest of it. That's why I suspected a hwmod issue. It could also be runtime PM or the clock system shutting down "unused" resources early in boot. If there's any information about how/when the soft reset happens, that would be very useful.

    -Zane Cersovsky

  • 0 in reply to Zane Cersovsky
    TI__Expert 5970 points

    Hi Zane,

    Yes, there are some patches which are outside the dss kernel driver, eg: hwmod and global clk settings.

    eg:

    http://review.omapzoom.org/#/c/36941/3

    review.omapzoom.org/

    Please note that the patches mentioned in the app note are all required for this functionality on earlier SDK. Please use them as lead and make necessary changes for the latest Kernel drivers. The idea is to exclude reinit of any DSS (clocks, plls, device resets) etc from Linux side.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 220 points

    If/when I find a working solution or give up, I will update this thread. For the next few months, I have to focus on other tasks.

    As for the linked patch, as the reviewer noted, the patch completely disables clock disabling. I'll have to either find a better solution or to give up since power consumption and heat dissipation are much more pressing concerns than a seamless boot splash. The clk_disable_unused method seems like a good place to start. When I get back to this issue, I will try the linked changes to get a rough draft working and then go back and add support for the "ti,no-idle-on-init" device tree flag. Some care will be needed to not break power management of the DSS, though.

  • 0 in reply to Zane Cersovsky
    TI__Expert 5970 points

    Hi Zane Cersovsky,

    Thanks for the note. I'm closing the thread now. Please open it whenever you get back to this task.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 220 points

    Okay. I will link back to this thread when I open a new thread to help those searching in the future.