Re: [PATCH 0/5] SRAM patcher: patch register addresses in SRAM code atruntime

[Tony Lindgren <tony@atomide.com>]

* Woodruff, Richard <r-woodruff2@ti.com> [071116 11:48]:
> Hi Paul,
> 
> > On Wed, 14 Nov 2007, Woodruff, Richard wrote:
> > 
> > > -*- This code as written today likely won't be used on OMAP3 anyway as
> > > the DVFS procedure will be different.  The SRAM code usage can be much
> > > smaller and should also be different.
> > > The aim of making it single kernel for OMAP2 to OMAP3 in this case is
> > > just using the SRAM function for pushing the correct SRAM routine.
> > 
> > Yeah, agreed.  The main motivation was to share 2420/2430 code here.  I'm
> > hoping that there may be some 3430 sharing that can be done also, perhaps
> > some of the SDRAM timing change code, but there's probably other code that
> > won't be sharable without contortions.
> 
> Yes it would work here.  However, like I was hinting there is another method which 2430's which have been characterized, could try.  But that is something else.
> 
> > > - Well that does look fine.  It kind of feels like a gratuitous cache
> > > range flush should be added.  But as its all data side patches it
> > > probably can live with out it.  The initial code copy should probably
> > > have this.  Caches are VIPT, which means you almost don't have to flush,
> > > but you still do, but it can be in a more optimal way at run time.
> > 
> > Want to do a patch for omap_sram_push()?  I suppose we're getting away
> > without it now because nothing is running from SRAM before
> > omap_sram_push(), and therefore isn't in I$?  sounds like it should be
> > there, though.
> 
> It probably needs to be there.  The reason for getting away is this is init time stuff not so dynamic, and VIPT means there is only a chance of a conflict.  On say an OMAP1 with a VIVT cache it would be a bigger possible problem.
> 
> I think in our older images it was non-cached also.  In current GIT its MT_MEMORY so it will be.
> 
> Its kind of low in things to do today but I might file it away to do.  Right now sram only has a push and no pop so its not so dynamic either.

Yeah and we may want to start using SRAM dynamically too at some
point. Pushing Paul's patches today.

Tony