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) 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
