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

[Tom]

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