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