[U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[york sun]

On 10/26/2016 02:00 PM, Stephen Warren wrote:
> On 10/26/2016 02:29 PM, york sun wrote:
>> On 10/26/2016 01:12 PM, Stephen Warren wrote:
>>> On 10/26/2016 01:54 PM, york sun wrote:
>>>> On 10/26/2016 12:47 PM, Stephen Warren wrote:
>>>>>
>>>>> There are two data structures in ARM U-Boot that describe memory layout:
>>>>>
>>>>> 1) A list of RAM memory regions. U-Boot uses these to know where to
>>>>> relocate itself to (it relocates itself to the top of RAM at boot), and
>>>>> to fill in the /memory node when booting an OS using DT (and other
>>>>> equivalent mechanisms when not using DT.)
>>>>>
>>>>> 2) For AArch64 specifically, there's a memory map table that defines all
>>>>> RAM and MMIO regions, and the translation table attributes required for
>>>>> those regions.
>>>>>
>>>>> Judging by your comments later in the original message, it sounds like
>>>>> it'd be fine to read from these structures during any dcache clean
>>>>> routine provided the table has already been cleaned. That makes using
>>>>> the tables much more tractable:-)
>>>>>
>>>>
>>>> I think we need to benchmark walking through the MMU tables. It can map
>>>> huge amount of memory. For our case, it is more than 16GB. I have been
>>>> reluctant to do so for the size. I am now back testing to revert _this_
>>>> patch, hoping to confirm what I learned from this discussion. After
>>>> that, I will see how long it takes to flush all cached addresses by VA.
>>>
>>> Given the existence of the two data structures I mentioned above, I
>>> don't think we'd ever need to walk the MMU translation tables (assuming
>>> you mean the data structures U-Boot creates and configures into the
>>> CPU's MMU), rather than just walking over the tiny number of entries in
>>> those data structures?
>>>
>>
>> The list of RAM used by U-Boot is different from the total memory.
>> U-Boot relocates itself to the gd->ram_top. We may have memory in second
>> region, or even the third region.
>>
>> We also have other cached region other than RAM. I know for Layerscape
>> SoCs, there is QMan portal has 64MB cached. If we consider to flush
>> _all_ address, they should be included.
>>
>> I think the 2nd data structure you mentioned is the MMU table for
>> aarch64, isn't it?
>
> The 2nd data structure I mentioned is what U-Boot uses to create the
> translation tables, but isn't the translation table itself.
>

I see. You were referring the struct mm_region. It does simplify walking 
the address. You presumption is we don't update the MMU table after 
creating it. It is mostly true, but current MMU code allows updating.

York