• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 400 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.

OMAP-L138: CPUFreq and Display Conflict

Clifton Barnes
Prodigy 155 points
Other Parts Discussed in Thread: OMAP-L138

I'm using the DaVinci-PSP-SDK-03.20.00.11 release for OMAP-L138 and enabling CPU frequency scaling in Linux on my board.  All of the frequency scaling is working correctly and changing the regulator voltage correctly.  However, whenever it is enabled, the LCD stop updating.  One difference with my board is a 26 MHz crystal is being used instead of the 24 MHz crystal on the EVM.  Could that be causing a problem with the CPU frequency scaling?  Does something have to be changed to account for the different crystal?  The LCD is using the LIDD interface in the LCD controller.  The image on the display (although not changing) continues to look fine, however, so I believe the interface to the display is working correctly.

 

Thanks for any help,

Clif

  • 0
    TI__Expert 8785 points

    What frequencies are you sweeping across?  Did you change your PLL configurations to account for the different crystal? 

    Is there a certain frequency transition (going from high to low, or low to high) that causes the LCD to stop working?  Is the LCD reading data from EMIFA or DDR2/mDDR?  If it is, are you changing the timing of the memory controller to account for the frequency change?

    --Christina

  • 0 in reply to clam
    Prodigy 155 points

    I'm using the frequencies from the da850.c file in the Linux kernel (300,200,90 MHz).  I've accounted for the different crystal in UBL, U-Boot and the Linux kernel.  There's no certain frequency where there's a problem.  In fact, if I only add 300 MHz to the frequency table for frequency scaling, the problem still exists.  I have to disable the cpufreq driver for the LCD to function correctly.  The DMA for the LCD controller is on and sending the data to the LCD through the LIDD interface.

  • 0 in reply to Clifton Barnes
    TI__Expert 8785 points

    I'm not very familiar with the Linux driver, so I moved this to the Linux forum.  It seems like there is something happening in the Linux driver.  Could it be that after frequency scaling the LCD needs to be reinitialized?

    Hopefully, someone familiar with the Linux driver will have more insight into the frequency scaling API and can provide more assistance.

    --Christina