From: "Arnd Bergmann" <arnd@arndb.de>
To: "Ben Collins" <bcollins@kernel.org>
Cc: dmaengine@vger.kernel.org, "Zhang Wei" <zw@zh-kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fsldma: Support 40 bit DMA addresses where capable
Date: Tue, 22 Apr 2025 09:59:42 +0200 [thread overview]
Message-ID: <ace8c85d-6dec-499f-8a8a-35d4672c181d@app.fastmail.com> (raw)
In-Reply-To: <2025042202-uncovered-mongrel-aee116@boujee-and-buff>
On Tue, Apr 22, 2025, at 09:12, Ben Collins wrote:
> On Tue, Apr 22, 2025 at 08:34:55AM -0500, Arnd Bergmann wrote:
>>
>> - SoCs that don't set a dma-ranges property in the parent bus
>> are normally still capped to 32 bit DMA. I don't see those
>> properties, so unless there is a special hack on those chips,
>> you get 32 bit DMA regardless of what DMA mask the driver
>> requests
>
> I've yet to see a dma-ranges property in any of the Freescale PowerPC
> device trees.
Right, but this could just mean that they end up using SWIOTLB
to bounce the high DMA pages or use an IOMMU rather than actually
translating the physical address to a dma address.
The only special case I see for freescale powerpc chips is the
PCI dma_set_mask() handler that does
static void fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
/*
* Fix up PCI devices that are able to DMA to the large inbound
* mapping that allows addressing any RAM address from across PCI.
*/
if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
dev->bus_dma_limit = 0;
dev->archdata.dma_offset = pci64_dma_offset;
}
}
but that should not apply here because this is not a PCI device.
> I'll check on this, but I think it's a seperate issue. The main thing is
> just to configure the dma hw correctly.
I think it's still important to check this before changing the
driver: if the larger mask doesn't actually have any effect now
because the DT caps the DMA at 4GB, then it might break later
when someone adds the correct dma-ranges properties.
> So a little research shows that these 3 compatible strings in
> the fsldma are:
>
> fsl,elo3-dma: 40-bit
> fsl,eloplus-dma: 36-bit
> fsl,elo-dma: 32-bit
>
> I'll rework it so addressing is based on the compatible string.
Sounds good, yes. Just to clarify: where did you find those
limits? Are you sure those are not just the maximum addressable
amounts of physical RAM on the chips that use the respective
controllers?
Arnd
next prev parent reply other threads:[~2025-04-22 8:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 2:49 [PATCH] fsldma: Support 40 bit DMA addresses where capable Ben Collins
2025-04-22 6:34 ` Arnd Bergmann
2025-04-22 7:12 ` Ben Collins
2025-04-22 7:59 ` Arnd Bergmann [this message]
2025-04-22 8:56 ` Ben Collins
2025-04-22 9:25 ` Arnd Bergmann
2025-04-22 21:10 ` Ben Collins
2025-04-23 13:49 ` Arnd Bergmann
2025-04-23 20:41 ` Ben Collins
2025-04-23 20:56 ` Arnd Bergmann
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=ace8c85d-6dec-499f-8a8a-35d4672c181d@app.fastmail.com \
--to=arnd@arndb.de \
--cc=bcollins@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=vkoul@kernel.org \
--cc=zw@zh-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox