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 2/5] of: get dma area lower limit
Date: Tue, 18 Jun 2024 22:38:29 +0100 [thread overview]
Message-ID: <ZnH-VU2iz9Q2KLbr@arm.com> (raw)
In-Reply-To: <230ea13ef8e9f576df849e1b03406184ca890ba8.1712642324.git.baruch@tkos.co.il>
On Tue, Apr 09, 2024 at 09:17:55AM +0300, Baruch Siach wrote:
> of_dma_get_max_cpu_address() returns the highest CPU address that
> devices can use for DMA. The implicit assumption is that all CPU
> addresses below that limit are suitable for DMA. However the
> 'dma-ranges' property this code uses also encodes a lower limit for DMA
> that is potentially non zero.
>
> Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
> limit for the same 'dma-ranges' property describing the high limit.
I don't understand the reason for the lower limit. The way the Linux
zones work is that ZONE_DMA always starts from the start of the RAM. It
doesn't matter whether it's 0 or not, you'd not allocate below the start
of RAM anyway. If you have a device that cannot use the bottom of the
RAM, it is pretty broken and not supported by Linux.
I think you added this limit before we tried to move away from
zone_dma_bits to a non-power-of-two limit (zone_dma_limit). With the
latter, we no longer need tricks with the lower limit,
of_dma_get_max_cpu_address() should capture the smallest upper CPU
address limit supported by all devices (and that's where ZONE_DMA should
end).
--
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 2/5] of: get dma area lower limit
Date: Tue, 18 Jun 2024 22:38:29 +0100 [thread overview]
Message-ID: <ZnH-VU2iz9Q2KLbr@arm.com> (raw)
In-Reply-To: <230ea13ef8e9f576df849e1b03406184ca890ba8.1712642324.git.baruch@tkos.co.il>
On Tue, Apr 09, 2024 at 09:17:55AM +0300, Baruch Siach wrote:
> of_dma_get_max_cpu_address() returns the highest CPU address that
> devices can use for DMA. The implicit assumption is that all CPU
> addresses below that limit are suitable for DMA. However the
> 'dma-ranges' property this code uses also encodes a lower limit for DMA
> that is potentially non zero.
>
> Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
> limit for the same 'dma-ranges' property describing the high limit.
I don't understand the reason for the lower limit. The way the Linux
zones work is that ZONE_DMA always starts from the start of the RAM. It
doesn't matter whether it's 0 or not, you'd not allocate below the start
of RAM anyway. If you have a device that cannot use the bottom of the
RAM, it is pretty broken and not supported by Linux.
I think you added this limit before we tried to move away from
zone_dma_bits to a non-power-of-two limit (zone_dma_limit). With the
latter, we no longer need tricks with the lower limit,
of_dma_get_max_cpu_address() should capture the smallest upper CPU
address limit supported by all devices (and that's where ZONE_DMA should
end).
--
Catalin
next prev parent reply other threads:[~2024-06-18 21:38 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 [this message]
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
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-VU2iz9Q2KLbr@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.