VIDEO1PLL setting change

Michi-san,

1. I want to note that we have PLLSS_MMR_LOCK register, which is used to allow/block access to the PLL registers. Make sure you are writing the value of 517622845 (0x1EDA4C3D) in it before accessing the PLL registers.

2. I think that we can change "on-the fly" only M2 and N2 values. To change the N value you should first change the state of the PLL from locked to unlocked/bypassed, then change the N value, then lock it.

Regards,
Pavel

Michi,

What is the customer really trying to do? Why are they directly changing the PLL rather than using the APIs?

BR,

Steve

Dear Pavel-san,

Thank you for your reply.

Customer set "517622845(Unlock value) to PLLSS_MMR_LOCK register certainly.

But "N" parameter can't be changef from default setting (N=13h) to other value.

Are there any other registers that customer should be set?

Please advise me again.

Best regards,

Michi

Dear Steve-san,

Thank you for your reply.

Customer would like to change the display setting (LCD) when booting. Customer displays some message before OS(WEC7) boot up.

For this reason, they can't use APIs of OS.

Best regards,

Michi

The boot logo code should already have settings for all the video parameters including the pixel clock.

I suggest using the existing code rather than changing the frequency later by forcing the PLL.

BR,

Steve

Michi Yama said:

But "N" parameter can't be changef from default setting (N=13h) to other value.

Michi-san,

I think you can not change the "N" parameter dynamically (on-the-fly), while the PLL is locked and active. You need first to put the PLL in idle bypass mode, through programming the VIDEO1PLL_CLKCTRL and monitor the VIDEO1PLL_STATUS register. Then once in idle bypass mode, you should change the "N" parameter through programming the VIDEO1PLL_M2NDIV register. Then you should load the "N" value through programming the VIDEO1PLL_TENABLE register (write 0x1, then write 0x0). Then you need to lock the PLL, then the new frequency should be generated.

Regards,
Pavel

Dear Steve-san,

Thank you for your reply.

>The boot logo code should already have settings for all the video parameters including the pixel clock.

>I suggest using the existing code rather than changing the frequency later by forcing the PLL.

Do you mention M3 firmware? If you advise us to use M3 firmwware, unfortunately we can't use it because of we don't have the source code, command information and so on.

Best regards,

Michi

Dear Pavel-san,

Thank you for your cooperation.

Customer succeeded to change "N" parameter using CCS based on your advice. From now on, customer implement it to the code. So I have one question.

According to the TRM, PLL module enters to bypass mode with TINITZ=1 and IDLE=1 setting. But according

to the customer's result, PLL module enters to bypass mode with TINITZ=0 and IDLE=1 setting. Customer says always TINITZ=1. This is different from TRM. Is this typo?

Please advise me again.

Best regards,

Michi 

Hi Michi,

boot logo code does not support pixel clock for all resolution, there is no generic code for calculating these parameters and configure it. it supports few pixel clock configurations, Please calculate your required pixel clock and required video pll parameters and use the code in boot logo to configure it.

Rgds,

Brijesh

Dear Brijesh-san,

Thank you for your reply.

Where is the boot logo code? Is it included in Linux SDKV(ver5.04.00.11)? 

But our customer does not use Linux OS. How does customer use its Boot logo code?

Best regards,

Michi

Hi Michi,

You could get the public repository for uboot code from dvr-rdk at below link

http://arago-project.org/git/projects/?p=u-boot-dvr-rdk-dm81xx.git;a=shortlog;h=refs/heads/dvrrdk_uboot_int_branch

You could get the boot logo code from

u-boot-dvr-rdk\common\cmd_logo_816x.c or cmd_logo_814x.c depending on soc has the source code

Regards,

Brijesh

Dear Brijesh-san,

Thank you for your quick reply.

I have one question.

Our customer does not use Linux OS. They use WEC7 OS. 

So, customer development environment is Visual Studio 2008. 

Can "cmd_logo_814x.c" be build by VS2008 without issue?

Please advise me again.

Best regards,

Michi

Hi Michi,

It should get compiled as it is pure c code. you will require below extra header and source files

Header file (logo_ti81xx.h/hdmi_cfg.h/vpdma firmware.h) are in uboot\include folder

HDMI control is in file hdmi_lib.c

Rgds,

Brijesh

