From: Arnd Bergmann <arnd@arndb.de>
To: "Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>
Cc: Phil Edworthy <phil.edworthy@renesas.com>,
Will Deacon <will.deacon@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Magnus <magnus.damm@gmail.com>
Subject: Re: PCIe host controller behind IOMMU on ARM
Date: Wed, 11 Nov 2015 21:22:35 +0100 [thread overview]
Message-ID: <4372968.dQOnUSIksK@wuerfel> (raw)
In-Reply-To: <20151111182456.GV963@e106497-lin.cambridge.arm.com>
On Wednesday 11 November 2015 18:24:56 Liviu.Dudau@arm.com wrote:
>
> > Somewhat related to this, since our PCIe controller HW is limited to
> > 32-bit AXI address range, before trying to hook up the IOMMU I have
> > tried to limit the dma_mask for PCI cards to DMA_BIT_MASK(32). The
> > reason being that Linux uses a 1 to 1 mapping between PCI addresses
> > and cpu (phys) addresses when there isn't an IOMMU involved, so I
> > think that we need to limit the PCI address space used.
>
> I think you're mixing things a bit or not explaining them very well. Having the
> PCIe controller limited to 32-bit AXI does not mean that the PCIe bus cannot
> carry 64-bit addresses. It depends on how they get translated by the host bridge
> or its associated ATS block. I can't see why you can't have a setup where
> the CPU addresses are 32-bit but the PCIe bus addresses are all 64-bit.
> You just have to be careful on how you setup your mem64 ranges so that they don't
> overlap with the 32-bit ranges when translated.
>
> And no, you should not limit at the card driver the DMA_BIT_MASK() unless the
> card is not capable of supporting more than 32-bit addresses.
I think we are missing one crucial bit of infrastructure on ARM64 at
the moment: the dma_set_mask() function should fail if a driver asks
for a mask that is larger than the dma-ranges property of the parent
device (or any device higher up in the hierarchy) allows.
Drivers that want a larger mask should try that first, and then fall
back to a 32-bit mask, which is guaranteed to work.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: PCIe host controller behind IOMMU on ARM
Date: Wed, 11 Nov 2015 21:22:35 +0100 [thread overview]
Message-ID: <4372968.dQOnUSIksK@wuerfel> (raw)
In-Reply-To: <20151111182456.GV963@e106497-lin.cambridge.arm.com>
On Wednesday 11 November 2015 18:24:56 Liviu.Dudau at arm.com wrote:
>
> > Somewhat related to this, since our PCIe controller HW is limited to
> > 32-bit AXI address range, before trying to hook up the IOMMU I have
> > tried to limit the dma_mask for PCI cards to DMA_BIT_MASK(32). The
> > reason being that Linux uses a 1 to 1 mapping between PCI addresses
> > and cpu (phys) addresses when there isn't an IOMMU involved, so I
> > think that we need to limit the PCI address space used.
>
> I think you're mixing things a bit or not explaining them very well. Having the
> PCIe controller limited to 32-bit AXI does not mean that the PCIe bus cannot
> carry 64-bit addresses. It depends on how they get translated by the host bridge
> or its associated ATS block. I can't see why you can't have a setup where
> the CPU addresses are 32-bit but the PCIe bus addresses are all 64-bit.
> You just have to be careful on how you setup your mem64 ranges so that they don't
> overlap with the 32-bit ranges when translated.
>
> And no, you should not limit at the card driver the DMA_BIT_MASK() unless the
> card is not capable of supporting more than 32-bit addresses.
I think we are missing one crucial bit of infrastructure on ARM64 at
the moment: the dma_set_mask() function should fail if a driver asks
for a mask that is larger than the dma-ranges property of the parent
device (or any device higher up in the hierarchy) allows.
Drivers that want a larger mask should try that first, and then fall
back to a 32-bit mask, which is guaranteed to work.
Arnd
next prev parent reply other threads:[~2015-11-11 20:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-04 13:57 PCIe host controller behind IOMMU on ARM Phil Edworthy
2015-11-04 13:57 ` Phil Edworthy
2015-11-04 14:24 ` Liviu.Dudau
2015-11-04 14:24 ` Liviu.Dudau at arm.com
2015-11-04 14:48 ` Phil Edworthy
2015-11-04 14:48 ` Phil Edworthy
2015-11-04 14:48 ` Phil Edworthy
2015-11-04 15:01 ` Liviu.Dudau
2015-11-04 15:01 ` Liviu.Dudau at arm.com
2015-11-04 15:19 ` Phil Edworthy
2015-11-04 15:19 ` Phil Edworthy
2015-11-04 15:19 ` Phil Edworthy
2015-11-04 15:30 ` Will Deacon
2015-11-04 15:30 ` Will Deacon
2015-11-04 18:02 ` Phil Edworthy
2015-11-04 18:02 ` Phil Edworthy
2015-11-04 18:02 ` Phil Edworthy
2015-11-09 12:32 ` Phil Edworthy
2015-11-09 12:32 ` Phil Edworthy
2015-11-09 12:32 ` Phil Edworthy
2015-11-11 18:24 ` Liviu.Dudau
2015-11-11 18:24 ` Liviu.Dudau at arm.com
2015-11-11 20:22 ` Arnd Bergmann [this message]
2015-11-11 20:22 ` Arnd Bergmann
2015-11-12 9:26 ` Phil Edworthy
2015-11-12 9:26 ` Phil Edworthy
2015-11-12 9:26 ` Phil Edworthy
2015-11-12 9:49 ` Arnd Bergmann
2015-11-12 9:49 ` Arnd Bergmann
2015-11-12 15:33 ` Phil Edworthy
2015-11-12 15:33 ` Phil Edworthy
2015-11-12 16:16 ` Arnd Bergmann
2015-11-12 16:16 ` Arnd Bergmann
2015-11-13 13:03 ` Phil Edworthy
2015-11-13 13:03 ` Phil Edworthy
2015-11-13 13:59 ` Arnd Bergmann
2015-11-13 13:59 ` Arnd Bergmann
2015-11-13 14:11 ` Phil Edworthy
2015-11-13 14:11 ` Phil Edworthy
2015-11-12 10:32 ` Liviu.Dudau
2015-11-12 10:32 ` Liviu.Dudau at arm.com
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=4372968.dQOnUSIksK@wuerfel \
--to=arnd@arndb.de \
--cc=Liviu.Dudau@arm.com \
--cc=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=magnus.damm@gmail.com \
--cc=phil.edworthy@renesas.com \
--cc=will.deacon@arm.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 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.