Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
Hi Jim, Am 24.09.18 um 17:01 schrieb Jim Quinlan: > On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel > wrote: >> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: >>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli >>> wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 14:31, Florian Fainelli > wrote: >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 13:55, Florian Fainelli >>> wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan > wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so >> in >> this case. are there any plans to release a new version of this series? The Raspberry Pi 4 uses a similiar PCIe controller, so it would be nice to get this upstream. Unfortunately i have no clue about PCI, so i the only thing i can do is testing. Regards Stefan
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/26/2018 03:56 AM, Robin Murphy wrote: > On 26/09/18 03:59, Florian Fainelli wrote: >> >> >> On 9/24/2018 8:01 AM, Jim Quinlan wrote: >>> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel >>> wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > wrote: >> >> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 14:31, Florian Fainelli >>> wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 13:55, Florian Fainelli > wrote: >> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >>> On 19 September 2018 at 07:31, Jim Quinlan >>> wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[ 03fff] <=> pci@[ 03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >>> So is describing this as >>> >>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >>> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >>> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >>> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >>> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >>> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >>> >>> not working for you? I haven't tried this myself, but since >>> DT permits >>> describing the inbound mappings this way, we should fix the >>> code if it >>> doesn't work at the moment. >> >> You mean encoding the memory controller index in the first >> cell? If that >> works, that's indeed a much cleaner solution, though is it >> standard >> compliant in any form? > > No those are just memory addresses (although I may have screwed > up the > order). From Documentation/devicetree/booting-without-of.txt: > > """ > Optional property: > - dma-ranges: encoded as arbitrary number > of triplets of > (child-bus-address, parent-bus-address, length). Each > triplet specified > describes a contiguous DMA address range. > """ > Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. >>> >>> Ah ok, apologies for the noise then. >>> >>> I was hoping that having working support for dma-ranges would remove >>> the need for the special phys<->dma conversion routines. >> >> What you describe definitively works with platform devices, but I >> am not >> sure this is working for PCIe devices, although, conceptually it >> should, >> yes. > Sorry for my delay in responding. One problem is that > of_dma_configure() only looks at the first dma-range given and then > converts it to dev->dma_pfn_offset which is respected by the DMA API. > However, we often have multiple dma-ranges, not just one. This is the > big issue. > Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? >>> >>> It looks like this has been brought up before in the "[RFC PATCH] of: >>> Fix DMA configuration for non-DT masters" thread aka >>> >>> https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html >>> >>> In the
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/26/2018 03:56 AM, Robin Murphy wrote: > On 26/09/18 03:59, Florian Fainelli wrote: >> >> >> On 9/24/2018 8:01 AM, Jim Quinlan wrote: >>> On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel >>> wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > wrote: >> >> On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 14:31, Florian Fainelli >>> wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 13:55, Florian Fainelli > wrote: >> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >>> On 19 September 2018 at 07:31, Jim Quinlan >>> wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[ 03fff] <=> pci@[ 03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >>> So is describing this as >>> >>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >>> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >>> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >>> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >>> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >>> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >>> >>> not working for you? I haven't tried this myself, but since >>> DT permits >>> describing the inbound mappings this way, we should fix the >>> code if it >>> doesn't work at the moment. >> >> You mean encoding the memory controller index in the first >> cell? If that >> works, that's indeed a much cleaner solution, though is it >> standard >> compliant in any form? > > No those are just memory addresses (although I may have screwed > up the > order). From Documentation/devicetree/booting-without-of.txt: > > """ > Optional property: > - dma-ranges: encoded as arbitrary number > of triplets of > (child-bus-address, parent-bus-address, length). Each > triplet specified > describes a contiguous DMA address range. > """ > Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. >>> >>> Ah ok, apologies for the noise then. >>> >>> I was hoping that having working support for dma-ranges would remove >>> the need for the special phys<->dma conversion routines. >> >> What you describe definitively works with platform devices, but I >> am not >> sure this is working for PCIe devices, although, conceptually it >> should, >> yes. > Sorry for my delay in responding. One problem is that > of_dma_configure() only looks at the first dma-range given and then > converts it to dev->dma_pfn_offset which is respected by the DMA API. > However, we often have multiple dma-ranges, not just one. This is the > big issue. > Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? >>> >>> It looks like this has been brought up before in the "[RFC PATCH] of: >>> Fix DMA configuration for non-DT masters" thread aka >>> >>> https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html >>> >>> In the
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 26/09/18 03:59, Florian Fainelli wrote: On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[ 03fff] <=> pci@[ 03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Nope, the code is most definitely incomplete - it's sufficient to support the system it was originally needed for (i.e. platform devices with a single range), but can by no means even pretend to support the binding fully. Furthermore, the way that PCI support was later grafted into of_dma_configure() was *only* in support of dma-coherent without consideration for dma-ranges. Hence the current mess. Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node",
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 26/09/18 03:59, Florian Fainelli wrote: On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[ 03fff] <=> pci@[ 03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Nope, the code is most definitely incomplete - it's sufficient to support the system it was originally needed for (i.e. platform devices with a single range), but can by no means even pretend to support the binding fully. Furthermore, the way that PCI support was later grafted into of_dma_configure() was *only* in support of dma-coherent without consideration for dma-ranges. Hence the current mess. Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node",
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Wed, 26 Sep 2018 at 04:59, Florian Fainelli wrote: > > > > On 9/24/2018 8:01 AM, Jim Quinlan wrote: > > On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel > > wrote: > >> > >> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > >>> > >>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > >>> wrote: > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > On 20 September 2018 at 14:31, Florian Fainelli > > wrote: > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > >>> On 20 September 2018 at 13:55, Florian Fainelli > >>> wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 07:31, Jim Quinlan > > wrote: > >> The Broadcom STB PCIe host controller is intimately related to the > >> memory subsystem. This close relationship adds complexity to how > >> cpu > >> system memory is mapped to PCIe memory. Ideally, this mapping is > >> an > >> identity mapping, or an identity mapping off by a constant. Not > >> so in > >> this case. > >> > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 > >> GB > >> of system memory. Here is how the PCIe controller maps the > >> system memory to PCIe memory: > >> > >>memc0-a@[03fff] <=> pci@[03fff] > >>memc0-b@[1...13fff] <=> pci@[ 40007fff] > >>memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > >>memc1-b@[3...33fff] <=> pci@[ c000] > >>memc2-a@[ 8000bfff] <=> pci@[1...13fff] > >>memc2-b@[c...c3fff] <=> pci@[14000...17fff] > >> > > > > So is describing this as > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > not working for you? I haven't tried this myself, but since DT > > permits > > describing the inbound mappings this way, we should fix the code if > > it > > doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If > that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? > >>> > >>> No those are just memory addresses (although I may have screwed up the > >>> order). From Documentation/devicetree/booting-without-of.txt: > >>> > >>> """ > >>> Optional property: > >>> - dma-ranges: encoded as arbitrary number of > >>> triplets of > >>> (child-bus-address, parent-bus-address, length). Each > >>> triplet specified > >>> describes a contiguous DMA address range. > >>> """ > >>> > >> > >> Then I am confused by your comment, that's what this patch does, it > >> adds > >> support for reading "dma-ranges" from Device Tree and setting up > >> inbound > >> windows using that. The only caveat is that because the PCIe root > >> complex has some ties with the memory bus architecture it is connected > >> to (SCB in our case) there is still a requirement to know the > >> translation between a given physical address and its backing memory > >> controller/aperture. > >> > > > > Ah ok, apologies for the noise then. > > > > I was hoping that having working support for dma-ranges would remove > > the need for the special phys<->dma conversion routines. > > What you describe definitively works with platform devices, but I am not > sure this is working for PCIe devices, although, conceptually it should, > yes. > >>> Sorry for my delay in responding. One problem is that > >>> of_dma_configure() only looks at the first dma-range given and then > >>> converts it to dev->dma_pfn_offset which is respected by the DMA API. > >>> However, we often have multiple dma-ranges, not just one. This is the > >>> big issue. > >>> > >> > >> Given the recent attention to getting these APIs in shape, this may be > >> something Robin or Christoph may care to look into? > > > > It looks like this has been brought up before in the "[RFC PATCH] of: > > Fix DMA configuration for non-DT masters" thread aka > > > > https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html > > > > In the thread "Oza Oza", a Broadcom coworker probably dealing with the > > same exact problem as I, enumerates three problems. #1 and #2 are > > the exact same
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Wed, 26 Sep 2018 at 04:59, Florian Fainelli wrote: > > > > On 9/24/2018 8:01 AM, Jim Quinlan wrote: > > On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel > > wrote: > >> > >> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > >>> > >>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > >>> wrote: > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > On 20 September 2018 at 14:31, Florian Fainelli > > wrote: > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > >>> On 20 September 2018 at 13:55, Florian Fainelli > >>> wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 07:31, Jim Quinlan > > wrote: > >> The Broadcom STB PCIe host controller is intimately related to the > >> memory subsystem. This close relationship adds complexity to how > >> cpu > >> system memory is mapped to PCIe memory. Ideally, this mapping is > >> an > >> identity mapping, or an identity mapping off by a constant. Not > >> so in > >> this case. > >> > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 > >> GB > >> of system memory. Here is how the PCIe controller maps the > >> system memory to PCIe memory: > >> > >>memc0-a@[03fff] <=> pci@[03fff] > >>memc0-b@[1...13fff] <=> pci@[ 40007fff] > >>memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > >>memc1-b@[3...33fff] <=> pci@[ c000] > >>memc2-a@[ 8000bfff] <=> pci@[1...13fff] > >>memc2-b@[c...c3fff] <=> pci@[14000...17fff] > >> > > > > So is describing this as > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > not working for you? I haven't tried this myself, but since DT > > permits > > describing the inbound mappings this way, we should fix the code if > > it > > doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If > that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? > >>> > >>> No those are just memory addresses (although I may have screwed up the > >>> order). From Documentation/devicetree/booting-without-of.txt: > >>> > >>> """ > >>> Optional property: > >>> - dma-ranges: encoded as arbitrary number of > >>> triplets of > >>> (child-bus-address, parent-bus-address, length). Each > >>> triplet specified > >>> describes a contiguous DMA address range. > >>> """ > >>> > >> > >> Then I am confused by your comment, that's what this patch does, it > >> adds > >> support for reading "dma-ranges" from Device Tree and setting up > >> inbound > >> windows using that. The only caveat is that because the PCIe root > >> complex has some ties with the memory bus architecture it is connected > >> to (SCB in our case) there is still a requirement to know the > >> translation between a given physical address and its backing memory > >> controller/aperture. > >> > > > > Ah ok, apologies for the noise then. > > > > I was hoping that having working support for dma-ranges would remove > > the need for the special phys<->dma conversion routines. > > What you describe definitively works with platform devices, but I am not > sure this is working for PCIe devices, although, conceptually it should, > yes. > >>> Sorry for my delay in responding. One problem is that > >>> of_dma_configure() only looks at the first dma-range given and then > >>> converts it to dev->dma_pfn_offset which is respected by the DMA API. > >>> However, we often have multiple dma-ranges, not just one. This is the > >>> big issue. > >>> > >> > >> Given the recent attention to getting these APIs in shape, this may be > >> something Robin or Christoph may care to look into? > > > > It looks like this has been brought up before in the "[RFC PATCH] of: > > Fix DMA configuration for non-DT masters" thread aka > > > > https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html > > > > In the thread "Oza Oza", a Broadcom coworker probably dealing with the > > same exact problem as I, enumerates three problems. #1 and #2 are > > the exact same
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge. Humm, why is that ambiguous for a host bridge/root
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 9/24/2018 8:01 AM, Jim Quinlan wrote: On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: On 20 September 2018 at 14:31, Florian Fainelli wrote: On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: On 20 September 2018 at 13:55, Florian Fainelli wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """ Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Robin, is that something that is expected or should the "dma-ranges" somehow propagate from host bridge down the PCIe end-point drivers? Thanks, Jim In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge. Humm, why is that ambiguous for a host bridge/root
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: > > On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > > wrote: > > > > > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > > > On 20 September 2018 at 14:31, Florian Fainelli > > > > wrote: > > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > > > >>> On 20 September 2018 at 13:55, Florian Fainelli > > > >>> wrote: > > > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > > > On 19 September 2018 at 07:31, Jim Quinlan > > > > wrote: > > > >> The Broadcom STB PCIe host controller is intimately related to the > > > >> memory subsystem. This close relationship adds complexity to how > > > >> cpu > > > >> system memory is mapped to PCIe memory. Ideally, this mapping is > > > >> an > > > >> identity mapping, or an identity mapping off by a constant. Not > > > >> so in > > > >> this case. > > > >> > > > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 > > > >> GB > > > >> of system memory. Here is how the PCIe controller maps the > > > >> system memory to PCIe memory: > > > >> > > > >> memc0-a@[03fff] <=> pci@[03fff] > > > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > > > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > > > >> memc1-b@[3...33fff] <=> pci@[ c000] > > > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > > > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > > > >> > > > > > > > > So is describing this as > > > > > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > > > > > not working for you? I haven't tried this myself, but since DT > > > > permits > > > > describing the inbound mappings this way, we should fix the code if > > > > it > > > > doesn't work at the moment. > > > > > > You mean encoding the memory controller index in the first cell? If > > > that > > > works, that's indeed a much cleaner solution, though is it standard > > > compliant in any form? > > > >>> > > > >>> No those are just memory addresses (although I may have screwed up the > > > >>> order). From Documentation/devicetree/booting-without-of.txt: > > > >>> > > > >>> """ > > > >>> Optional property: > > > >>> - dma-ranges: encoded as arbitrary number of > > > >>> triplets of > > > >>> (child-bus-address, parent-bus-address, length). Each triplet > > > >>> specified > > > >>> describes a contiguous DMA address range. > > > >>> """ > > > >>> > > > >> > > > >> Then I am confused by your comment, that's what this patch does, it > > > >> adds > > > >> support for reading "dma-ranges" from Device Tree and setting up > > > >> inbound > > > >> windows using that. The only caveat is that because the PCIe root > > > >> complex has some ties with the memory bus architecture it is connected > > > >> to (SCB in our case) there is still a requirement to know the > > > >> translation between a given physical address and its backing memory > > > >> controller/aperture. > > > >> > > > > > > > > Ah ok, apologies for the noise then. > > > > > > > > I was hoping that having working support for dma-ranges would remove > > > > the need for the special phys<->dma conversion routines. > > > > > > What you describe definitively works with platform devices, but I am not > > > sure this is working for PCIe devices, although, conceptually it should, > > > yes. > > Sorry for my delay in responding. One problem is that > > of_dma_configure() only looks at the first dma-range given and then > > converts it to dev->dma_pfn_offset which is respected by the DMA API. > > However, we often have multiple dma-ranges, not just one. This is the > > big issue. > > > > Given the recent attention to getting these APIs in shape, this may be > something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Thanks, Jim > > In any case, the description of
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel wrote: > > On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli > > wrote: > > > > > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > > > On 20 September 2018 at 14:31, Florian Fainelli > > > > wrote: > > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > > > >>> On 20 September 2018 at 13:55, Florian Fainelli > > > >>> wrote: > > > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > > > On 19 September 2018 at 07:31, Jim Quinlan > > > > wrote: > > > >> The Broadcom STB PCIe host controller is intimately related to the > > > >> memory subsystem. This close relationship adds complexity to how > > > >> cpu > > > >> system memory is mapped to PCIe memory. Ideally, this mapping is > > > >> an > > > >> identity mapping, or an identity mapping off by a constant. Not > > > >> so in > > > >> this case. > > > >> > > > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 > > > >> GB > > > >> of system memory. Here is how the PCIe controller maps the > > > >> system memory to PCIe memory: > > > >> > > > >> memc0-a@[03fff] <=> pci@[03fff] > > > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > > > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > > > >> memc1-b@[3...33fff] <=> pci@[ c000] > > > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > > > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > > > >> > > > > > > > > So is describing this as > > > > > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > > > > > not working for you? I haven't tried this myself, but since DT > > > > permits > > > > describing the inbound mappings this way, we should fix the code if > > > > it > > > > doesn't work at the moment. > > > > > > You mean encoding the memory controller index in the first cell? If > > > that > > > works, that's indeed a much cleaner solution, though is it standard > > > compliant in any form? > > > >>> > > > >>> No those are just memory addresses (although I may have screwed up the > > > >>> order). From Documentation/devicetree/booting-without-of.txt: > > > >>> > > > >>> """ > > > >>> Optional property: > > > >>> - dma-ranges: encoded as arbitrary number of > > > >>> triplets of > > > >>> (child-bus-address, parent-bus-address, length). Each triplet > > > >>> specified > > > >>> describes a contiguous DMA address range. > > > >>> """ > > > >>> > > > >> > > > >> Then I am confused by your comment, that's what this patch does, it > > > >> adds > > > >> support for reading "dma-ranges" from Device Tree and setting up > > > >> inbound > > > >> windows using that. The only caveat is that because the PCIe root > > > >> complex has some ties with the memory bus architecture it is connected > > > >> to (SCB in our case) there is still a requirement to know the > > > >> translation between a given physical address and its backing memory > > > >> controller/aperture. > > > >> > > > > > > > > Ah ok, apologies for the noise then. > > > > > > > > I was hoping that having working support for dma-ranges would remove > > > > the need for the special phys<->dma conversion routines. > > > > > > What you describe definitively works with platform devices, but I am not > > > sure this is working for PCIe devices, although, conceptually it should, > > > yes. > > Sorry for my delay in responding. One problem is that > > of_dma_configure() only looks at the first dma-range given and then > > converts it to dev->dma_pfn_offset which is respected by the DMA API. > > However, we often have multiple dma-ranges, not just one. This is the > > big issue. > > > > Given the recent attention to getting these APIs in shape, this may be > something Robin or Christoph may care to look into? It looks like this has been brought up before in the "[RFC PATCH] of: Fix DMA configuration for non-DT masters" thread aka https://lists.linuxfoundation.org/pipermail/iommu/2017-April/021325.html In the thread "Oza Oza", a Broadcom coworker probably dealing with the same exact problem as I, enumerates three problems. #1 and #2 are the exact same ones I've just given: the "dma-ranges" prop of the RC DT node is "skipped", and of_dma_get_range() only considers the first entry in any "dma-ranges". Thanks, Jim > > In any case, the description of
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: > > > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > > On 20 September 2018 at 14:31, Florian Fainelli > > > wrote: > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > > >>> On 20 September 2018 at 13:55, Florian Fainelli > > >>> wrote: > > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > > On 19 September 2018 at 07:31, Jim Quinlan > > > wrote: > > >> The Broadcom STB PCIe host controller is intimately related to the > > >> memory subsystem. This close relationship adds complexity to how cpu > > >> system memory is mapped to PCIe memory. Ideally, this mapping is an > > >> identity mapping, or an identity mapping off by a constant. Not so > > >> in > > >> this case. > > >> > > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > > >> of system memory. Here is how the PCIe controller maps the > > >> system memory to PCIe memory: > > >> > > >> memc0-a@[03fff] <=> pci@[03fff] > > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > > >> memc1-b@[3...33fff] <=> pci@[ c000] > > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > > >> > > > > > > So is describing this as > > > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > > > not working for you? I haven't tried this myself, but since DT permits > > > describing the inbound mappings this way, we should fix the code if it > > > doesn't work at the moment. > > > > You mean encoding the memory controller index in the first cell? If > > that > > works, that's indeed a much cleaner solution, though is it standard > > compliant in any form? > > >>> > > >>> No those are just memory addresses (although I may have screwed up the > > >>> order). From Documentation/devicetree/booting-without-of.txt: > > >>> > > >>> """ > > >>> Optional property: > > >>> - dma-ranges: encoded as arbitrary number of > > >>> triplets of > > >>> (child-bus-address, parent-bus-address, length). Each triplet > > >>> specified > > >>> describes a contiguous DMA address range. > > >>> """ > > >>> > > >> > > >> Then I am confused by your comment, that's what this patch does, it adds > > >> support for reading "dma-ranges" from Device Tree and setting up inbound > > >> windows using that. The only caveat is that because the PCIe root > > >> complex has some ties with the memory bus architecture it is connected > > >> to (SCB in our case) there is still a requirement to know the > > >> translation between a given physical address and its backing memory > > >> controller/aperture. > > >> > > > > > > Ah ok, apologies for the noise then. > > > > > > I was hoping that having working support for dma-ranges would remove > > > the need for the special phys<->dma conversion routines. > > > > What you describe definitively works with platform devices, but I am not > > sure this is working for PCIe devices, although, conceptually it should, > > yes. > Sorry for my delay in responding. One problem is that > of_dma_configure() only looks at the first dma-range given and then > converts it to dev->dma_pfn_offset which is respected by the DMA API. > However, we often have multiple dma-ranges, not just one. This is the > big issue. > Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. > There is another issue with of_dma_configure() being invoked by the EP > driver on "bridge->parent->of_node", which is our RC device, > Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of > our RC's device node and this misses the dma-ranges property which is > contained within the RC. I think I could workaround this but there is > no getting around the first problem. > IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge.
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: > > On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: > > > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > > On 20 September 2018 at 14:31, Florian Fainelli > > > wrote: > > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > > >>> On 20 September 2018 at 13:55, Florian Fainelli > > >>> wrote: > > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > > On 19 September 2018 at 07:31, Jim Quinlan > > > wrote: > > >> The Broadcom STB PCIe host controller is intimately related to the > > >> memory subsystem. This close relationship adds complexity to how cpu > > >> system memory is mapped to PCIe memory. Ideally, this mapping is an > > >> identity mapping, or an identity mapping off by a constant. Not so > > >> in > > >> this case. > > >> > > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > > >> of system memory. Here is how the PCIe controller maps the > > >> system memory to PCIe memory: > > >> > > >> memc0-a@[03fff] <=> pci@[03fff] > > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > > >> memc1-b@[3...33fff] <=> pci@[ c000] > > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > > >> > > > > > > So is describing this as > > > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > > > not working for you? I haven't tried this myself, but since DT permits > > > describing the inbound mappings this way, we should fix the code if it > > > doesn't work at the moment. > > > > You mean encoding the memory controller index in the first cell? If > > that > > works, that's indeed a much cleaner solution, though is it standard > > compliant in any form? > > >>> > > >>> No those are just memory addresses (although I may have screwed up the > > >>> order). From Documentation/devicetree/booting-without-of.txt: > > >>> > > >>> """ > > >>> Optional property: > > >>> - dma-ranges: encoded as arbitrary number of > > >>> triplets of > > >>> (child-bus-address, parent-bus-address, length). Each triplet > > >>> specified > > >>> describes a contiguous DMA address range. > > >>> """ > > >>> > > >> > > >> Then I am confused by your comment, that's what this patch does, it adds > > >> support for reading "dma-ranges" from Device Tree and setting up inbound > > >> windows using that. The only caveat is that because the PCIe root > > >> complex has some ties with the memory bus architecture it is connected > > >> to (SCB in our case) there is still a requirement to know the > > >> translation between a given physical address and its backing memory > > >> controller/aperture. > > >> > > > > > > Ah ok, apologies for the noise then. > > > > > > I was hoping that having working support for dma-ranges would remove > > > the need for the special phys<->dma conversion routines. > > > > What you describe definitively works with platform devices, but I am not > > sure this is working for PCIe devices, although, conceptually it should, > > yes. > Sorry for my delay in responding. One problem is that > of_dma_configure() only looks at the first dma-range given and then > converts it to dev->dma_pfn_offset which is respected by the DMA API. > However, we often have multiple dma-ranges, not just one. This is the > big issue. > Given the recent attention to getting these APIs in shape, this may be something Robin or Christoph may care to look into? In any case, the description of dma-ranges should be in sync with the way Linux interprets it, so this is either a documentation bug or a DMA layer bug. > There is another issue with of_dma_configure() being invoked by the EP > driver on "bridge->parent->of_node", which is our RC device, > Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of > our RC's device node and this misses the dma-ranges property which is > contained within the RC. I think I could workaround this but there is > no getting around the first problem. > IIUC dma-ranges should be added to the parent bus of a device, which I guess is slightly ambiguous for a root complex that incorporates a host bridge.
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > On 20 September 2018 at 14:31, Florian Fainelli > > wrote: > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > >>> On 20 September 2018 at 13:55, Florian Fainelli > >>> wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 07:31, Jim Quinlan wrote: > >> The Broadcom STB PCIe host controller is intimately related to the > >> memory subsystem. This close relationship adds complexity to how cpu > >> system memory is mapped to PCIe memory. Ideally, this mapping is an > >> identity mapping, or an identity mapping off by a constant. Not so in > >> this case. > >> > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > >> of system memory. Here is how the PCIe controller maps the > >> system memory to PCIe memory: > >> > >> memc0-a@[03fff] <=> pci@[03fff] > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > >> memc1-b@[3...33fff] <=> pci@[ c000] > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > >> > > > > So is describing this as > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > not working for you? I haven't tried this myself, but since DT permits > > describing the inbound mappings this way, we should fix the code if it > > doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? > >>> > >>> No those are just memory addresses (although I may have screwed up the > >>> order). From Documentation/devicetree/booting-without-of.txt: > >>> > >>> """ > >>> Optional property: > >>> - dma-ranges: encoded as arbitrary number of > >>> triplets of > >>> (child-bus-address, parent-bus-address, length). Each triplet > >>> specified > >>> describes a contiguous DMA address range. > >>> """ > >>> > >> > >> Then I am confused by your comment, that's what this patch does, it adds > >> support for reading "dma-ranges" from Device Tree and setting up inbound > >> windows using that. The only caveat is that because the PCIe root > >> complex has some ties with the memory bus architecture it is connected > >> to (SCB in our case) there is still a requirement to know the > >> translation between a given physical address and its backing memory > >> controller/aperture. > >> > > > > Ah ok, apologies for the noise then. > > > > I was hoping that having working support for dma-ranges would remove > > the need for the special phys<->dma conversion routines. > > What you describe definitively works with platform devices, but I am not > sure this is working for PCIe devices, although, conceptually it should, > yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. Thanks, Jim > -- > Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli wrote: > > On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > > On 20 September 2018 at 14:31, Florian Fainelli > > wrote: > >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > >>> On 20 September 2018 at 13:55, Florian Fainelli > >>> wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 07:31, Jim Quinlan wrote: > >> The Broadcom STB PCIe host controller is intimately related to the > >> memory subsystem. This close relationship adds complexity to how cpu > >> system memory is mapped to PCIe memory. Ideally, this mapping is an > >> identity mapping, or an identity mapping off by a constant. Not so in > >> this case. > >> > >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > >> of system memory. Here is how the PCIe controller maps the > >> system memory to PCIe memory: > >> > >> memc0-a@[03fff] <=> pci@[03fff] > >> memc0-b@[1...13fff] <=> pci@[ 40007fff] > >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > >> memc1-b@[3...33fff] <=> pci@[ c000] > >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] > >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] > >> > > > > So is describing this as > > > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > > > not working for you? I haven't tried this myself, but since DT permits > > describing the inbound mappings this way, we should fix the code if it > > doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? > >>> > >>> No those are just memory addresses (although I may have screwed up the > >>> order). From Documentation/devicetree/booting-without-of.txt: > >>> > >>> """ > >>> Optional property: > >>> - dma-ranges: encoded as arbitrary number of > >>> triplets of > >>> (child-bus-address, parent-bus-address, length). Each triplet > >>> specified > >>> describes a contiguous DMA address range. > >>> """ > >>> > >> > >> Then I am confused by your comment, that's what this patch does, it adds > >> support for reading "dma-ranges" from Device Tree and setting up inbound > >> windows using that. The only caveat is that because the PCIe root > >> complex has some ties with the memory bus architecture it is connected > >> to (SCB in our case) there is still a requirement to know the > >> translation between a given physical address and its backing memory > >> controller/aperture. > >> > > > > Ah ok, apologies for the noise then. > > > > I was hoping that having working support for dma-ranges would remove > > the need for the special phys<->dma conversion routines. > > What you describe definitively works with platform devices, but I am not > sure this is working for PCIe devices, although, conceptually it should, > yes. Sorry for my delay in responding. One problem is that of_dma_configure() only looks at the first dma-range given and then converts it to dev->dma_pfn_offset which is respected by the DMA API. However, we often have multiple dma-ranges, not just one. This is the big issue. There is another issue with of_dma_configure() being invoked by the EP driver on "bridge->parent->of_node", which is our RC device, Of_dma_configure() calls of_dma_range() on the of_get_next_parent() of our RC's device node and this misses the dma-ranges property which is contained within the RC. I think I could workaround this but there is no getting around the first problem. Thanks, Jim > -- > Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 14:31, Florian Fainelli wrote: >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 13:55, Florian Fainelli >>> wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so in >> this case. >> >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >> of system memory. Here is how the PCIe controller maps the >> system memory to PCIe memory: >> >> memc0-a@[03fff] <=> pci@[03fff] >> memc0-b@[1...13fff] <=> pci@[ 40007fff] >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >> memc1-b@[3...33fff] <=> pci@[ c000] >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >> > > So is describing this as > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > not working for you? I haven't tried this myself, but since DT permits > describing the inbound mappings this way, we should fix the code if it > doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? >>> >>> No those are just memory addresses (although I may have screwed up the >>> order). From Documentation/devicetree/booting-without-of.txt: >>> >>> """ >>> Optional property: >>> - dma-ranges: encoded as arbitrary number of triplets >>> of >>> (child-bus-address, parent-bus-address, length). Each triplet >>> specified >>> describes a contiguous DMA address range. >>> """ >>> >> >> Then I am confused by your comment, that's what this patch does, it adds >> support for reading "dma-ranges" from Device Tree and setting up inbound >> windows using that. The only caveat is that because the PCIe root >> complex has some ties with the memory bus architecture it is connected >> to (SCB in our case) there is still a requirement to know the >> translation between a given physical address and its backing memory >> controller/aperture. >> > > Ah ok, apologies for the noise then. > > I was hoping that having working support for dma-ranges would remove > the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 14:31, Florian Fainelli wrote: >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 13:55, Florian Fainelli >>> wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so in >> this case. >> >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >> of system memory. Here is how the PCIe controller maps the >> system memory to PCIe memory: >> >> memc0-a@[03fff] <=> pci@[03fff] >> memc0-b@[1...13fff] <=> pci@[ 40007fff] >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >> memc1-b@[3...33fff] <=> pci@[ c000] >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >> > > So is describing this as > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > not working for you? I haven't tried this myself, but since DT permits > describing the inbound mappings this way, we should fix the code if it > doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? >>> >>> No those are just memory addresses (although I may have screwed up the >>> order). From Documentation/devicetree/booting-without-of.txt: >>> >>> """ >>> Optional property: >>> - dma-ranges: encoded as arbitrary number of triplets >>> of >>> (child-bus-address, parent-bus-address, length). Each triplet >>> specified >>> describes a contiguous DMA address range. >>> """ >>> >> >> Then I am confused by your comment, that's what this patch does, it adds >> support for reading "dma-ranges" from Device Tree and setting up inbound >> windows using that. The only caveat is that because the PCIe root >> complex has some ties with the memory bus architecture it is connected >> to (SCB in our case) there is still a requirement to know the >> translation between a given physical address and its backing memory >> controller/aperture. >> > > Ah ok, apologies for the noise then. > > I was hoping that having working support for dma-ranges would remove > the need for the special phys<->dma conversion routines. What you describe definitively works with platform devices, but I am not sure this is working for PCIe devices, although, conceptually it should, yes. -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 20 September 2018 at 14:31, Florian Fainelli wrote: > On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >> On 20 September 2018 at 13:55, Florian Fainelli wrote: >>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: > The Broadcom STB PCIe host controller is intimately related to the > memory subsystem. This close relationship adds complexity to how cpu > system memory is mapped to PCIe memory. Ideally, this mapping is an > identity mapping, or an identity mapping off by a constant. Not so in > this case. > > Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > of system memory. Here is how the PCIe controller maps the > system memory to PCIe memory: > > memc0-a@[03fff] <=> pci@[03fff] > memc0-b@[1...13fff] <=> pci@[ 40007fff] > memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > memc1-b@[3...33fff] <=> pci@[ c000] > memc2-a@[ 8000bfff] <=> pci@[1...13fff] > memc2-b@[c...c3fff] <=> pci@[14000...17fff] > So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. >>> >>> You mean encoding the memory controller index in the first cell? If that >>> works, that's indeed a much cleaner solution, though is it standard >>> compliant in any form? >> >> No those are just memory addresses (although I may have screwed up the >> order). From Documentation/devicetree/booting-without-of.txt: >> >> """ >> Optional property: >> - dma-ranges: encoded as arbitrary number of triplets of >> (child-bus-address, parent-bus-address, length). Each triplet >> specified >> describes a contiguous DMA address range. >> """ >> > > Then I am confused by your comment, that's what this patch does, it adds > support for reading "dma-ranges" from Device Tree and setting up inbound > windows using that. The only caveat is that because the PCIe root > complex has some ties with the memory bus architecture it is connected > to (SCB in our case) there is still a requirement to know the > translation between a given physical address and its backing memory > controller/aperture. > Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines.
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 20 September 2018 at 14:31, Florian Fainelli wrote: > On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >> On 20 September 2018 at 13:55, Florian Fainelli wrote: >>> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: On 19 September 2018 at 07:31, Jim Quinlan wrote: > The Broadcom STB PCIe host controller is intimately related to the > memory subsystem. This close relationship adds complexity to how cpu > system memory is mapped to PCIe memory. Ideally, this mapping is an > identity mapping, or an identity mapping off by a constant. Not so in > this case. > > Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB > of system memory. Here is how the PCIe controller maps the > system memory to PCIe memory: > > memc0-a@[03fff] <=> pci@[03fff] > memc0-b@[1...13fff] <=> pci@[ 40007fff] > memc1-a@[ 40007fff] <=> pci@[ 8000bfff] > memc1-b@[3...33fff] <=> pci@[ c000] > memc2-a@[ 8000bfff] <=> pci@[1...13fff] > memc2-b@[c...c3fff] <=> pci@[14000...17fff] > So is describing this as dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, <0x0 0x4000 0x1 0x0 0x0 0x4000>, <0x0 0x8000 0x0 0x4000 0x0 0x4000>, <0x0 0xc000 0x3 0x0 0x0 0x4000>, <0x1 0x0 0x0 0x8000 0x0 0x4000>, <0x1 0x4000 0x0 0xc000 0x0 0x4000>; not working for you? I haven't tried this myself, but since DT permits describing the inbound mappings this way, we should fix the code if it doesn't work at the moment. >>> >>> You mean encoding the memory controller index in the first cell? If that >>> works, that's indeed a much cleaner solution, though is it standard >>> compliant in any form? >> >> No those are just memory addresses (although I may have screwed up the >> order). From Documentation/devicetree/booting-without-of.txt: >> >> """ >> Optional property: >> - dma-ranges: encoded as arbitrary number of triplets of >> (child-bus-address, parent-bus-address, length). Each triplet >> specified >> describes a contiguous DMA address range. >> """ >> > > Then I am confused by your comment, that's what this patch does, it adds > support for reading "dma-ranges" from Device Tree and setting up inbound > windows using that. The only caveat is that because the PCIe root > complex has some ties with the memory bus architecture it is connected > to (SCB in our case) there is still a requirement to know the > translation between a given physical address and its backing memory > controller/aperture. > Ah ok, apologies for the noise then. I was hoping that having working support for dma-ranges would remove the need for the special phys<->dma conversion routines.
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 13:55, Florian Fainelli wrote: >> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >>> On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >>> So is describing this as >>> >>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >>> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >>> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >>> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >>> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >>> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >>> >>> not working for you? I haven't tried this myself, but since DT permits >>> describing the inbound mappings this way, we should fix the code if it >>> doesn't work at the moment. >> >> You mean encoding the memory controller index in the first cell? If that >> works, that's indeed a much cleaner solution, though is it standard >> compliant in any form? > > No those are just memory addresses (although I may have screwed up the > order). From Documentation/devicetree/booting-without-of.txt: > > """ > Optional property: > - dma-ranges: encoded as arbitrary number of triplets of > (child-bus-address, parent-bus-address, length). Each triplet > specified > describes a contiguous DMA address range. > """ > Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 13:55, Florian Fainelli wrote: >> On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >>> On 19 September 2018 at 07:31, Jim Quinlan wrote: The Broadcom STB PCIe host controller is intimately related to the memory subsystem. This close relationship adds complexity to how cpu system memory is mapped to PCIe memory. Ideally, this mapping is an identity mapping, or an identity mapping off by a constant. Not so in this case. Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB of system memory. Here is how the PCIe controller maps the system memory to PCIe memory: memc0-a@[03fff] <=> pci@[03fff] memc0-b@[1...13fff] <=> pci@[ 40007fff] memc1-a@[ 40007fff] <=> pci@[ 8000bfff] memc1-b@[3...33fff] <=> pci@[ c000] memc2-a@[ 8000bfff] <=> pci@[1...13fff] memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >>> So is describing this as >>> >>> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >>> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >>> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >>> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >>> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >>> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >>> >>> not working for you? I haven't tried this myself, but since DT permits >>> describing the inbound mappings this way, we should fix the code if it >>> doesn't work at the moment. >> >> You mean encoding the memory controller index in the first cell? If that >> works, that's indeed a much cleaner solution, though is it standard >> compliant in any form? > > No those are just memory addresses (although I may have screwed up the > order). From Documentation/devicetree/booting-without-of.txt: > > """ > Optional property: > - dma-ranges: encoded as arbitrary number of triplets of > (child-bus-address, parent-bus-address, length). Each triplet > specified > describes a contiguous DMA address range. > """ > Then I am confused by your comment, that's what this patch does, it adds support for reading "dma-ranges" from Device Tree and setting up inbound windows using that. The only caveat is that because the PCIe root complex has some ties with the memory bus architecture it is connected to (SCB in our case) there is still a requirement to know the translation between a given physical address and its backing memory controller/aperture. -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 20 September 2018 at 13:55, Florian Fainelli wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >> On 19 September 2018 at 07:31, Jim Quinlan wrote: >>> The Broadcom STB PCIe host controller is intimately related to the >>> memory subsystem. This close relationship adds complexity to how cpu >>> system memory is mapped to PCIe memory. Ideally, this mapping is an >>> identity mapping, or an identity mapping off by a constant. Not so in >>> this case. >>> >>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >>> of system memory. Here is how the PCIe controller maps the >>> system memory to PCIe memory: >>> >>> memc0-a@[03fff] <=> pci@[03fff] >>> memc0-b@[1...13fff] <=> pci@[ 40007fff] >>> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >>> memc1-b@[3...33fff] <=> pci@[ c000] >>> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >>> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >> >> So is describing this as >> >> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >> >> not working for you? I haven't tried this myself, but since DT permits >> describing the inbound mappings this way, we should fix the code if it >> doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 20 September 2018 at 13:55, Florian Fainelli wrote: > On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: >> On 19 September 2018 at 07:31, Jim Quinlan wrote: >>> The Broadcom STB PCIe host controller is intimately related to the >>> memory subsystem. This close relationship adds complexity to how cpu >>> system memory is mapped to PCIe memory. Ideally, this mapping is an >>> identity mapping, or an identity mapping off by a constant. Not so in >>> this case. >>> >>> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >>> of system memory. Here is how the PCIe controller maps the >>> system memory to PCIe memory: >>> >>> memc0-a@[03fff] <=> pci@[03fff] >>> memc0-b@[1...13fff] <=> pci@[ 40007fff] >>> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >>> memc1-b@[3...33fff] <=> pci@[ c000] >>> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >>> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >>> >> >> So is describing this as >> >> dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, >> <0x0 0x4000 0x1 0x0 0x0 0x4000>, >> <0x0 0x8000 0x0 0x4000 0x0 0x4000>, >> <0x0 0xc000 0x3 0x0 0x0 0x4000>, >> <0x1 0x0 0x0 0x8000 0x0 0x4000>, >> <0x1 0x4000 0x0 0xc000 0x0 0x4000>; >> >> not working for you? I haven't tried this myself, but since DT permits >> describing the inbound mappings this way, we should fix the code if it >> doesn't work at the moment. > > You mean encoding the memory controller index in the first cell? If that > works, that's indeed a much cleaner solution, though is it standard > compliant in any form? No those are just memory addresses (although I may have screwed up the order). From Documentation/devicetree/booting-without-of.txt: """ Optional property: - dma-ranges: encoded as arbitrary number of triplets of (child-bus-address, parent-bus-address, length). Each triplet specified describes a contiguous DMA address range. """
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so in >> this case. >> >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >> of system memory. Here is how the PCIe controller maps the >> system memory to PCIe memory: >> >> memc0-a@[03fff] <=> pci@[03fff] >> memc0-b@[1...13fff] <=> pci@[ 40007fff] >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >> memc1-b@[3...33fff] <=> pci@[ c000] >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >> > > So is describing this as > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > not working for you? I haven't tried this myself, but since DT permits > describing the inbound mappings this way, we should fix the code if it > doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so in >> this case. >> >> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB >> of system memory. Here is how the PCIe controller maps the >> system memory to PCIe memory: >> >> memc0-a@[03fff] <=> pci@[03fff] >> memc0-b@[1...13fff] <=> pci@[ 40007fff] >> memc1-a@[ 40007fff] <=> pci@[ 8000bfff] >> memc1-b@[3...33fff] <=> pci@[ c000] >> memc2-a@[ 8000bfff] <=> pci@[1...13fff] >> memc2-b@[c...c3fff] <=> pci@[14000...17fff] >> > > So is describing this as > > dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>, > <0x0 0x4000 0x1 0x0 0x0 0x4000>, > <0x0 0x8000 0x0 0x4000 0x0 0x4000>, > <0x0 0xc000 0x3 0x0 0x0 0x4000>, > <0x1 0x0 0x0 0x8000 0x0 0x4000>, > <0x1 0x4000 0x0 0xc000 0x0 0x4000>; > > not working for you? I haven't tried this myself, but since DT permits > describing the inbound mappings this way, we should fix the code if it > doesn't work at the moment. You mean encoding the memory controller index in the first cell? If that works, that's indeed a much cleaner solution, though is it standard compliant in any form? -- Florian
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 19 September 2018 at 07:31, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[03fff] <=> pci@[03fff]
> memc0-b@[1...13fff] <=> pci@[ 40007fff]
> memc1-a@[ 40007fff] <=> pci@[ 8000bfff]
> memc1-b@[3...33fff] <=> pci@[ c000]
> memc2-a@[ 8000bfff] <=> pci@[1...13fff]
> memc2-b@[c...c3fff] <=> pci@[14000...17fff]
>
So is describing this as
dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>,
<0x0 0x4000 0x1 0x0 0x0 0x4000>,
<0x0 0x8000 0x0 0x4000 0x0 0x4000>,
<0x0 0xc000 0x3 0x0 0x0 0x4000>,
<0x1 0x0 0x0 0x8000 0x0 0x4000>,
<0x1 0x4000 0x0 0xc000 0x0 0x4000>;
not working for you? I haven't tried this myself, but since DT permits
describing the inbound mappings this way, we should fix the code if it
doesn't work at the moment.
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. The method to do
> this is to redefine the __dma_to_phys() and __phys_to_dma() functions
> of the ARM, ARM64, and MIPS architectures. This commit sets up the
> infrastructure in the Brcm PCIe controller to prepare for this, while
> there is three other subsequent commits to implement/redefine these
> two functions for the three target architectures.
>
> Signed-off-by: Jim Quinlan
> ---
> drivers/pci/controller/pcie-brcmstb.c | 130
> ++
> include/soc/brcmstb/common.h | 16 +
> 2 files changed, 133 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index 9c87d10..abfa429 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -321,6 +322,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus
> *bus, unsigned int devfn,
> (((val) & ~reg##_##field##_MASK) | \
> (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> +static struct of_pci_range *brcm_dma_ranges;
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> static int num_memc;
> static int num_pcie;
> @@ -599,6 +601,79 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie
> *pcie,
> WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
> }
>
> +static int brcm_pcie_parse_map_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + /*
> +* Parse dma-ranges property if present. If there are multiple
> +* PCIe controllers, we only have to parse from one of them since
> +* the others will have an identical mapping.
> +*/
> + if (!of_pci_dma_range_parser_init(, dn)) {
> + struct of_pci_range *p;
> + unsigned int max_ranges = (parser.end - parser.range)
> + / parser.np;
> +
> + /* Add a null entry to indicate the end of the array */
> + brcm_dma_ranges = kcalloc(max_ranges + 1,
> + sizeof(struct of_pci_range),
> +
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
On 19 September 2018 at 07:31, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[03fff] <=> pci@[03fff]
> memc0-b@[1...13fff] <=> pci@[ 40007fff]
> memc1-a@[ 40007fff] <=> pci@[ 8000bfff]
> memc1-b@[3...33fff] <=> pci@[ c000]
> memc2-a@[ 8000bfff] <=> pci@[1...13fff]
> memc2-b@[c...c3fff] <=> pci@[14000...17fff]
>
So is describing this as
dma-ranges = <0x0 0x0 0x0 0x0 0x0 0x4000>,
<0x0 0x4000 0x1 0x0 0x0 0x4000>,
<0x0 0x8000 0x0 0x4000 0x0 0x4000>,
<0x0 0xc000 0x3 0x0 0x0 0x4000>,
<0x1 0x0 0x0 0x8000 0x0 0x4000>,
<0x1 0x4000 0x0 0xc000 0x0 0x4000>;
not working for you? I haven't tried this myself, but since DT permits
describing the inbound mappings this way, we should fix the code if it
doesn't work at the moment.
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. The method to do
> this is to redefine the __dma_to_phys() and __phys_to_dma() functions
> of the ARM, ARM64, and MIPS architectures. This commit sets up the
> infrastructure in the Brcm PCIe controller to prepare for this, while
> there is three other subsequent commits to implement/redefine these
> two functions for the three target architectures.
>
> Signed-off-by: Jim Quinlan
> ---
> drivers/pci/controller/pcie-brcmstb.c | 130
> ++
> include/soc/brcmstb/common.h | 16 +
> 2 files changed, 133 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index 9c87d10..abfa429 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -321,6 +322,7 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus
> *bus, unsigned int devfn,
> (((val) & ~reg##_##field##_MASK) | \
> (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> +static struct of_pci_range *brcm_dma_ranges;
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> static int num_memc;
> static int num_pcie;
> @@ -599,6 +601,79 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie
> *pcie,
> WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
> }
>
> +static int brcm_pcie_parse_map_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + /*
> +* Parse dma-ranges property if present. If there are multiple
> +* PCIe controllers, we only have to parse from one of them since
> +* the others will have an identical mapping.
> +*/
> + if (!of_pci_dma_range_parser_init(, dn)) {
> + struct of_pci_range *p;
> + unsigned int max_ranges = (parser.end - parser.range)
> + / parser.np;
> +
> + /* Add a null entry to indicate the end of the array */
> + brcm_dma_ranges = kcalloc(max_ranges + 1,
> + sizeof(struct of_pci_range),
> +
