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.

Linux/OMAP-L138: Clock device tree support in latest Davinci Git

Part Number: OMAP-L138
Other Parts Discussed in Thread: DA8XX

Tool/software: Linux

I'm working on implementing a device tree for my OMAP L-138 based platform. I am using Linux and have recently pulled from the most recent davinci git. I realize that this tree pulls from mainline and is currently pulling in rc's, however I feel like this has possibly been a problem for awhile or was never fully supported.

Here is a description of my problem:

  1. Compile and load kernel
  2. U-Boot starts kernel and passes in device tree blob
  3. Kernel decompresses and then ceases to print anything else

I've determined that this is because all

of_platform_serial_probe

calls are failing, leaving the kernel without a valid console. Here is the chain of calls that cause the probe to fail:

  1. of_platform_serial_probe
    1. of_platform_serial_setup
      1. devm_clk_get
        1. clk_get

Looking at the disassemby, I see that

__of_clk_get_by_name

is compiled out of the clk_get call (pulled from CCS):

E2503000 SUBS          R3, R0, #0x0
01A00003 MOVEQ         R0, R3
0A000002 BEQ           0xC018F9DC
E593002C LDR           R0, [R3, #0x2C]
E3500000 CMP           R0, #0x0
05930008 LDREQ         R0, [R3, #0x8]
EAFFFFBF B             clk_get_sys

This means that clk_get_sys get called with dev_id = "1d0c000.serial" or a similar address. However, the file da850.c sets up the device id's for the uart clocks as follows:

static struct clk_lookup da850_clks[] = {
...
        CLK("serial8250.0",     NULL,           &uart0_clk),
        CLK("serial8250.1",     NULL,           &uart1_clk),
        CLK("serial8250.2",     NULL,           &uart2_clk),
...
};

This causes clock lookup and thus probe to fail.

I believe this is because CONFIG_COMMON_CLK is not set, causing 

__of_clk_get_by_name

to be invalid. Going through the menuconfig, I don't clearly see any way to enable this.

Is there something that I'm missing here to get device tree clock lookup to work correctly on my platform? Am I actually supposed to be able to enable this option? Or is there another solution to get this working correctly without modifying 8250/clk kernel code?

As a workaround I could rename all of the clock dev_id's to "address.device" in da850.c, but that seems like an incorrect solution to my problem.

  • Hi,

    You need to modify the Kconfig file so that you have select COMMON_CLK under your platform. I am not familiar with the latest davinci kernel, but for example if you refer to the latest source code (kernel 4.4.32 from Proc SDK 03.02.00.05), you should modify
    arch/arm/arch-davinci/Kconfig, under ARCH_DAVINCI_DA850 try adding:
    config ARCH_DAVINCI_DA850
    bool "DA850/OMAP-L138/AM18x based system"
    depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
    select ARCH_DAVINCI_DA8XX
    + select COMMON_CLK
    select CP_INTC

    config ARCH_DAVINCI_DA8XX
    bool
    select CPU_ARM926T

    This should enable it.

    Just FYI, TI is in the process of releasing a new Processors SDK Linux (I think using kernel 4.9.x) with added support for OMAP-L138, which means that we will have OMAP-L138 dts in the sources.

    Best Regards,
    Yordan
  • Yordan

    Thanks for the response. Yes, I am aware of the upcoming SDK - I am attempting to get most of the issues with our modifications ironed out before that release so we're ready to go when it's released. Could I possibly get some clarification on the relationship between the Davinci git web page and the SDK (pertaining to the kernel that is, not U-Boot)? I see that da850 changes have been being pushed into the git web page by looking at the log. Is the released SDK just a snapshot of that repository that has been "officially tested" or something, or is there actually a difference in the codebase somewhere (and if so, where at)?

    Basically, say we upgrade our platform to this upcoming SDK, but then after awhile Linux releases a feature that we determine we'd really like to have, is this davinci repository "up to date" with all of the da850 changes? I realize that some of them may not be tested yet, but it would be useful to know so that way we can incrementally upgrade our kernel, rather then having huge jumps for when the SDK releases are years apart.

    Regarding the original question, I think that I found the Linux style fix to this problem. If you look in da8xx-dt.c in the call to

    of_platform_default_populate

    there is a table of auxdata passed in. This table basically renames the device node names to more traditional names. I believe this is necessary because the da850 platform hasn't been upgraded (at least in the git repo) to use the - still under development - Linux device tree clock binding.

    Anyway, here's what the table looks like for anyone else reading the post:

    static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
            OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
            OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
            OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "davinci-wdt", NULL),
            OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
            OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm.0", NULL),
            OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm.1", NULL),
            OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap.0", NULL),
            OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap.1", NULL),
            OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap.2", NULL),
            OF_DEV_AUXDATA("ti,da830-spi", 0x01c41000, "spi_davinci.0", NULL),
            OF_DEV_AUXDATA("ti,da830-spi", 0x01f0e000, "spi_davinci.1", NULL),
            OF_DEV_AUXDATA("ns16550a", 0x01c42000, "serial8250.0", NULL),
            OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
            OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
            OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
            OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
                           NULL),
            OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
            OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", &aemif_data),
            OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
            OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
            OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
            OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
            OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
            OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
            {}
    };
    

    For now I'll probably stick to this rather then trying to muck around with the Kconfig, as this is an acceptable Linux provided workaround.

  • Hi,

    I see that da850 changes have been being pushed into the git web page by looking at the log. Is the released SDK just a snapshot of that repository that has been "officially tested" or something, or is there actually a difference in the codebase somewhere (and if so, where at)?


    The processor sdk repository is different from the davinci git. When available, you should refer to the sources provided in the product folder. In the software manifest you will be able to find the git repository, where the kernel sources are taken from.

    Best Regards,
    Yordan