From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jon Hunter <jon-hunter@ti.com>
Date: Thu, 21 Mar 2013 10:25:03 -0500
Subject: [U-Boot] [PATCH] Fix bootdelay timeout calculation when
	SYS_HZ!=1000
In-Reply-To: <20130321144145.GG26945@bill-the-cat>
References: <1363842874-8286-1-git-send-email-swarren@wwwdotorg.org>
	<20130321065553.BC624200547@gemini.denx.de>
	<514B1036.3090400@ti.com>
	<20130321143540.B01CF200547@gemini.denx.de>
	<20130321144145.GG26945@bill-the-cat>
Message-ID: <514B264F.2000306@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de


On 03/21/2013 09:41 AM, Tom Rini wrote:
> On Thu, Mar 21, 2013 at 03:35:40PM +0100, Wolfgang Denk wrote:
>> Dear Tom,
>>
>> In message <514B1036.3090400@ti.com> you wrote:
>>>
>>>> A system with CONFIG_SYS_HZ != 1000 is _broken_.
>>>
>>> So, RPi is going higher, and Jon hit this on I suspect omap2420h4
>>> which is also higher (after mathing that all out).  If we no longer
>>> support CONFIG_SYS_HZ != 1000 we need to make that clear (and explain
>>> why).
>>
>> It has never been supported, so this is not a case of "no longer".
>> There are several longish threads (about the timer code, especially
>> on ARM) in the archives.
> 
> OK, then we need to do something about these platforms today.  I'm
> guessing RPi can just be tuned down to 1000 but for omap2420h4 it's an
> interesting value and I don't know about the platform well enough to say
> what we'd need to do to adapt it.  Jon?

For OMAP2420, we have a choice of using either a 12MHz or 32kHz clock to
drive the timer. With the 32kHz clock we can get close to 1000Hz tick
but we cannot get it dead on. That's why OMAP has been using 128Hz tick
in the kernel as opposed to 100Hz tick in the kernel for years (although
that was changed recently).

Cheers
Jon