• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 794 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.

Prevent Kernel from De-initing LCD at Boot

David Paden
Expert 1925 points
Other Parts Discussed in Thread: AM3517

I am using the AM3517 with Linux.  I have enabled the LCD at boot with U-Boot to show a splash screen, and the LCD is working fine once Linux is up and running.

However, in the time between U-Boot handing off operation to the Kernel and the Kernel re-initializing the LCD (DSS, DISPC, DPI), the LCD seems to be disabled.  I've tried selecting the Kernel option to check for prior DSS initialization, but this does not seem to actually prevent any re-initialization.  In fact, in the Kernel sources it appears it just prevents a soft reset of the DSS system.

Ideally, I would like the framebuffer data to remain unchanged and the display remain unchanged all the way through the boot process.  The framebuffer may be changed later by our application (no Framebuffer Console).  I'm using SGX for the app, so I DO need the Kernel LCD module at some level so the PowerVR drivers load properly.

I'm thinking the culprit may be that the DPLL4 or DSS1_ALWON_FCLK clock is being changed during early board init.  Anyone with a little experience in the clocking sources have an idea where I should start looking?

  • 0
    Expert 1925 points

    I had gotten this message and then it was missing after the E2E site was down:

    Vaibhav Hiremath replied to Re: Prevent Kernel from De-initing LCD at Boot in AM35x, AM37x Cortex-A8 Microprocessors Forum.

    Hi David,

    Personnelly I have never tried this use-case. Have you tried disabling option "CONFIG_OMAP_RESET_CLOCKS" from kernel configuration? Also I believe you are passing the same framebuffer address which you are using from u-boot, right?

    Thanks,

    Vaibhav

  • 0 in reply to David Paden
    Expert 1925 points

    Is it possible to supply the omapfb with the desired framebuffer address?  I haven't tried before.

    Anyway, it seems that the following process occurs at bootup:

    1 - U-Boot initializes LCD and hands off control to Kernel

    2 - Kernel re-initializes framebuffer (screen goes black...makes sense), but LCD data is still being clocked out

    3 - Kernel initializes and resets DSS, DISPC, Display, etc.  This is when the pixel clock stops and the LCD fades to white.  Even with skip init option checked in kernel, the DSS always performs a soft-reset, thus killing the pixel clock.  The documentation for that kernel option is very misleading.

    4 - Kernel performs some other initializations (Networking, Touchscreen, RTC, etc.)

    5 - Kernel sets DSS clocks and re-enables the display.  I can verify the 1~3 second delay between steps 3 and 5 because DPI outputs a warning that the pixel clock isn't precise.  At this point, the display goes to black again, but the display is up and running properly again

    So, why such a large delay between the DSS init and setting the LCD clocks?

    Also, I tried enabling the CONFIG_OMAP_RESET_CLOCKS option and it had no effect on the above procedure.  In fact, if you leave the DSS and OMAPFB modules out of the kernel entirely, the display stays active with the splash screen during boot, so I know the problem lies in the DSS or OMAPFB initialization.

  • 0 in reply to David Paden
    Intellectual 275 points

    Hi David:

    I found from a patch to the kernel that the feature to skip init was not working and was removed completely from the kernel code to avoid misleading. Have you gotten any response regarding this issue? I was trying to follow the path from the Denx git kernel (shared buffer approach) but it is implemented for other platform.

    Thanks

    Diego Chaverri

  • 0 in reply to Diego Chaverri
    Intellectual 500 points

    Hi Diego Chaverri,


    I am also facing the same issue, that is the delay between U-boot splash screen and Kernel splash screen because of the DSS initialization again in Kernel. Currently i am using the Kernel 2.6.32(Gingerbread) on DM37 processors. Can you tell me on which kernel patch the issue is resolved?