[U-Boot] [PATCH 09/14] tegra: Add warmboot implementation

From: Yen Lin <yelin@nvidia.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 09/14] tegra: Add warmboot implementation
Date: Fri, 13 Jan 2012 14:04:38 -0800	[thread overview]
Message-ID: <1326492278.16046.98.camel@yelin-desktop> (raw)
In-Reply-To: <CAPnjgZ1KArHqY7Wf5vybY01XdV--Ap6BV9A+e403=F54yD7YHA@mail.gmail.com>

Hi Simon,

On Fri, 2012-01-13 at 11:34 -0800, Simon Glass wrote:
> Hi Stephen,
> 
> [Yen please can you read this also?]
> 
> On Tue, Jan 10, 2012 at 10:30 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > On 12/26/2011 12:33 PM, Simon Glass wrote:
> >> From: Yen Lin <yelin@nvidia.com>
> >>
> >> Add code to set up the warm boot area in the Tegra CPU ready for a
> >> resume after suspend.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > How come Yen's S-o-b line is missing here?
> >
> > As a general comment on this patch, it contains a lot of structure
> > definitions and defines that should really be part of the clock module's
> > headers and similar; why not just included the clock headers and place
> > all the definitions in those headers if they aren't already there?
> 
> Yes this bit of it got a pretty light review at the time and I was
> reluctant to press on the bitfields when that side of things was still
> up in the air. No functions exist to access these things and using the
> clk_rst.h header adds a mountain of ugly reg & OSC_FREQ_MASK) >>
> OSC_FREQ_SHIFT to the code. I am still uncomfortable with how this
> sort of thing is done in U-Boot.
> 
> Also the AVP code cannot call functions in clock.c (they are in SDRAM
> which isn't on yet), so we need the structures or some sort of access
> there anyway.
> 
> I will tidy up some low-hanging fruit in warmboot.c but don't know
> that I can do much with warmboot_avp.c. At least it isn't assembler
> anymore!
> 
> But there a few questions here. Firstly it seems that it saves some
> memory speed info to scratch2 but never restores it. Then it restores
> CPU speed from scratch3 but I can't see where it saves it. Does Yen
> have any comments on that? Apparently it works because we have been
> using it, but... If it is saving things that are never restored I
> could dump that and reduce the code size.
> 

U-boot code saves sdram parameters to scratch2, scratch4, and scratch 24
registers, so when system resumes, bootrom can restore sdram parameters
from these registers.

The scratch3 register content was saved by kernel before suspend, and is
used by the warmboot code to restore PLLX settings.

Regards,

Yen

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------