OK. Will do
> -----Original Message----- > From: Tom [mailto:tom....@windriver.com] > Sent: Thursday, September 10, 2009 3:02 PM > To: Paulraj, Sandeep > Cc: Dirk Behme; u-boot@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@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
