[U-Boot] Potential issue with recent OMAP PRCM struct unification

[Sricharan R]

On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote:
> On Apr 2, 2013, at 5:32 AM, Sricharan R <r.sricharan at ti.com> wrote:
> 
>>> On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake.
>>
>> First, on which board are you testing ?. I tested the mainline on my 4460 ES1.1 PANDA and it booted.
> 
> One custom board still under development and also on the same Pandaboard you have.
> 
> But further testing showed that CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (and the related EMIF defines) stopped working somewhere between commits a268170 and 417c558. Returning to the pre-canned SDRAM modes allowed booting to work again.
> 
> The reason I suspected the clocks was that they were the *only* difference in the entire debug log between the working and hanging cases. I don't know why the SDRAM state difference which was the real cause did not produce even a single difference in the log.
>
  Yes, i think AUTOMATIC_SDRAM_DETECTION is broken. I am having some patches to fix and will post shortly.
  Sorry,that you hit this issue.
  But these were any not because of the PRCM changes, it was much before that. 
>> As you said the unnecessary entry in omap_common.h should be removed and typo in prcm-regs.c
>> I can correct this, but does correcting this gets you working again ?
>> Enabling these two clocks should have nothing to do with boot.
> 
> Correct. As I later found, the clocks in question are non-essential for u-boot and were not causing the hang.
> 
>> Also why are you enabling the non-essential clocks ?
> 
> Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift.
> 
>> Now enabling non-essential clocks is deprecated and they are **not** by enabled by default.
> 
> As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)?
> 
> There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window.
> 
> But clearly until such removal happens dropping any that were previously handled is a regression.
> 
> Thanks for the assistance!
> 
  Yes, thats why we still have kept it for testing.
  But now, there are already patches to fix this in the kernel being posted, and probably
  all of them should be fixed shortly. Once that is done, all of this can be removed.

Regards,
 Sricharan