All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Edworthy <phil.edworthy@renesas.com>
To: Arnd Bergmann <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Magnus <magnus.damm@gmail.com>, Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>
Subject: RE: PCIe host controller behind IOMMU on ARM
Date: Fri, 13 Nov 2015 14:11:47 +0000	[thread overview]
Message-ID: <PS1PR06MB11808E4C2C15BC9FD01E214EF5110@PS1PR06MB1180.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <4744053.Iz6Y8QJQYF@wuerfel>

On 13 November 2015 14:00, Arnd Bergmann wrote:
> On Friday 13 November 2015 13:03:11 Phil Edworthy wrote:
> >
> > > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB
> before
> > > > calling of_pci_dma_configure(). I assume it does this on the basis that this is
> a
> > > > good default for PCI drivers that don't call dma_set_mask().
> > > > So if arch_setup_dma_ops() walks up the parents to limit the mask, you'll
> hit
> > > > this mask.
> > >
> > > arch_setup_dma_ops() does not walk up the hierarchy, of_dma_configure()
> > > does this before calling arch_setup_dma_ops(). The PCI devices start out
> > > with the 32-bit mask, but the limit should be whatever PCI host uses.
> > Ok, so of_dma_configure() could walk up the tree and restrict the dma
> > mask to whatever parents limit it to. Then it could be overridden by
> > a dma-ranges entry in the DT node, right?
> 
> No, the dma-ranges properties tell you what the allowed masks are,
> this is what of_dma_configure() looks at.
Ok, I understand now.


> > If so, one problem I can see is PCI controllers already use the
> > dma-ranges binding but with 3 address cells since it also specifies
> > the PCI address range.
> >
> > I noticed that of_dma_get_range() skips straight to the parent node.
> > Shouldn't it attempt to get the dma-ranges for the device's node
> > first?
> 
> No, the dma-ranges explain the capabilities of the bus, this is
> what you have to look at. The device itself may have additional
> restrictions, but those are what the driver knows based on the
> compatibility value when it passes the device specific mask into
> dma_set_mask()
Ok, this is making sense now.


> > I mean most hardware is limited by the peripheral's
> > capabilities, not the bus. If fact, of_dma_get_range() gets the number
> > of address and size cells from the device node, but gets the dma-ranges
> > from the parent. That seems a little odd to me.
> 
> of_dma_get_range() calls of_n_addr_cells()/of_n_size_cells(), which get
> the #address-cells/#size-cells property from the parent device (except
> for the root, which is special).
Right, I should have checked what of_n_addr/size_cell() actually did.


> > The only other problem I can see is that currently all PCI drivers can
> > try to set their dma mask to 64 bits. At the moment that succeeds
> > because there are no checks.
> 
> Right, this is the main bug we need to fix.
Yep.


> > Until devices using them have their DTs
> > updated with dma-ranges, we would be limiting them to a 32 bit mask. I
> > guess that's not much of an issue in practice.
> 
> Correct. I've tried to tell everyone about this when they added device
> nodes for DMA capable devices. In most cases, they want 32-bit masks
> anyway.

Thanks for your help & patience, much appreciated!
Phil

WARNING: multiple messages have this Message-ID (diff)
From: phil.edworthy@renesas.com (Phil Edworthy)
To: linux-arm-kernel@lists.infradead.org
Subject: PCIe host controller behind IOMMU on ARM
Date: Fri, 13 Nov 2015 14:11:47 +0000	[thread overview]
Message-ID: <PS1PR06MB11808E4C2C15BC9FD01E214EF5110@PS1PR06MB1180.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <4744053.Iz6Y8QJQYF@wuerfel>

On 13 November 2015 14:00, Arnd Bergmann wrote:
> On Friday 13 November 2015 13:03:11 Phil Edworthy wrote:
> >
> > > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB
> before
> > > > calling of_pci_dma_configure(). I assume it does this on the basis that this is
> a
> > > > good default for PCI drivers that don't call dma_set_mask().
> > > > So if arch_setup_dma_ops() walks up the parents to limit the mask, you'll
> hit
> > > > this mask.
> > >
> > > arch_setup_dma_ops() does not walk up the hierarchy, of_dma_configure()
> > > does this before calling arch_setup_dma_ops(). The PCI devices start out
> > > with the 32-bit mask, but the limit should be whatever PCI host uses.
> > Ok, so of_dma_configure() could walk up the tree and restrict the dma
> > mask to whatever parents limit it to. Then it could be overridden by
> > a dma-ranges entry in the DT node, right?
> 
> No, the dma-ranges properties tell you what the allowed masks are,
> this is what of_dma_configure() looks at.
Ok, I understand now.


> > If so, one problem I can see is PCI controllers already use the
> > dma-ranges binding but with 3 address cells since it also specifies
> > the PCI address range.
> >
> > I noticed that of_dma_get_range() skips straight to the parent node.
> > Shouldn't it attempt to get the dma-ranges for the device's node
> > first?
> 
> No, the dma-ranges explain the capabilities of the bus, this is
> what you have to look at. The device itself may have additional
> restrictions, but those are what the driver knows based on the
> compatibility value when it passes the device specific mask into
> dma_set_mask()
Ok, this is making sense now.


> > I mean most hardware is limited by the peripheral's
> > capabilities, not the bus. If fact, of_dma_get_range() gets the number
> > of address and size cells from the device node, but gets the dma-ranges
> > from the parent. That seems a little odd to me.
> 
> of_dma_get_range() calls of_n_addr_cells()/of_n_size_cells(), which get
> the #address-cells/#size-cells property from the parent device (except
> for the root, which is special).
Right, I should have checked what of_n_addr/size_cell() actually did.


> > The only other problem I can see is that currently all PCI drivers can
> > try to set their dma mask to 64 bits. At the moment that succeeds
> > because there are no checks.
> 
> Right, this is the main bug we need to fix.
Yep.


> > Until devices using them have their DTs
> > updated with dma-ranges, we would be limiting them to a 32 bit mask. I
> > guess that's not much of an issue in practice.
> 
> Correct. I've tried to tell everyone about this when they added device
> nodes for DMA capable devices. In most cases, they want 32-bit masks
> anyway.

Thanks for your help & patience, much appreciated!
Phil

  reply	other threads:[~2015-11-13 14:11 UTC|newest]

Thread overview: 52+ 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 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:24   ` Liviu.Dudau
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:01       ` Liviu.Dudau
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 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 18:24           ` Liviu.Dudau
2015-11-11 20:22           ` Arnd Bergmann
2015-11-11 20:22             ` Arnd Bergmann
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 15:33                 ` Phil Edworthy
2015-11-12 16:16                 ` Arnd Bergmann
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:03                     ` Phil Edworthy
2015-11-13 13:59                     ` Arnd Bergmann
2015-11-13 13:59                       ` Arnd Bergmann
2015-11-13 14:11                       ` Phil Edworthy [this message]
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
2015-11-12 10:32               ` Liviu.Dudau

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=PS1PR06MB11808E4C2C15BC9FD01E214EF5110@PS1PR06MB1180.apcprd06.prod.outlook.com \
    --to=phil.edworthy@renesas.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --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=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.