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.

[AM3354] LCD controller settings

Guru 24520 points

Hi community member,

Would you please provide advice for my problem?

[Problem]
Now my customer would like to use the LCD panel which it is not on EVM for their application. Thus, they modified the driver code (drivers/video/da8xx-fb.c ) of linux such as below.

***************************
[4] = {
.name = "Custom",
.width = 800,
.height = 480,
.hfp = 15,
.hbp = 15,
.hsw = 30,
.vfp = 2,
.vbp = 2,
.vsw = 6,
.pxl_clk = 37100000,
.invert_pxl_clk = 0,
},
*******************************

And they modified the "lcd_init" in "board-am335x_evm.c" in order to read this settings. However, the pxl_clk was 42MHz even though they have set the 37.1MHz.

Where should they modify the code in order to generate the expected clock for pxl_clk?

**************
SDK Version: 6.0
Device : AM3354B
***************
If you have any questions and necessary information, please let me know.
Best regards.
Kaka

  • Hi Kato-san,

    I have forwarded this to a SW expert, who will explain better than me where the issue lies. In a few words - we have come across this in SDK 6.0. The problem lies in the Display PLL initialization and calculations involved. You will need to initialize Display PLL to a frequency that is an integer multiple of the pixel clock you require. For 37.1MHz pixel clock this would be 185MHz or 186MHz PLL output frequency (200MHz is maximum allowed for LCDC input clock).

  • Hi ,

    To resolve the problem as Biser say you have to see in .../da8xx-fb.c there in da8xxfb_set_par(struct fb_info *info)
    do_div(pxl_clk, info->var.pixclock);
    par->pxl_clk = pxl_clk;
    first pxl_clk = 1000000000000ULL; and divide by your pixel clock 37100000 is an integer result. Next you have another action 1000000000000 / pxl_clk(previous calculated) and again result is integer. You can't calculate exact yours pixel clock (this is back conversion from picoseconds to frequency). Next to calculate divisor coefficient m and n driver will calculate 300000000/(new pixel clock) and result will be integer removing again fraction. This is a reason to choose in a board file frequent PLL that divide pixel clock to integer maths. To be sure you can calculate the right coefficient you can see them in LCD pixel clock divisor and in CM_CLKSEL_DPLL_DISP.

    You have to make in the following file changes:
    - in a board file - change 300000000 with 185MHz(186MHz)
    - in a driver da8xx-fb.c in da8xxfb_set_par(...) to remove mention two line or to calculate yourself, nut not to use do_div(...)
    - <>arch/arm/mach-omap2/clkt_dpll.c in omap2_dpll_round_rate(...) to see the m and n coefficient in dd->last_rounded_m and dd->last_rounded_n parameters.

    BR
    Ivan
  • HI Ivan,

    Thank you for your kindly support. Please let me confirm your comments.
    I am so beginner for LCD controller....

    1. Does "a board file" mean "board-am335x_evm.c"? Or which file?
    - in a board file - change 300000000 with 185MHz(186MHz)

    2. What do you mean "300000000"?
    3. Does this mean that they set the 185MHz/186MHz for Display PLL?
    4. Does the following mean that erase the following lines?
         "do_div(pxl_clk, info->var.pixclock);"
         "par->pxl_clk = pxl_clk;"?
    Your comment:
    - in a driver da8xx-fb.c in da8xxfb_set_par(...) to remove mention two line or to calculate yourself, nut not to use do_div(...)

    I calculated the values which you showed in previous Post.

    Where should we use those values?
    100000000000/37100000 = 26954.1779.... = 26954 
    100000000000/26954= 37100244.86 = 37100244(<- New Pixel clock)
    300000000/37100244 = 8.086200188 = 8

    5. How to calculate the value of m and n from this result??

    6. To summary your comment, should customer set the DPPL_DISP with 185MHz? And disable the automatic settings of Display PLL.

    If possible, would you please show me the example with my case?

    If you have any questions, please let me know.

    Best regards.
    Kaka

  • Hi Biser,

    Thank you for your response.
    This problem is caused by Display PLL settings and auto-calculation of pixel clock. Right?
    [Question]
    Would you please explain why customer need to set the 185MHz or 186MHz for Display PLL in order to generate the 37.1MHz pixel clock?

    In previous post, "Display PLL to a frequency that is an integer multiple of the pixel clock you require." However, the result of 185MHz/37.1MHz is not integer.

    Best regards.
    Kaka

  • I will try to give a more detailed explanation:

    1. LCD pixel clock is equal to the LCD functional clock divided by CTRL.clkdiv. LCD functional clock must be 200MHz maximum.
    2. LCD functional clock can be sourced from Display PLL, Core PLL or Peripheral PLL. This is selected by CLKSEL_LCDC_PIXEL_CLK register. Please note that default value of this register sources LCD functional clock from Display PLL, also note that Core PLL and Peripheral PLL clock sources have fixed values - PER PLL CLKOUTM2=192MHz and CORE PLL CLKOUTM5=250MHz.
    3. The Display PLL has three values that need to be set: M, N and M2 post-divider.

    Display PLL output clock = ((Main oscillator frequency * M) / (N + 1)) / M2

    Note that the M2 post-divider is not used in Linux. Therefore for 37.1MHz pixel clock you will need 185.5MHz LCD functional clock and  CTRL.clkdiv=5. The Display PLL can output either 185MHz or !86MHz. If you use 24MHz crystal the easiest choice would be to use N=23 and M=185 or 186 (M2=1 by default). In either case you will not be able to get exactly 37.1MHz but you should be close enough for the display to work properly.

  • Hi Biser,
    Thank you for your kindly support.
    I can understand that reason.

    Regarding to S/W questions, I will wait the Ivan.
    Best regards.
    Kaka
  • Hi Ivan,

    Would you please provide your answers by end of tomorrow morning in Japan time?
    I apologize for rush you.
    I requested from my customer to inform the initial report of the incident.

    Best regards.
    Kaka
  • Ivan is busy on another issue at the moment. Can you dump the following registers with the devmem2 tool and post their values:

    LCD_CTRL 0x4830E004
    CM_CLKMODE_DPLL_DISP 0x44E00498
    CM_CLKSEL_DPLL_DISP 0x44E00454
    CM_DIV_M2 0x44E004A4
    CLKSEL_LCDC_PIXEL_CLK 0x44E00534

  • Hi Biser,

    Thank you for your response.
    I request your requirement to my customer.
    If I get the feedback from them, I will inform to you again.

    I am waiting Ivan's answer at this time.

    Best regards.
    Kaka
  • Hi Biser,

    We got feedback from my customer.
    Would you please check them?

    address data
    LCD_CTRL 0x4830E004 0x00000701
    CM_CLKMODE_DPLL_DISP 0x44E00498 0x00000007
    CM_CLKSEL_DPLL_DISP 0x44E00454 0x00000C00
    CM_DIV_M2 0x44E004A4 0x00000201
    CLKSEL_LCDC_PIXEL_CLK 0x44E00534 0x00000000


    Best regards.
    Kaka
  • OK, here is what you have currently:

    LCD functional clock source is Display PLL, which is enabled and locked. Display PLL values are M=12, N=0, M2=1. I think you are running from a 25MHz main oscillator, so:

    LCD functional clock = (25MHz *12 / (0 + 1)) / 1 = 300MHz and this is absolutely incorrect. Maximum value for this clock must be 200MHz.

    After that pixel clock divisor is 7, so:

    LCD pixel clock = 300MHz / 7 = 42.86MHz

  • Hi Biser,

    Thank you for your response and kindly support.
    I could understand your comments.

    If we get the request from my customer to show the modify point, please let me re-ask questions which I have posted.

    If you have any question, please let me know.
    Best regards.
    Kaka

  • Hi Biser,

    Regarding to your comments, the input clock of LCDM is not over 200MHz.
    >> LCD functional clock = (25MHz *12 / (0 + 1)) / 1 = 300MHz and this is absolutely incorrect. Maximum value for this clock must be 200MHz

    In case of using SterterKIT, this also over the input clock (300MHz).

    > LCD_CTRL 0x4830E004 0x2101
    > CM_CLKMODE_DPLL_DISP 0x44E00498 0x7
    > CM_CLKSEL_DPLL_DISP 0x44E00454 0x1901
    > CM_DIV_M2 0x44E004A4 0x201
    > CLKSEL_LCDC_PIXEL_CLK 0x44E00534 0x0

    Is this also problem?

    If you have any questions, please let me know.
    Best regards.
    Kaka
  • Yes, according to AM335X TRM Rev. K Table 13-2 LCD functional clock maximum frequency is 200MHz.

  • Thank you for quick response.
    Do you have a plan to modify this code?

    Best regards.
    Kaka
  • I only work on the forum. I don't know what is planned on SW development.

  • Thank you for your response.
    Can you confirm whether the TRM description for input clock for LCDM is correct?
    The evaluation boards are work well even though it is over the 300MHz.

    Best regards.
    Kaka
  • I have alerted the factory team about this issue. Feedback will be posted here when available.

  • Thank you for your kindly support.
    I'll wait for you to confirm this.

    Best regards.
    Kaka
  • Hi Biser,

    Do you have any updates for my request?
    My customer requests us to answer for this as soon as possible.

    Best regards.
    Kaka
  • I already posted that I have alerted the factory team about this issue. Feedback will be posted here when available. I cannot give any time frame when that will be, depends on factory team schedules and priorities.

  • Hi Biser,
    Thank you for explaining about your status.
    If you have any update, please let me know.

    Best regards.
    Kaka
  • Hi Biser,

    Do you have any updates for this topics?

    Best regards.
    Kaka
  • Hi Kato-san,

    Ivan Matrakov sent you a friendship request a few days ago. Please check it and accept so that you can communicate with him offline.

  • Hi Biser,

    Thank you for your comments.
    I missed that message. I will contact with him.

    Best regards.
    Kaka