From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg Date: Sun, 04 Mar 2012 09:45:28 +0200 Subject: [U-Boot] [PATCH] ARMv7: OMAP: Add init function for TWL4030 GBPR1 register In-Reply-To: References: <1330548734-18571-1-git-send-email-jsolnit@gmail.com> <4F4F364F.3030808@compulab.co.il> Message-ID: <4F531D98.1050602@compulab.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/01/12 19:47, Jonathan Solnit wrote: > Hi Igor. > > On Thu, Mar 1, 2012 at 12:41 AM, Igor Grinberg > 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 > > 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. Nevertheless, I don't think U-Boot uses MADC feature (am I right?), so IMO, kernel has to be fixed (I think already fixed) to not rely on ROM/U-Boot setup of that MADC clock. -- Regards, Igor.