Greetings,
I think http://patchwork.ozlabs.org/patch/218063/ or something related to it has confused OMAP4 clock init. I haven't entirely unraveled the onion but wanted to ping the list to see if this is known or I'm off in the weeds.
Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part):
Enable clock module - 4a008e20 Enable clock module - 4a008e28 Enable clock module - 4a008e40 << later builds omit Enable clock module - 4a009338 << these two clocks Enable clock module - 4a004528 Enable clock module - 4a004530 Enable clock module - 4a004538
That build works. But by commit 417c558 the 2 clocks noted are omitted and the later call to get_ram_size() hangs.
In tracing this I found that the prcm structure initializes one field (cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) to do_enable_clocks(). That latter uninitialized field is zero which terminates that clock init array and results in the two clock omissions above.
Searching for this and leaving out omap5 for clarity I see:
cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5 ./arch/arm/cpu/armv7/omap4/prcm-regs.c: .cm_l3instr_intrconn_wp1_clkct = 0x4a008e40, ./arch/arm/cpu/armv7/omap4/hw_data.c: (*prcm)->cm_l3instr_intrconn_wp1_clkctrl, ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkctrl; ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkct;
On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake.
If that's true can anyone say which should be eliminated and whether or not the order of fields in struct prcm_regs matters?
Thanks, -Mike Cashwell