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

[Tom <Tom.Rix@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