Michi,

Michi Yama said:

Dear Pavel-san,

Thank you for your cooperation.

Customer succeeded to change "N" parameter using CCS based on your advice. From now on, customer implement it to the code. So I have one question.

According to the TRM, PLL module enters to bypass mode with TINITZ=1 and IDLE=1 setting. But according

to the customer's result, PLL module enters to bypass mode with TINITZ=0 and IDLE=1 setting. Customer says always TINITZ=1. This is different from TRM. Is this typo?

Please advise me again.

Per my understanding, when TINITZ = 1 and IDLE=1, we enter into the idle bypass low-power mode. But in order to be able to change the PLL parameters (like N divider), we should also program the TINITZ bit.

Regards,
Pavel

Pavel-san,

Thank you for your quick reply.

> But in order to be able to change the PLL parameters (like N divider), we should also program the TINITZ bit.

You said as the above. What does this mean?

From TRM description,  TINITZ bit always 0h?(reset value). And when we change the PLL parameters, we should

set TINITZ bit from 0 to 1. Is my understanding right?

However, from customer's result, TINITZ bit always 1h. And when they change the PLL parameters, they had to set TINITZ bit from 1 to 0.

"program the TINITZ bit", which does this mean bit set or bit clear?

Please advise me again.

Best regards,

Michi

Michi-san,

Michi Yama said:

> But in order to be able to change the PLL parameters (like N divider), we should also program the TINITZ bit.

You said as the above. What does this mean?

From TRM description,  TINITZ bit always 0h?(reset value). And when we change the PLL parameters, we should

set TINITZ bit from 0 to 1. Is my understanding right?

However, from customer's result, TINITZ bit always 1h. And when they change the PLL parameters, they had to set TINITZ bit from 1 to 0.

"program the TINITZ bit", which does this mean bit set or bit clear?

Please advise me again.

Michi-san,

These are the steps to re-configure the VIDEO1PLL:

1. write VIDEO1PLL_CLKCTRL[23] IDLE = 1 //thus you start transition from locked/active to bypass/idle mode

2. wait while VIDEO1PLL_STATUS[8] BYPASSACK == 1 and VIDEO1PLL_STATUS[0] BYPASS == 1

Now the VIDEO1PLL is in bypass/idle mode.

3. clear bit VIDEO1PLL_CLKCTRL[0] TINITZ = 0

Now the VIDEO1PLL can be programmed with new N divider value

4. write the VIDEO1PLL_M2NDIV[7:0] N bitfield with the new N divider value

Now latch the new N value

5. write bit VIDEO1PLL_TENABLE[0] TENABLE to 0x1

6. clear bit VIDEO1PLL_TENABLE[0] TENABLE to 0x0

Now lock the PLL

7. write VIDEO1PLL_CLKCTRL[23] IDLE = 0, [12:10] SELFREQDCO = 0x2, [0] TINITZ = 1

8. wait while the VIDEO1PLL is locked, through checking the VIDEO1PLL_STATUS[10] PHASELOCK == 1 and [9] FREQLOCK == 1

Thus flow is used in the DM814x EZSDK GEL file: 0677.DM814x_PG2.x.gel

ti-ezsdk_dm814x-evm_5_05_02_00/board-support/host-tools/DM814x_gel.zip/DM814x_PG2.x.gel:

cmdVIDEO1PLL(CLKIN,19, 600,4);

cmdVIDEO1PLL(int CLKIN,int N, int M, int M2)
{
        DCOCLK_COMP(CLKIN,N,M);
        if(HSMODE == 2){   
            PLL_Clocks_Config(VIDEO_1_PLL_BASE,CLKIN,N,M,M2,ADPLLJ_CLKCRTL_HS2);  
             GEL_TextOut("\t VIDEO-1 ADPLLJ CLKOUT  value is  = %d \n",,,,,CLKOUT);
        }
        else if (HSMODE == 1){
            PLL_Clocks_Config(VIDEO_1_PLL_BASE,CLKIN,N,M,M2,ADPLLJ_CLKCRTL_HS1);  
             GEL_TextOut("\t VIDEO-1 ADPLLJ CLKOUT  value is  = %d \n",,,,,CLKOUT);
        }
        else {
                  GEL_TextOut("\t VIDEO-1 PLL NOT Configured.Wrong DCOCLK Output\n");
        }
 
}

