Part Number:OMAP-L138
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:
- Compile and load kernel
- U-Boot starts kernel and passes in device tree blob
- 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:
- of_platform_serial_probe
- of_platform_serial_setup
- devm_clk_get
- clk_get
- devm_clk_get
- of_platform_serial_setup
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.