Dear Tom, 2009/9/9 Tom <tom....@windriver.com>: > Minkyu Kang wrote: >> 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 >>> >> >> Although I did not understand all of the cache routine.. >> the s5pc100 soc doesn't need v7_flush_dcache_all function >> and other cache routines. >> But the s5pc110 soc needs this function, >> and it works fine without modification. (please see my patch) >> > > Please send me a link to your patch. > > Tom > > >> I think.. v7_flush_decache_all function can share together. >> >> If this function is not moved to soc layer, >> need to remove omap specific codes (checking device type) >> > >> Thanks. >> Minkyu Kang > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
http://lists.denx.de/pipermail/u-boot/2009-September/059889.html top of this thread thanks. -- from. prom. www.promsoft.net _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
