[U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

[Paulraj, Sandeep]

OK.

Will do

> -----Original Message-----
> From: Tom [mailto:Tom.Rix at windriver.com]
> Sent: Thursday, September 10, 2009 3:02 PM
> To: Paulraj, Sandeep
> Cc: Dirk Behme; u-boot at lists.denx.de; Minkyu Kang
> Subject: Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other
> soc
> 
> 
> Sandeep,
> Can you push this change to uboot-ti ?
> Tom
> 
> >> 1) From the previous discussion I think we should apply
> >>
> >> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
> >>
> 
> 
> Tom wrote:
> > Dirk Behme wrote:
> >> Tom wrote:
> >>> Minkyu Kang wrote:
> >>>> Dear Dirk,
> >>>>
> >>>>
> >>> <snip>
> >>>
> >>> I have lost track of this thread.
> >> Yes, and I'm currently trying to get the track back ;)
> >>
> >>> When last I worked this, it seemed like the cache routines were going
> to
> >>> be split.
> >>>
> >>> 1. generic cache routines
> >>> 2. legacy soc cache routines.
> >>>
> >>> Are the generic cache routines in place and can you use them?
> >>> Else can you handle your soc specific cache routines as part of a
> >>> legacy cache routine ?
> >>>
> >>> The omap cache routines are dependent on omap rom code and fitting
> >>> new routines in using the omap specifics may not be the best way to
> >>> go.
> >> I'm sure this is not the perfect way, but it seems to me that splitting
> >> all this stuff into several small steps would be the easier for all.
> E.g.
> >>
> >> 1) From the previous discussion I think we should apply
> >>
> >> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
> >>
> >> Independent of any discussion if this code is needed at all, if it is
> >> generic or not etc. the main advantage I understood is that it frees
> the
> >> way for Samsung.
> >>
> >> 2a) Then, what I understood from Minkyu, we need an additional patch
> >> (discussion?) how to switch CONFIG_L2_OFF from compile time to run time
> >> selection (for Samsung's multi board support)
> >>
> >> 2b) Then, what I understood from Minkyu, we should discuss about
> removal
> >> of get_device_type() function
> >>
> >> 3) In parallel, we should discuss how to further improve the OMAP3
> cache
> >> stuff. What might be generic, what not, what isn't necessary etc.
> >>
> >> 4) Regarding (cache) code duplication, I vote for doing this
> duplication
> >> first. That is, have working Samsung and OMAP3 code applied in
> parallel.
> >> While Jean-Christophe might cry "code duplication", I learned from
> OMAP3
> >> boards that is was easier to unify common code _after_ code duplication
> >> was done and therefore can be easily identified. Discussing about
> >> possible code duplication without being able to see (and test) the code
> >> is sometimes a little tricky ;)
> >>
> >> As mentioned, doing this in several, small steps I feel more
> comfortable
> >> with. If we would have done step (1) already, it's my feeling that we
> >> would have reached step 2 or 3 already. But now, we are still
> discussing
> >> about the 'one big perfect patch'.
> >>
> >> Best regards
> >>
> >> Dirk
> >>
> >>
> >
> > I am making this workflow up as I go.. but it seems like the
> > way to resolve this is to work through the new sub-arm repo's
> >
> > #1 should go to u-boot-ti first and then I will will merge it to u-boot-
> arm
> > Then u-boot-samsung can sync to it and we will all be at a good
> > starting point for #2.
> > Can #1 go now to u-boot-ti ?
> > If there is a merge problem, kick it back to the developer ;)
> >
> > This patch moves the cache support out of A8 and into omap3 which is
> > the correct place for it.
> >
> > I assume the samsung changes are going to go first to u-boot-samsung
> > Correct ?
> >
> > For 2a) runtime cache enabling / disabling
> > New feature I don't think omap needs so it should be at some board or
> > soc level that does not impact omap.
> >
> > For 2b) get_device_type.  This is an omap-ism that goes away with #1
> >
> > The means though that samsung needs its own cache routines.
> > If they are going to do 2a) they will need them anyway.
> >
> > For 3) I don't think omap needs improving at this point.
> >
> > For 4) Lets see how much the samsung cache routines look like the
> > omap once they are done.  If it is a lot of cut-n-paste this is
> > not worth arguing about a common routine will be easier to manage.
> > If the cache code looks really different then it can live at the
> > board or soc layer.  As long as no one claims the cpu layer at the
> > very least everyone's board will work.
> >
> >
> > Tom
> >
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>