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.

DM814x change clock

Other Parts Discussed in Thread: TPS65910, TMS320DM8148, AM3874, DM385

Hi,

In our custom DM8148 boards we have the DM8148 clocked to 600MHZ as I can see in
 u-boot

TI8148-GP rev 3.0

ARM clk: 600MHz
DDR clk: 400MHz

I2C:   ready
DRAM:  2 GiB
MMC:   OMAP SD/MMC: 0

How can I change to run in 1GHz? Are there some patches to modify u-boot and kernel to support this DM8148?

Regards!

  • Refer to the below E2E thread.

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/204555.aspx

    BR
    Pavel

  • Pavel Botev said:

    Refer to the below E2E thread.

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/204555.aspx

    Ok, I've changed the MODENA_M define and I show 1000MHz as the ARM clk but then the linux kernel doesn't boot. I'll try to check how to switch to the higher voltage, because the next command doesn't works in our board...

    TI8148_EVM#i2c mw 0x2D 0x22 0x3C

    Regards

  • Anonymous Developer said:
    but then the linux kernel doesn't boot.

    This is expected when the voltage is not changed (1.1V -> 1.35V).

    Anonymous Developer said:
    TI8148_EVM#i2c mw 0x2D 0x22 0x3C

    This command works with the PMIC IC integrated in the DM8148 EVM hardware. See the below E2E threads for more info:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/297053.aspx

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/228050/801772.aspx

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/275232.aspx

    Best Regards,
    Pavel

  • Pavel Botev said:

    This command works with the PMIC IC integrated in the DM8148 EVM hardware. See the below E2E threads for more info:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/297053.aspx

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/228050/801772.aspx

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/275232.aspx

    Very interesting links! Is there some patch in order to do correctly the switch of power in stage1 as explained by Diego Santa Cruz in the last link you give me?

    I'm interested raising the DDR3 to 533MHz and the DSP to 750MHz as you pointed in the first link because we're using a CYE1 DM8148 version... I'll read it all carefully, thanks!

    Regards

  • Anonymous Developer said:
    Is there some patch in order to do correctly the switch of power in stage1 as explained by Diego Santa Cruz in the last link you give me?

    Sorry but we do not have ready made u-boot patch for this. All the PSP u-boot patches are available at the below link:

    http://arago-project.org/git/projects/u-boot-omap3.git?p=projects/u-boot-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

    The Linux kernel PSP patches are available at:

    http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

    BR
    Pavel

  • Diego Santa Cruz said:

    Hi Pavel and Daniel,

    Sorry to correct, but the first stage of U-Boot does not run from SRAM, it runs from DDR. It is loaded to SRAM by the ROM boot code, but then it is moved to DDR by the low level initialization code. So it starts running from SRAM but only up until the cpu_init_crit assembly function returns. It is then moved to DDR by relocate and copy_loop in arch/arm/cpu/arm_cortexa8/start.S. BTW, stage 1 is compiled with TEXT_BASE = 0x80700000, which is an address in DDR.

    The cpu_init_crit assembly function calls lowlevel_init, s_init_start and finally s_init in evm.c and all PLLs and DDR is initialized from s_init().

    So it is not enough to write the PMIC registers in stage1, it must be done from s_init() before the PLLs are set up by prcm_init().

    I managed to do the I2C calls before the PLLs are set up by doing the following:

    • Remove the global variables from the I2C driver (drivers/i2c/omap24xx_i2c.c), they are not needed. They were intended for I2C multi bus configurations bus I2C multi bus is only partially implemented and totally broken.
    • Enable I2C in stage 1 by defining CONFIG_I2C in the minimal configuration
    • Move the initialization of DMTIMER1 out of per_clocks_enable() into a function that is called earlier, be it basic_timer_init(). It selects OSC0 as source for DMTIMER1, resets it and starts it with auto-reload enabled (auto-reload was not enabled in the original code). This makes it possible to use udelay(), which is called by the I2C driver, so it must be done before I2C can be used.
    • As the start of prcm_init() call basic_timer_init(), enable the I2C module (CM_ALWON_I2C_0_CLKCTRL), the I2C0 SDA and SCL pins, call i2c_init() and then write the PMIC registers as necessary to raise the voltages to 1.35V as required for OPP166. Note that the I2C module gets its clock from SYSCLK10, but this is already set up by the ROM boot code to be 48 MHz as expected by the I2C driver.

    It works like a charm, and the voltages are raised to the required level before initializing the PLLs.

    Just a remark: none of the functions called by s_init() can use static arrays, because the compiler generates absolute addresses to load these and absolute addresses do not work at that point, since U-Boot is not yet running from the expected address.

    Hi Pavel,

    One more question... Then is it needed to raised to the required level before initializing the PLLs as Diego Santa Cruz said is his post?

    I ask it because we can program the power regulator we're using to boot always at 1.35V and avoid the i2c programming but this chip can only be programmed once.

    Regards

  • Hello,

    I think if you configure the power regulator to boot at 1.35V you do not need to raise it to the required level (1.35V) before initializing the PLLs, as it would already be to the required level (1.35V).

    But I have never tested this, as I am working with the DM814x EVM.

    As far as I can tell, configuring the power regulator to fixed voltage (1.35V) will result in worse power management (higher power consumption) as the device will be not able to auto-switch to lower voltage when needed/possible.

    See DM814x TRM, section 2.1.4.3.1 Dynamic Voltage and Frequency Scaling


    Best Regards,
    Pavel

  • Pavel Botev said:

    I think if you configure the power regulator to boot at 1.35V you do not need to raise it to the required level (1.35V) before initializing the PLLs, as it would already be to the required level (1.35V).

    But I have never tested this, as I am working with the DM814x EVM.

    Sorry, I've explained wrong. I was wondering if it's possible to raise to 1.35 after the PLL configuration and so on, for instance, in uboot stage2, in order to have easy access to i2c instead of the uboot changes proposed by Diego.

    For instance, can I set DDR_PLL_533 instead of DDR_PLL_400 and then change from 1.1V to 1.35V?

    Regards

  • Yes, you can.

    I have never seen someone to report any kind of "brake" when doing this (first raise the DDR3 to 533MHz, then raise the voltage to 1.35V). Note that we have the same approach when raising the CPU to 1GHz.

    Best Regards,
    Pavel

  • Ok, just to clarify myself, with a DM8148 CYE1/2 you can change dinamically the voltage and the frequency as it's explained in

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_PM_DVFS_User_Guide

    I suppose an important element in this subsystem is the TPS65910, the integrated power-management IC, which has to be programmed with the correct voltage for every configuration. Isn't it? I suppose I can't test this in the evaluation board that I have because the DM8148 its a CYEF version...

    In our custom board I have compiled the support for DVFS in the kernel and I can see the supported frequencies: 600000 and 1000000. I can't change to 1GHz because I have to implement the support for our power-management IC but setting the 1GHz will change the DSP, DDR3 and SGX or only ARM core? I suppose that changing to OPP166 (1.35V) sets these items to DSP 700MHz, DDR3 533MHz and SGX 280MHz as is shown in Table 7-4 in 7.2.2.1 from TMS320DM8148 datasheet.

    Regards

  • See DM814x datasheet, section 9.1.2 Device and Development-Support Tool Nomenclature

    Only CYE device is limited to 600MHz ARM and  500MHz DSP.

    CYE0, CYE1 and CYE2 can be boost.

    Anonymous Developer said:
    I suppose an important element in this subsystem is the TPS65910

    Actually in the DM8148 EVM is used TPS659113 - http://www.ti.com/product/tps659113

    Anonymous Developer said:
    the integrated power-management IC, which has to be programmed with the correct voltage for every configuration. Isn't it?

    Yes, correct. But I would recommend you to ask your TPS659xx questions in our TPS659xx forum:

    http://e2e.ti.com/support/power_management/pmu/f/43.aspx

    Anonymous Developer said:
    I suppose I can't test this in the evaluation board that I have because the DM8148 its a CYEF version...

    I do not think TI has CYEF processor in its portfolio! At least CYEF is not described in the datasheet. And no one else ever reported something for CYEF processor.

    Anonymous Developer said:
    I can't change to 1GHz because I have to implement the support for our power-management IC but setting the 1GHz will change the DSP, DDR3 and SGX or only ARM core? I suppose that changing to OPP166 (1.35V) sets these items to DSP 700MHz, DDR3 533MHz and SGX 280MHz

    When you switch to OPP166, this does not automatically boost DSP, DDR3, SGX and ARM to the higher frequency. You should also modify the PLLs.

    For example, when you modify only ARM PLL for 1GHz and switch to OPP166, the rest (DSP, DDR3, etc) will remain in their previous frequency as their PLLs are not modified for the higher frequencies.

    BR
    Pavel

  • Hi Pavel,

    Pavel Botev said:

    Yes, correct. But I would recommend you to ask your TPS659xx questions in our TPS659xx forum:

    Thanks, It was only to set a common ground...

    Pavel Botev said:

    I do not think TI has CYEF processor in its portfolio! At least CYEF is not described in the datasheet. And no one else ever reported something for CYEF processor.

    The complete reference onto the chip is X8148X3874BCYEF ... Maybe its only a CYE...

    Pavel Botev said:

    When you switch to OPP166, this does not automatically boost DSP, DDR3, SGX and ARM to the higher frequency. You should also modify the PLLs.

    For example, when you modify only ARM PLL for 1GHz and switch to OPP166, the rest (DSP, DDR3, etc) will remain in their previous frequency as their PLLs are not modified for the higher frequencies.

    Ok, this was the info I was looking for... then from uboot board initialization code I show that I have to change:

    For ARM ->MODENA_M = 0x64

    For DSP -> DSP_N, DSP_M, DSP_M2, DSP_CLKCTRL ?

    For DDR3 -> DDR_N, DDR_M, DDR_M2, DDR_CLKCTRL ?

    For ISS -> ISS_N, ISS_M, ISS_M2, ISS_CLKCTRL ?

    For L3 core -> L3_N, L3_M, L3_M2, L3_CLKCTRL ?

    But what about the other subsystems in Table 7-4

    For HDVICP2 -> ??

    For HDVPSS -> ??

    For SGX -> ??

    For Media Ctlr -> ??

    For L4 core -> ??

    Regards

  • Anonymous Developer said:
    The complete reference onto the chip is X8148X3874BCYEF ... Maybe its only a CYE...

    OK, this is the processor for the DM8148/AM3874 EVM. As you have "TI8148-GP rev 3.0" message when boot-up, this means you are with PG3.0 processor and you can boost the corresponding modules.

    I will also check for the other questions.

    BR
    Pavel

  • Anonymous Developer said:

    For ARM ->MODENA_M = 0x64

    For DSP -> DSP_N, DSP_M, DSP_M2, DSP_CLKCTRL ?

    The formula about how to adjust the DPLL parameters for the target output frequency is documented in DM814x TRM, section 2.6 DPLLLJ (as DSP DPLL is of type DPLLLJ)

    Anonymous Developer said:
    For HDVICP2 -> ??

    HDVICP2 is also referred as IVA and IVA-HD. Thus the DPLL is IVA_PLL, and parameters are IVA_PLL_BASE, IVA_N, IVA_M, IVA_M2, IVA_CLKCTRL

    Anonymous Developer said:
    For HDVPSS -> ??

    HDVPSS is also referred as DSS. Thus the DPLL is DSS_PLL (DSS_PLL_BASE). But this DPLL is not configured/initialized in u-boot.

    Anonymous Developer said:
    For SGX -> ??

    The PLL is SGX_PLL (SGX_PLL_BASE) but this PLL is not configured/initialized in u-boot. See the below E2E thread for more info:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/316859.aspx

    Anonymous Developer said:
    For Media Ctlr -> ??

    The Media Controller (Cortex-M3 ARM processor) and ISS subsystem share the same PLL, the ISS PLL. The only difference is that the output of the ISS PLL goes directly to the ISS and through fix-by-2 divider to the M3. Thus when you have 400MHz for ISS, you have 200MHz to M3. And when you have 560MHz to ISS you have 280MHz to M3.

    Anonymous Developer said:
    For L4 core -> ??

    L3 and L4 interconnects are supplied from the L3 interconnect PLL (L3 PLL)

    Best regards,
    Pavel

  • Hi Pavel,

    From your last post is not clear how to set

    For DDR3 -> DDR_N, DDR_M, DDR_M2, DDR_CLKCTRL ?

    For ISS -> ISS_N, ISS_M, ISS_M2, ISS_CLKCTRL ?

    For L3 core -> L3_N, L3_M, L3_M2, L3_CLKCTRL ?

    For DSP -> DSP_N, DSP_M, DSP_M2, DSP_CLKCTRL ?

    what are the values to get the OPP166?

    Pavel Botev said:

    HDVICP2 is also referred as IVA and IVA-HD. Thus the DPLL is IVA_PLL, and parameters are IVA_PLL_BASE, IVA_N, IVA_M, IVA_M2, IVA_CLKCTRL

    And the values to get the OPP166?

    Pavel Botev said:

    HDVPSS is also referred as DSS. Thus the DPLL is DSS_PLL (DSS_PLL_BASE). But this DPLL is not configured/initialized in u-boot.

    Where is initialized? In kernel? In the custom firmware? Then how can we set the OPP166 mode?

    Pavel Botev said:

    The PLL is SGX_PLL (SGX_PLL_BASE) but this PLL is not configured/initialized in u-boot. See the below E2E thread for more info:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/316859.aspx

    Ok, I have to change 'ti-ezsdk_dm814x-evm_5_05_02_00/component-sources/graphics-sdk_4.04.00.02/GFX_Linux_KM/services4/srvkm/devices/sgx/sgxinit.c' to set

    PLL_Clocks_Config((UWORD32)pll_base,OSC_0,19,1120,4,ADPLLJ_CLKCRTL_HS2);

    and rebuild the 'pvrsrvkm.ko' module

    Pavel Botev said:

    The Media Controller (Cortex-M3 ARM processor) and ISS subsystem share the same PLL, the ISS PLL. The only difference is that the output of the ISS PLL goes directly to the ISS and through fix-by-2 divider to the M3. Thus when you have 400MHz for ISS, you have 200MHz to M3. And when you have 560MHz to ISS you have 280MHz to M3.

    Ok, then the values to ISS_N, ISS_M, ISS_M2, ISS_CLKCTRL to set the OPP166 mode?

    Sorry, for re-asking but It could be interesting if we have a centralized place where we can check this values instead of going from one link to another or calculate ourselves... Imagine that I only want to set this mode not to become an expert setting the TI8148 clocks, pll, etc :)

    Regards

  • Anonymous Developer said:
    For DDR3 -> DDR_N, DDR_M, DDR_M2, DDR_CLKCTRL ?

    1. Change file u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch-ti81xx/clocks_ti814x.h

    #define DDR_M        (pg_val_ti814x(666, 800))

    to

    #define DDR_M        (pg_val_ti814x(666, 1066))

    Thus DDR_M = 1066 (533MHz), not 800 (400MHz)

    2. Change file u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch-ti81xx/ddr_defs_ti814x.h as follows

    /* TI814X DDR3 EMIF CFG Registers values 400MHz */
    #define DDR3_EMIF_READ_LATENCY        0x00173209
    #define DDR3_EMIF_TIM1            0x0AAAD4DB
    #define DDR3_EMIF_TIM2            0x682F7FDA
    #define DDR3_EMIF_TIM3            0x501F82BF
    #define DDR3_EMIF_REF_CTRL        0x00000C30
    #define DDR3_EMIF_SDRAM_CONFIG        0x61C011B2
    #define DDR3_EMIF_SDRAM_ZQCR        0x50074BE1
    #endif

    to

     
    /* TI814X DDR3 EMIF CFG Registers values 533MHz */
    #define DDR3_EMIF_READ_LATENCY      0x0017320B
    #define DDR3_EMIF_TIM1              0x0EEF2664
    #define DDR3_EMIF_TIM2              0x303F7FE2
    #define DDR3_EMIF_TIM3              0x501F83AF
    #define DDR3_EMIF_REF_CTRL          0x0000103D
    #define DDR3_EMIF_SDRAM_CONFIG      0x61C121B2
    #define DDR3_EMIF_SDRAM_ZQCR        0x50074BE1
    #endif

    I will further check for the other PLLs.

    BR
    Pavel

  • Anonymous Developer said:
    For ISS -> ISS_N, ISS_M, ISS_M2, ISS_CLKCTRL ?

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch/clocks_ti814x.h

    #define ISS_M        1120 //800

    The formula is:

    iss_freq = ((OSC_0_FREQ / (ISS_N + 1) * ISS_M) / ISS_M2);

    Anonymous Developer said:
    For L3 core -> L3_N, L3_M, L3_M2, L3_CLKCTRL ?

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch/clocks_ti814x.h

    /*#define L3_M        (pg_val_ti814x(880, 800))*/ //L3_M = 800

    #define L3_M        (pg_val_ti814x(880, 880)) //L3_M = 880

    The formula is:

    l3_freq = ((OSC_0_FREQ / (L3_N + 1) * L3_M) / L3_M2);

    Anonymous Developer said:
    For DSP -> DSP_N, DSP_M, DSP_M2, DSP_CLKCTRL ?

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch/clocks_ti814x.h

    #define DSP_M        750 //500

    I will further check for the rest of the questions.

    BR
    Pavel

  • Anonymous Developer said:

    HDVICP2 is also referred as IVA and IVA-HD. Thus the DPLL is IVA_PLL, and parameters are IVA_PLL_BASE, IVA_N, IVA_M, IVA_M2, IVA_CLKCTRL

    And the values to get the OPP166?

    [/quote]

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch/clocks_ti814x.h

    /*#define IVA_M        (pg_val_ti814x(612, 612))*/ //IVA_M = 612

    #define IVA_M        (pg_val_ti814x(612, 900)) //IVA_M = 900

    The formula is:

    iva_freq = ((OSC_0_FREQ / (IVA_N + 1) * IVA_M) / IVA_M2);

    BR
    Pavel

  • Anonymous Developer said:

    HDVPSS is also referred as DSS. Thus the DPLL is DSS_PLL (DSS_PLL_BASE). But this DPLL is not configured/initialized in u-boot.

    Where is initialized? In kernel? In the custom firmware? Then how can we set the OPP166 mode?

    [/quote]

    After more close look, it turns out that HDVPSS PLL is initialized/configured in u-boot, but not in the same place as the rest of the PLLs (ARM, ISS, DDR, etc)

    As you know most of the DM814x PLLs are initialized/configured in the u-boot evm.c file based on the settings from the u-boot clocks_ti814x.h.

    While the HDVPSS PLL is initialized/configured in the u-boot ti814x_logo.c file, with hardcoded settings for the HDVPSS PLL, there is no header file for these settings:

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/drivers/video/ti814x_logo.c

    /**
     * Configure PLL for HDVPSS unit
     */
    static void ti814x_pll_config_hdvpss(void)
    {
        u32 rd_osc_src;
        rd_osc_src = __raw_readl(PLL_VIDEO2_PINMUX);
        rd_osc_src &= 0xFFFFFFFE;
        __raw_writel(rd_osc_src, PLL_VIDEO2_PINMUX);
        ti814x_pll_configure(PLL_HDVPSS_BASE, 19, 800, 4, 0x00000801);
    }

    This configuration is for OPP100/200MHz. For OPP166/220MHz you should update this file:

    ti814x_pll_configure(PLL_HDVPSS_BASE, 19, 880, 4, 0x00000801);

    Thus the HDVPSS PLL M value will be 880 (previous 800).

    After boot up everything (u-boot, linux kernel, firmware, file system), you can check all device clocks and frequencies from the Debugfs, see the below wiki for more info:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_PM_CLOCK_FRAMEWORK_User_Guide#Browsing_DebugFs_for_Clock_configuration

    Anonymous Developer said:
    Sorry, for re-asking but It could be interesting if we have a centralized place where we can check this values instead of going from one link to another or calculate ourselves... Imagine that I only want to set this mode not to become an expert setting the TI8148 clocks, pll, etc :)

    Sorry but we do not have such centralized place for all these things we discuss. From now on I will consider this E2E thread as such centralized place for PLLs configuration and boost :)

    BR
    Pavel

  • Hi Pavel!

    Pavel Botev said:

    Sorry but we do not have such centralized place for all these things we discuss. From now on I will consider this E2E thread as such centralized place for PLLs configuration and boost :)

    Thaks you Pavel! I'm waiting for the hardware guy to fix me the 1.35V in our board then I'll check all the changes you have outline here. I'll report the findings in order to leave a complete thread for everyone looking the same

    Regards!

  • Hi Pavel,

    I've been able to boot in 1GHz mode.The clocks I can read are:

    ARM Core 1GHZ
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/arm_dpll_clkin_ck/arm_dpll_ck/rate
    1000000000

    DSP clock a 750MHz
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/dsp_dpll_ck/rate
    750000000

    L3 core clock 220MHz
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/l3_dpll_clkin_ck/l3_dpll_ck/rate
    220000000

    HDVPSS clock 220MHz
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/hdvpss_dpll_ck/rate
    220000000

    I've made some corrections to adapt to CYE1. With your values the ISS was at 560MHz and HCVICP2 at 450MHz (CYE2?) then:

    ISS clock 480MHz
    #define ISS_M        960
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate
    480000000


    HDVICP2 clock 410MHz
    #define IVA_M        (pg_val_ti814x(612, 820))
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/hdvicp_dpll_ck/rate
    410000000

    The DDR3 with your values for DDR3_EMIF_* doesn't boot. I'm recalculating it to our DDR3 memory chips. The clock can be read as:

    DDR3 clock a 400MHz
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/ddr_dpll_clkin_ck/ddr_dpll_ck/rate
    400000000

    And finally, the SGX clock is not changed. I read 200MHz instead of 280MHz.

    # cat /sys/kernel/debug/clock/osc0_clkin_ck/sgx_dpll_ck/rate
    20000000
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/sgx_dpll_ck/sysclk23_ck/rate
    5000000
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/sgx_dpll_ck/sysclk23_ck/sgx_ck/rate
    5000000
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/sgx_dpll_ck/sysclk23_ck/sgx_sys_ck/rate
    5000000
    # cat /sys/kernel/debug/clock/osc0_clkin_ck/sgx_dpll_ck/sysclk23_ck/sgx_mem_ck/rate
    5000000


    I'll try to use the scope as you pointed in http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/316859.aspx

    Regards

  • Anonymous Developer said:
    With your values the ISS was at 560MHz and HCVICP2 at 450MHz (CYE2?)

    Yes, the values I have provided are for CYE2

    Anonymous Developer said:
    The DDR3 with your values for DDR3_EMIF_* doesn't boot.

    Can you try these values on the DM8148 EVM, can the DDR3 533MHz boot in EVM with these values?

    Anonymous Developer said:
    the SGX clock is not changed

    Yes, this is expected. The Debugfs reports what has been set in the linux kernel, while SGX PLL is set at later stage. See this post:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/316859/1103847.aspx#1103847

    BR
    Pavel

  • Hi,

    Pavel Botev said:

    Can you try these values on the DM8148 EVM, can the DDR3 533MHz boot in EVM with these values?

    Yes, it works with the values you posted:

    # cat /sys/kernel/debug/clock/osc0_clkin_ck/ddr_dpll_clkin_ck/ddr_dpll_ck/rate
    533000000

    Pavel Botev said:

    Yes, this is expected. The Debugfs reports what has been set in the linux kernel, while SGX PLL is set at later stage. See this post:

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/316859/1103847.aspx#1103847

    Yes, that's the link I've posted too... I'm trying to check with the scope this clock.

    Thanks!

  • Hi,

    Anonymous Developer said:

    Yes, it works with the values you posted:

    # cat /sys/kernel/debug/clock/osc0_clkin_ck/ddr_dpll_clkin_ck/ddr_dpll_ck/rate
    533000000

    Then these values should be specific for your custom board depending on the external DDR3 chips you are using. Refer to the below wiki page:

    http://processors.wiki.ti.com/index.php/TI814x-DDR3-Init-U-Boot

    Regards

  • Hi,

    Now all is working. I can't check the SGX clock because I don't have access to clkout0/1 then I'll do it empirically... running an opengl demo and get the fps booting in both modes.

    Thanks for your help Pavel,

    Regards

  • Hi ,if i want to change the iss frequency to 560,I Is it right? As long as put ISS_M into 11200 ,do i need to change the voltage? and how can I confirm my frequency is correct.

  • Hi Shupeng,

    shupeng hu said:
    if i want to change the iss frequency to 560,I Is it right?

    If you have CYE2 device, then you can boost the ISS to 560MHz.

    shupeng hu said:
    As long as put ISS_M into 11200 ,do i need to change the voltage?

    You need to set ISS_M to 1120, not to 11200. Yes, you need to change the voltage from 1.1V to 1.35V.

    shupeng hu said:
    and how can I confirm my frequency is correct.

    You can use the clock framework:

    #cat /sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate

    Regards,
    Pavel

  • Shupeng,

    shupeng hu said:
    and how can I confirm my frequency is correct.

    You can also connect a wire to the clkout0/1 pin, export the DPLL_ISS clock out signal to that pin and measure its value with scope. See DM814x TRM, section 2.3.11 Clock Output Pin

    Regards,
    Pavel

  • Thank you for your answer ,But I have two more questions;

    First ,I have no such file system directory “/sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate”,What should I do?

    Second ,if I don't have changed the the voltage from 1.1V to 1.35V, the value of  /sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate will be 560MHz?

  • Shupeng,

    shupeng hu said:
    First ,I have no such file system directory “/sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate”,What should I do?

    Once you boot up your board, you should mount the debugfs. See the below wiki page for more info:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_PM_CLOCK_FRAMEWORK_User_Guide#Browsing_DebugFs_for_Clock_configuration

    shupeng hu said:
    Second ,if I don't have changed the the voltage from 1.1V to 1.35V, the value of  /sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate will be 560MHz?

    If you do not have changed the voltage from 1.1V to 1.35V, your linux kernel (uImage) will not be able to boot up. Thus you will stuck far before you will be able to check the ISS freq value.

    Best regards,
    Pavel

  • Thanks for your help, I can read the /sys/kernel/debug/clock/osc0_clkin_ck/iss_dpll_ck/rate,is 560000000.But I still have some questions,I'm sorry to ask you once again.

    First,Although I can read the rate is 560000000,but I don't even change the voltage from 1.1V to 1.35V,  I could read the rate is 560000000,and the linux kernel (uImage) can boot up,so ,I wonder if I have changed the iss frequency successfully.Can read out this rate value can be set as the criteria to judge success?

    Second,I try to export the ISS_DPLL clock out signal to that pin and measure its value with scope.And I choose" Source is ISP_DPLL_OUT_DIV2" ,so I set the CLKOUT_MUX register a value of 0x4,But the cycle of the waveform is 5 ns,the frequency is 200MHZ.What went wrong?

  • Shupeng,

    shupeng hu said:
    First,Although I can read the rate is 560000000,but I don't even change the voltage from 1.1V to 1.35V,  I could read the rate is 560000000,and the linux kernel (uImage) can boot up,so ,I wonder if I have changed the iss frequency successfully.

    I check this on my side, and I confirm the linux kernel boot up without switch to 1.35V. It seems that the linux kernel boot up stuck only for the ARM (when switch from 600MHz to 1GHz and keep at 1.1V), but not for the ISS.

    shupeng hu said:
    Can read out this rate value can be set as the criteria to judge success?

    I think yes, as by default, this value is 400000000. You can also modify the u-boot source to report you the ISS frequency (by default u-boot reports ARM and DDR frequency):

    ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/cpu/arm_cortexa8/ti81xx/sys_info.c

    int print_cpuinfo (void)
    {
        char *cpu_s, *sec_s;
        int arm_freq, ddr_freq, iss_freq, rev;

    .......

    #else
    /* clk_out  = ((OSC_0/ ( N+1 )) * M) / M2   */
        arm_freq = ((OSC_0_FREQ / (MODENA_N + 1) * MODENA_M) / MODENA_M2);
        ddr_freq = ((OSC_0_FREQ / (DDR_N + 1) * DDR_M) / DDR_M2);
        iss_freq = ((OSC_0_FREQ / (ISS_N + 1) * ISS_M) / ISS_M2);
    #ifdef CONFIG_DM385

    ....

    #endif
        printf("ARM clk: %dMHz\n", arm_freq);
        printf("DDR clk: %dMHz\n", ddr_freq);
        printf("ISS clk: %dMHz\n", iss_freq);
    #ifdef CONFIG_DM385

    Thus the u-boot will report (when ISS_M = 1120):

    ARM clk: 600MHz
    DDR clk: 400MHz
    ISS clk: 560MHz

    By default u-boot will report (when ISS_M = 800):

    ARM clk: 600MHz
    DDR clk: 400MHz
    ISS clk: 400MHz

    shupeng hu said:
    ISP_DPLL_OUT_DIV2" ,so I set the CLKOUT_MUX register a value of 0x4,But the cycle of the waveform is 5 ns,the frequency is 200MHZ


    The value on the pin is after div2 (ISP_DPLL_OUT_DIV2), so the actual value is 400MHz. Can you try with switching to 1.35V, will you have the same value on the pin?

    Regards,
    Pavel

  • Now,I can read the frequency is 560M by export the ISS_DPLL clock out signal to that pin, but the voltage is still 1.2 v,and I change the voltage from 1.2 to 1.35 later, nothing happened, is this phenomenon  no problem?

    In fact,I change the frequency of ISS in order to solve this problem.Video capture rate can reach 25 frames,but the  code rate can only reach 23 frames,and the emergence of "Buffer switch failed for stream ID:0" error.So ,i want to increase the frequency of ISS.But there is no effect.

    This idea is it right?And how can I  improve the coding rate.

    Thank you.

  • Shupeng,

    Are you sure that video capture is done from the ISS (not from the HDVPSS)? You can also try to increase the freq of HDVPSS, HDVICP2 and Cortex-M3.

    BR
    Pavel

  • I think so, but maybe I was wrong.