From: Catalin Marinas <catalin.marinas@arm.com>
To: Phil Chang <phil.chang@mediatek.com>
Cc: linux-arm-kernel@lists.infradead.org,
YJ Chiang <yj.chiang@mediatek.com>,
Alix Wu <alix.wu@mediatek.com>,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org
Subject: Re: Re: [PATCH] [PATCH] ARM64: Setup DMA32 zone size by bootargs
Date: Fri, 25 Sep 2020 10:11:55 +0100 [thread overview]
Message-ID: <20200925091154.GA4846@gaia> (raw)
In-Reply-To: <20200924141514.23930-1-phil.chang@mediatek.com>
On Thu, Sep 24, 2020 at 10:15:14PM +0800, Phil Chang wrote:
> Actually, In a embedded system with 3GB memory, the memory bus width is not the same among the 3GB.
> (The first 2GB is 48-bit wide, and the latter 1GB is 16-bit wide.)
So I guess that's the data bus width. Devices can still access the whole
memory, though at different throughputs.
Does this narrow data bus apply only to devices or the CPUs are affected
as well?
> For memory throughput reason of hardware IPs, we need allocate memory from the first 2GB for
> the hardware IPs. And that is why we setup the first 2GB as DMA_ZONE, and use GFP_DMA to allocate
> memory from the range.
If it's only a throughput problem, it looks to me more like a NUMA
configuration. I think you can add the first 2GB and the last GB in
separate nodes and define a "numa-node-id" property per device in DT.
--
Catalin
prev parent reply other threads:[~2020-09-25 9:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 15:08 [PATCH] [PATCH] ARM64: Setup DMA32 zone size by bootargs Phil Chang
2020-09-15 16:13 ` Catalin Marinas
2020-09-15 16:18 ` Mike Rapoport
2020-09-15 17:48 ` David Woodhouse
2020-09-16 7:22 ` Phil Chang
2020-09-16 8:37 ` Christoph Hellwig
2020-09-16 13:33 ` Phil Chang
2020-09-16 14:56 ` Catalin Marinas
2020-09-24 14:15 ` Phil Chang
2020-09-25 9:11 ` Catalin Marinas [this message]
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=20200925091154.GA4846@gaia \
--to=catalin.marinas@arm.com \
--cc=alix.wu@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=phil.chang@mediatek.com \
--cc=yj.chiang@mediatek.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).