All of lore.kernel.org
 help / color / mirror / Atom feed
From: york sun <york.sun@nxp.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function
Date: Wed, 26 Oct 2016 20:29:23 +0000	[thread overview]
Message-ID: <DB5PR0401MB1733CFED5AB9708D328EFA019AAB0@DB5PR0401MB1733.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 6661c17c-84fa-9d1a-c172-a8b868ea7994@wwwdotorg.org

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?

York

  reply	other threads:[~2016-10-26 20:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-14 20:17 [U-Boot] [Resend RFC PATCH 0/2] Fix armv8 cache flushing York Sun
2016-10-14 20:17 ` [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function York Sun
2016-10-14 20:23   ` Stephen Warren
2016-10-17 21:22   ` Stephen Warren
2016-10-19 15:25   ` Stephen Warren
2016-10-19 17:18     ` Stephen Warren
2016-10-19 22:32       ` york sun
2016-10-19 23:01         ` Stephen Warren
2016-10-20  5:06           ` york sun
2016-10-20 18:34             ` Stephen Warren
2016-10-21 19:31               ` york sun
2016-10-24 10:59                 ` Mark Rutland
2016-10-26 19:47                   ` Stephen Warren
2016-10-26 19:54                     ` york sun
2016-10-26 20:12                       ` Stephen Warren
2016-10-26 20:29                         ` york sun [this message]
2016-10-26 21:00                           ` Stephen Warren
2016-10-26 21:04                             ` york sun
     [not found]                     ` <d51c8f86-19c7-48d8-9335-097e8f574b76@nxp.com>
2016-10-26 21:02                       ` york sun
     [not found]                       ` <060025e2-128b-8c11-1804-fab1aa686f85@nxp.com>
2016-10-28 17:38                         ` york sun
2016-10-28 17:56                           ` Stephen Warren
2016-10-28 18:17                             ` york sun
2016-10-28 18:32                               ` Stephen Warren
2016-10-28 21:35                                 ` york sun
2016-11-07 14:11                                   ` Mark Rutland
2016-11-07 16:23                                     ` york sun
2016-11-07 14:03                                 ` Mark Rutland
2016-10-24 10:44     ` Mark Rutland
2016-10-26 19:41       ` Stephen Warren
2016-10-14 20:17 ` [U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function York Sun
2016-10-14 20:29   ` Stephen Warren
2016-10-14 20:38     ` york sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB5PR0401MB1733CFED5AB9708D328EFA019AAB0@DB5PR0401MB1733.eurprd04.prod.outlook.com \
    --to=york.sun@nxp.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.