DCOCLK_COMP(int CLKIN,int N, int M)
 {
         int DCOCLK;
        DCOCLK = (CLKIN/(N+1))*M;
        
        if(DCOCLK >= 500 && DCOCLK < 1000){
                HSMODE = 2;  //HS2 Mode  
        }
        else if(DCOCLK >= 1000 && DCOCLK < 2000){
                HSMODE = 1;  //HS1 Mode
        }
        else HSMODE = 0;  //wrong configuration
        
        //return HSMODE;
 }

PLL_Clocks_Config(UWORD32 Base_Address,UWORD32 CLKIN,UWORD32 N,UWORD32 M,UWORD32 M2,UWORD32 CLKCTRL_VAL)
{
    UWORD32 m2nval,mn2val,read_clkctrl,clk_out,ref_clk,clkout_dco = 0;
    m2nval = (M2<<16) | N;
    mn2val =  M;
    ref_clk     = CLKIN/(N+1);
    clkout_dco  = ref_clk*M;
    clk_out     = clkout_dco/M2;
    WR_MEM_32(Base_Address+CLKCTRL, RD_MEM_32(Base_Address+CLKCTRL)|0x00800000);
    while (( (RD_MEM_32(Base_Address+STATUS)) & 0x00000101) != 0x00000101);
    WR_MEM_32(Base_Address+CLKCTRL, RD_MEM_32(Base_Address+CLKCTRL)& 0xfffffffe); //TINITZ=0
    wait_delay(3);
    WR_MEM_32((Base_Address+M2NDIV    ),m2nval); //write N value
    WR_MEM_32((Base_Address+MN2DIV    ),mn2val);
    wait_delay(3);
    WR_MEM_32((Base_Address+TENABLEDIV),0x1);
    wait_delay(3);
    WR_MEM_32((Base_Address+TENABLEDIV),0x0);
    wait_delay(3);
    WR_MEM_32((Base_Address+TENABLE   ),0x1);
    wait_delay(3);
    WR_MEM_32((Base_Address+TENABLE   ),0x0);
    wait_delay(3);
    read_clkctrl = RD_MEM_32(Base_Address+CLKCTRL);
    //configure the TINITZ(bit0) and CLKDCO BITS IF REQUIRED
    WR_MEM_32(Base_Address+CLKCTRL,(read_clkctrl & 0xff7fe3ff) | CLKCTRL_VAL); //TINITZ = 1
    read_clkctrl = RD_MEM_32(Base_Address+CLKCTRL);
    // poll for the freq,phase lock to occur
    while (( (RD_MEM_32(Base_Address+STATUS)) & 0x00000600) != 0x00000600);
    //wait fot the clocks to get stabized
    wait_delay(10);
    CLKOUT    = clk_out;
}

Regards,
Pavel

Dear Pavel-san,

Thank you for your support.

I have one question regarding PLL Linux source "code.

After some value is written in register, wait_delay(3) is called.

Why is wait routine required? Also why is it "3"?  "2" is not enough?

Please advise me.

Best regards,

Michi

Michi-san,

Michi Yama said:

I have one question regarding PLL Linux source "code.

This is not Linux code. This is GEL file code. The GEL file should be used with CCStudio. The GEL file replace the ROM code and the u-boot code.

Michi Yama said:

Why is wait routine required?

The author/owner of the GEL file decided to ensure that the PLL hardware/registers has enough time to accept the write commands. I think this is not obligatory, as in the u-boot code, we do not have such wait routines:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/265619/935572.aspx#935572

Also I remove/comment these wait routines from the GEL file, then the VIDEO1PLL configuration and lock-up works fine without these wait routines:

Scripts -> Centaurus2 INDIVIDUAL PLL Config -> Video_1_PLL_Config

In both cases (with and without wait routines) I have successful result:

CortexA8: Output:      ****  CENTAURUS2 VIDEO-1 ADPLL INIT IS in Progress .........
CortexA8: GEL Output:      VIDEO-1 ADPLLJ CLKOUT  value is  = 150

Michi Yama said:

Also why is it "3"?  "2" is not enough?

This "3" was the GEL file writer/owner decision. "2" is enough, "1" is enough, even no wait routine works fine on my side.

Regards,
Pavel