[U-Boot] [PATCH] ARMv7: OMAP: Add init function for TWL4030 GBPR1 register

[Tom Rini]

On Sun, Mar 4, 2012 at 12:45 AM, Igor Grinberg <grinberg at compulab.co.il> wrote:
> On 03/01/12 19:47, Jonathan Solnit wrote:
>> Hi Igor.
>>
>> On Thu, Mar 1, 2012 at 12:41 AM, Igor Grinberg <grinberg at compulab.co.il <mailto:grinberg at compulab.co.il>> wrote:
>>
>>     Hi Jonathan,
>>
>>     On 02/29/12 22:52, Jonathan Solnit wrote:
>>     > The OMAP ROM code modifies the GBPR1 register, which can cause
>>
>>     s/GBPR1/GPBR1/
>>
>>     > unintended consequences.
>>
>>     What do you mean by this?
>>     Can you please elaborate, what issues do you see?
>>     Also, why does the OMAP ROM code needs to touch the GPBR1?
>>
>>
>> For my board, when booting the OMAP3 from MMC1, GPBR1 comes up as 0x00 instead of 0x90.  The improper clock configuration causes timeouts whenever I try to use the MADC.  In Linux, the error looks like this:
>>
>> user.err kernel: twl4030_madc twl4030_madc: conversion timeout!
>
> Right, but isn't this has been already fixed in kernel:
> 3d6271f (mfd: Turn on the twl4030-madc MADC clock)
>
> $ git describe 3d6271f
> v3.1-13-g3d6271f

OK, good (also good given Jonathan's follow-up).  In this case, I'm
going to go with just having this changed in the kernel unless someone
steps up with a case where this is a problem for U-Boot itself.

>> As for why ROM touches GPBR1, only TI can answer that.  What I've found is that this is a known issue and re-initializing the register at start-up is the recommended solution:
>>
>> http://e2e.ti.com/support/power_management/pmu/f/43/t/762.aspx
>
> We would really appreciate if someone from TI (Tom?) can confirm that this is a bug in ROM code.

My suspicion is that the "re-init in SW" note is the final answer to
the problem, from the ROM PoV.

-- 
Tom