From: Catalin Marinas <catalin.marinas@arm.com>
To: Baruch Siach <baruch@tkos.co.il>
Cc: "Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Rob Herring" <robh@kernel.org>,
"Saravana Kannan" <saravanak@google.com>,
"Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>,
iommu@lists.linux.dev, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, "Petr Tesařík" <petr@tesarici.cz>,
"Ramon Fried" <ramon@neureality.ai>,
"Elad Nachman" <enachman@marvell.com>
Subject: Re: [PATCH RFC v2 4/5] dma-direct: add base offset to zone_dma_bits
Date: Tue, 18 Jun 2024 22:40:39 +0100 [thread overview]
Message-ID: <ZnH-18_lQsdYaxgj@arm.com> (raw)
In-Reply-To: <1d7b0d59590aae631b6f0b894257ab961b907b44.1712642324.git.baruch@tkos.co.il>
On Tue, Apr 09, 2024 at 09:17:57AM +0300, Baruch Siach wrote:
> Current code using zone_dma_bits assume that all addresses range in the
> bits mask are suitable for DMA. For some existing platforms this
> assumption is not correct. DMA range might have non zero lower limit.
[...]
> @@ -59,7 +60,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
> * zones.
> */
> *phys_limit = dma_to_phys(dev, dma_limit);
> - if (*phys_limit <= zone_dma_limit)
> + if (*phys_limit <= zone_dma_base + zone_dma_limit)
> return GFP_DMA;
> if (*phys_limit <= DMA_BIT_MASK(32))
> return GFP_DMA32;
As I said previously, we no longer have zone_dma_bits after the first
patch, so adding this limit no longer make sense. In v1, you wanted a
limit like 32G to be added to the 30-bit zone_dma_bits to give you 33G
upper limit for ZONE_DMA. But since the first patch sets zone_dma_limit
to 33G already, this is no longer needed.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Baruch Siach <baruch@tkos.co.il>
Cc: "Rob Herring" <robh@kernel.org>,
linux-s390@vger.kernel.org, "Ramon Fried" <ramon@neureality.ai>,
"Saravana Kannan" <saravanak@google.com>,
devicetree@vger.kernel.org, "Petr Tesařík" <petr@tesarici.cz>,
"Will Deacon" <will@kernel.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, "Elad Nachman" <enachman@marvell.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Christoph Hellwig" <hch@lst.de>,
linux-arm-kernel@lists.infradead.org,
"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [PATCH RFC v2 4/5] dma-direct: add base offset to zone_dma_bits
Date: Tue, 18 Jun 2024 22:40:39 +0100 [thread overview]
Message-ID: <ZnH-18_lQsdYaxgj@arm.com> (raw)
In-Reply-To: <1d7b0d59590aae631b6f0b894257ab961b907b44.1712642324.git.baruch@tkos.co.il>
On Tue, Apr 09, 2024 at 09:17:57AM +0300, Baruch Siach wrote:
> Current code using zone_dma_bits assume that all addresses range in the
> bits mask are suitable for DMA. For some existing platforms this
> assumption is not correct. DMA range might have non zero lower limit.
[...]
> @@ -59,7 +60,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
> * zones.
> */
> *phys_limit = dma_to_phys(dev, dma_limit);
> - if (*phys_limit <= zone_dma_limit)
> + if (*phys_limit <= zone_dma_base + zone_dma_limit)
> return GFP_DMA;
> if (*phys_limit <= DMA_BIT_MASK(32))
> return GFP_DMA32;
As I said previously, we no longer have zone_dma_bits after the first
patch, so adding this limit no longer make sense. In v1, you wanted a
limit like 32G to be added to the 30-bit zone_dma_bits to give you 33G
upper limit for ZONE_DMA. But since the first patch sets zone_dma_limit
to 33G already, this is no longer needed.
--
Catalin
next prev parent reply other threads:[~2024-06-18 21:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 6:17 [PATCH RFC v2 0/5] arm64: support DMA zone starting above 4GB Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` [PATCH RFC v2 1/5] dma-mapping: replace zone_dma_bits by zone_dma_limit Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-06-18 18:26 ` Catalin Marinas
2024-06-18 18:26 ` Catalin Marinas
2024-04-09 6:17 ` [PATCH RFC v2 2/5] of: get dma area lower limit Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-06-18 21:38 ` Catalin Marinas
2024-06-18 21:38 ` Catalin Marinas
2024-07-25 11:49 ` Baruch Siach
2024-07-25 11:49 ` Baruch Siach
2024-07-30 15:52 ` Catalin Marinas
2024-07-30 15:52 ` Catalin Marinas
2024-04-09 6:17 ` [PATCH RFC v2 3/5] of: unittest: add test for of_dma_get_cpu_limits() 'min' param Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` [PATCH RFC v2 4/5] dma-direct: add base offset to zone_dma_bits Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-06-18 21:40 ` Catalin Marinas [this message]
2024-06-18 21:40 ` Catalin Marinas
2024-04-09 6:17 ` [PATCH RFC v2 5/5] arm64: mm: take DMA zone offset into account Baruch Siach
2024-04-09 6:17 ` Baruch Siach
2024-04-09 6:17 ` Baruch Siach
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=ZnH-18_lQsdYaxgj@arm.com \
--to=catalin.marinas@arm.com \
--cc=baruch@tkos.co.il \
--cc=devicetree@vger.kernel.org \
--cc=enachman@marvell.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=petr@tesarici.cz \
--cc=ramon@neureality.ai \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
--cc=will@kernel.org \
/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.