| Message ID | 1516058925-46522-1-git-send-email-jim2101024@gmail.com |
|---|---|
| Headers | show |
| Series | PCI: brcmstb: Add Broadcom Settopbox PCIe support | expand |
On Mon, Jan 15, 2018 at 5:28 PM, Jim Quinlan <jim2101024@gmail.com> 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@[ 0....3fffffff] <=> pci@[ 0....3fffffff] > memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff] > memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff] > memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff] > memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff] > memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff] > > 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_0000, 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_0000. But this > won't work; the device needs a dma_addr_t that reflects the PCIe space > address, namely 0xa000_0000. > > So, essentially the solution to this problem must modify the > dma_addr_t returned by the DMA routines routines. There are two > ways (I know of) of doing this: > > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls > that are used by the dma_ops routines. This is the approach of > > arch/mips/cavium-octeon/dma-octeon.c MIPS is rarely an example to follow. :) > In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h > as static inline functions. > > (b) Subscribe to a notifier that notifies when a device is added to a > bus. When this happens, set_dma_ops() can be called for the device. > This method is mentioned in: > > http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152 Why refer to an external website when you can just refer to the source of the project this patch applies to directly. > where it says as a comment > > "In case if platform code need to use own special DMA > configuration, it can use Platform bus notifier and > handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA > configuration." In the current tree, this comment is in drivers/of/device.c. > Solution (b) is what this commit does. It uses its own set of > dma_ops which are wrappers around the arch_dma_ops. The > wrappers translate the dma addresses before/after invoking > the arch_dma_ops, as appropriate. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: > > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls > > that are used by the dma_ops routines. This is the approach of > > > > arch/mips/cavium-octeon/dma-octeon.c > > MIPS is rarely an example to follow. :) But in this case it actually is the example to follow as told previously. NAK again for these chained dma ops that only create problems. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On January 17, 2018 11:31:23 PM PST, Christoph Hellwig <hch@lst.de> wrote: >On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote: >> > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls >> > that are used by the dma_ops routines. This is the approach of >> > >> > arch/mips/cavium-octeon/dma-octeon.c >> >> MIPS is rarely an example to follow. :) > >But in this case it actually is the example to follow as told >previously. > >NAK again for these chained dma ops that only create problems. Care to explain what should be done instead?
On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: > >But in this case it actually is the example to follow as told > >previously. > > > >NAK again for these chained dma ops that only create problems. > > Care to explain what should be done instead? Override phys_to_dma and dma_to_phys as mips and x86 do for similar situations. Bonous points of finding some generic way of doing it instead of hiding it in arch code. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/18/2018 07:23 AM, Christoph Hellwig wrote: > On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote: >>> But in this case it actually is the example to follow as told >>> previously. >>> >>> NAK again for these chained dma ops that only create problems. >> >> Care to explain what should be done instead? > > Override phys_to_dma and dma_to_phys as mips and x86 do for similar > situations. How can this work well in the context of a loadable module for instance? For MIPS, this would mean that we have to override phys_to_dma() and dma_to_phys() in the platform that is *susceptible* to use this PCIe controller (arch/mips/bmips) which is fine, but there, we essentially need to find a way to make this dynamic based on whether the PCIe controller is loaded or not. As you might have seen from this patch, what needs to be done is highly dependent on the processor architecture and its memory controller physical memory map, so I don't see how we are in any better situation if we need to replicate 3 times across MIPS, ARM and ARM64 how the addresses need to be mangled. Are you suggesting we somehow decouple the memory mangling part into a portion that can be built into the kernel image (so phys_to_dma() and dma_to_phys() is resolved at vmlinux link time) and can be selected by different architectures that need it? If so, yikes. > > Bonous points of finding some generic way of doing it instead of > hiding it in arch code. > I can see value in having a generic mechanism, ala X86_DMA_REMAP allowing architectures to have the ability to override phys_to_dma() and dma_to_phys() but right now, especially if we look at arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and equally ugly than stacking operations... What is the actual problem you want to avoid with the stacking of DMA operations, is it because it becomes harder to audit, or are there are other reasons?
On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: > How can this work well in the context of a loadable module for instance? > For MIPS, this would mean that we have to override phys_to_dma() and > dma_to_phys() in the platform that is *susceptible* to use this PCIe > controller (arch/mips/bmips) which is fine, but there, we essentially > need to find a way to make this dynamic based on whether the PCIe > controller is loaded or not. > > As you might have seen from this patch, what needs to be done is highly > dependent on the processor architecture and its memory controller > physical memory map, so I don't see how we are in any better situation > if we need to replicate 3 times across MIPS, ARM and ARM64 how the > addresses need to be mangled. > > Are you suggesting we somehow decouple the memory mangling part into a > portion that can be built into the kernel image (so phys_to_dma() and > dma_to_phys() is resolved at vmlinux link time) and can be selected by > different architectures that need it? If so, yikes. On architectures with crazy PCIe controllers (this seems to include mips, arm, arm64 and x86 thanks to the weird SOCs) we will need a a few different memory maps, yes. Take a look at arch/x86/pci/sta2x11-fixup.c, preferably from a tree where the worst issues are fixed: http://git.infradead.org/users/hch/misc.git/blob/refs/heads/dma-direct-all:/arch/x86/pci/sta2x11-fixup.c Overriding phys_to_dma and dma_to_phys is required if you need to support swiotlb, and chances are with a broken PCIe controller on arm64 or mips64 you eventuall will. This sta2x11 code should probably be lifted to common code in one form or another eventually, althought it will need another fair round of cleanups for now. > I can see value in having a generic mechanism, ala X86_DMA_REMAP > allowing architectures to have the ability to override phys_to_dma() and > dma_to_phys() but right now, especially if we look at > arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and > equally ugly than stacking operations... > > What is the actual problem you want to avoid with the stacking of DMA > operations, is it because it becomes harder to audit, or are there are > other reasons? Audit, consolidate into a single dma-direct implementation and properly support swiotlb out of the box. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/23/2018 05:20 AM, Christoph Hellwig wrote: > On Fri, Jan 19, 2018 at 11:47:54AM -0800, Florian Fainelli wrote: >> How can this work well in the context of a loadable module for instance? >> For MIPS, this would mean that we have to override phys_to_dma() and >> dma_to_phys() in the platform that is *susceptible* to use this PCIe >> controller (arch/mips/bmips) which is fine, but there, we essentially >> need to find a way to make this dynamic based on whether the PCIe >> controller is loaded or not. >> >> As you might have seen from this patch, what needs to be done is highly >> dependent on the processor architecture and its memory controller >> physical memory map, so I don't see how we are in any better situation >> if we need to replicate 3 times across MIPS, ARM and ARM64 how the >> addresses need to be mangled. >> >> Are you suggesting we somehow decouple the memory mangling part into a >> portion that can be built into the kernel image (so phys_to_dma() and >> dma_to_phys() is resolved at vmlinux link time) and can be selected by >> different architectures that need it? If so, yikes. > > On architectures with crazy PCIe controllers (this seems to include > mips, arm, arm64 and x86 thanks to the weird SOCs) we will need a > a few different memory maps, yes. Take a look at > arch/x86/pci/sta2x11-fixup.c, preferably from a tree where the worst > issues are fixed: > > http://git.infradead.org/users/hch/misc.git/blob/refs/heads/dma-direct-all:/arch/x86/pci/sta2x11-fixup.c > > Overriding phys_to_dma and dma_to_phys is required if you need to > support swiotlb, and chances are with a broken PCIe controller on > arm64 or mips64 you eventuall will. > > This sta2x11 code should probably be lifted to common code in > one form or another eventually, althought it will need another > fair round of cleanups for now. This looks nicer than the current shape, but this still requires to register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it would appear that you have dodged my question about how this is supposed to fit with an entirely modular PCIe root complex driver? Are you suggesting that we split the module into a built-in part and a modular part? > >> I can see value in having a generic mechanism, ala X86_DMA_REMAP >> allowing architectures to have the ability to override phys_to_dma() and >> dma_to_phys() but right now, especially if we look at >> arch/x86/pci/sta2x11-fixup.c this really appears to be quite messy and >> equally ugly than stacking operations... >> >> What is the actual problem you want to avoid with the stacking of DMA >> operations, is it because it becomes harder to audit, or are there are >> other reasons? > > Audit, consolidate into a single dma-direct implementation and properly > support swiotlb out of the box. > OK.
On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: > This looks nicer than the current shape, but this still requires to > register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it > would appear that you have dodged my question about how this is supposed > to fit with an entirely modular PCIe root complex driver? Are you > suggesting that we split the module into a built-in part and a modular part? I don't think entirely modular PCI root bridges should be a focal point for the design. If we happen to support them by other design choices: fine, but they should not be a priority. That being said if we have core dma mapping or PCIe code that has a list of offsets and the root complex only populates them it should work just fine. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig <hch@lst.de> wrote: > On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >> This looks nicer than the current shape, but this still requires to >> register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it >> would appear that you have dodged my question about how this is supposed >> to fit with an entirely modular PCIe root complex driver? Are you >> suggesting that we split the module into a built-in part and a modular part? > > I don't think entirely modular PCI root bridges should be a focal point > for the design. If we happen to support them by other design choices: > fine, but they should not be a priority. I disagree. If there is one common thing our customers request it is the ability to remove (or control the insmod of after boot) the pcie RC driver. I didn't add this in as a "nice-to-have". > > That being said if we have core dma mapping or PCIe code that has > a list of offsets and the root complex only populates them it should > work just fine. I'm looking at arch/arm/include/asm/dma-mapping.h. In addition to overriding dma_to_phsy() and phys_to_dma(), it looks like I may have to define __arch_pfn_to_dma(), __arch_dma_to_pfn(), __arch_dma_to_virt(), __arch_virt_to_dma(). Do you agree or is this not necessary? If it is, this seems more intrusive than our pcie-brcmstb-dma.c solution which doesn't require tentacles into major include files and Kconfigs. Another issue is that our function wrappers -- depending upon whether we are dealing with a pci device or not -- will have to possibly call the actual ARM and ARM64 definitions of these functions, which have been of course #ifdef'd out. This means that our code must contain identical copies of these functions' code and that the code must somehow be kept in sync. Do you see a solution to this? Jim -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 26, 2018 at 12:46 PM, Jim Quinlan <jim2101024@gmail.com> wrote: > On Fri, Jan 26, 2018 at 2:53 AM, Christoph Hellwig <hch@lst.de> wrote: >> On Wed, Jan 24, 2018 at 12:04:58PM -0800, Florian Fainelli wrote: >>> This looks nicer than the current shape, but this still requires to >>> register a PCI fixup to override phys_to_dma() and dma_to_phys(), and it >>> would appear that you have dodged my question about how this is supposed >>> to fit with an entirely modular PCIe root complex driver? Are you >>> suggesting that we split the module into a built-in part and a modular part? >> >> I don't think entirely modular PCI root bridges should be a focal point >> for the design. If we happen to support them by other design choices: >> fine, but they should not be a priority. > > I disagree. If there is one common thing our customers request it is > the ability to remove (or control the insmod of after boot) the pcie > RC driver. I didn't add this in as a "nice-to-have". > >> >> That being said if we have core dma mapping or PCIe code that has >> a list of offsets and the root complex only populates them it should >> work just fine. > > I'm looking at arch/arm/include/asm/dma-mapping.h. In addition to > overriding dma_to_phsy() and phys_to_dma(), it looks like I may have > to define __arch_pfn_to_dma(), __arch_dma_to_pfn(), > __arch_dma_to_virt(), __arch_virt_to_dma(). Do you agree or is this > not necessary? If it is, this seems more intrusive than our > pcie-brcmstb-dma.c solution which doesn't require tentacles into > major include files and Kconfigs. > > Another issue is that our function wrappers -- depending upon whether > we are dealing with a pci device or not -- will have to possibly call > the actual ARM and ARM64 definitions of these functions, which have > been of course #ifdef'd out. This means that our code must contain > identical copies of these functions' code and that the code must > somehow be kept in sync. Do you see a solution to this? > > Jim Cristoph, Could you please respond to my comments? Even a negative response is better than none. The problem with doing what you suggested is with ARM -- ARM64 and MIPS relatively uncomplicated . With ARM, I have to define the aforementioned functions -- the only way of doing this is to define arch/arm/mach-bcm/include/mach/memory.h, and for that to be picked up we no longer can have CONFIG_ARCH_MULTIPLATFORM=y, which is an unacceptable cost to pay for just an unusual PCIe RC controller. Regarding my current submission -- you are right, SWIOTLB will not work for EPs that require it. However, we don't care about these devices, and can just bailout with EPs when the dma_mask is <= 0xffff_ffff or if swiotlb_force == SWIOTLB_FORCE. Note that this would only affect PCIe DMA. We also have no plan of using MIPS64. -- Jim -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 15, 2018 at 06:28:44PM -0500, Jim Quinlan wrote: > diff --git a/arch/mips/boot/dts/brcm/bcm7425.dtsi b/arch/mips/boot/dts/brcm/bcm7425.dtsi > index e4fb9b6..02168d0 100644 > --- a/arch/mips/boot/dts/brcm/bcm7425.dtsi > +++ b/arch/mips/boot/dts/brcm/bcm7425.dtsi > @@ -495,4 +495,30 @@ > status = "disabled"; > }; > }; > + > + pcie: pcie@10410000 { > + reg = <0x10410000 0x830c>; > + compatible = "brcm,bcm7425-pcie"; > + interrupts = <37>, <37>; > + interrupt-names = "pcie", "msi"; > + interrupt-parent = <&periph_intc>; > + #address-cells = <3>; > + #size-cells = <2>; > + linux,pci-domain = <0>; > + brcm,enable-ssc; > + bus-range = <0x00 0xff>; > + msi-controller; > + #interrupt-cells = <1>; > + /* 4x128mb windows */ > + ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>, > + <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>, > + <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>, > + <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>; > + interrupt-map-mask = <0 0 0 7>; > + interrupt-map = <0 0 0 1 &periph_intc 33 > + 0 0 0 2 &periph_intc 34 > + 0 0 0 3 &periph_intc 35 > + 0 0 0 4 &periph_intc 36>; no status = "disabled" like the other dtsi? > + }; > + > }; > diff --git a/arch/mips/boot/dts/brcm/bcm7435.dtsi b/arch/mips/boot/dts/brcm/bcm7435.dtsi > index 1484e89..84881224 100644 > --- a/arch/mips/boot/dts/brcm/bcm7435.dtsi > +++ b/arch/mips/boot/dts/brcm/bcm7435.dtsi > @@ -510,4 +510,31 @@ > status = "disabled"; > }; > }; > + > + pcie: pcie@10410000 { > + reg = <0x10410000 0x930c>; > + interrupts = <0x27>, <0x27>; > + interrupt-names = "pcie", "msi"; > + interrupt-parent = <&periph_intc>; > + compatible = "brcm,bcm7435-pcie"; Might be nice to be consistent in your property ordering between these two dtsi files. I for one would prefer compatible to be near the top too, if only for consistency with most other nodes in these files. > + #address-cells = <3>; > + #size-cells = <2>; > + linux,pci-domain = <0>; > + brcm,enable-ssc; > + bus-range = <0x00 0xff>; > + msi-controller; > + #interrupt-cells = <1>; > + /* 4x128mb windows */ > + ranges = <0x2000000 0x0 0xd0000000 0xd0000000 0 0x08000000>, > + <0x2000000 0x0 0xd8000000 0xd8000000 0 0x08000000>, > + <0x2000000 0x0 0xe0000000 0xe0000000 0 0x08000000>, > + <0x2000000 0x0 0xe8000000 0xe8000000 0 0x08000000>; > + interrupt-map-mask = <0 0 0 7>; > + interrupt-map = <0 0 0 1 &periph_intc 35 > + 0 0 0 2 &periph_intc 36 > + 0 0 0 3 &periph_intc 37 > + 0 0 0 4 &periph_intc 38>; > + status = "disabled"; > + }; > + > }; Cheers James
On Mon, Jan 15, 2018 at 06:28:38PM -0500, Jim Quinlan wrote: > From: Florian Fainelli <f.fainelli@gmail.com> > > This commit adds a memory API suitable for ascertaining the sizes of > each of the N memory controllers in a Broadcom STB chip. Its first > user will be the Broadcom STB PCIe root complex driver, which needs > to know these sizes to properly set up DMA mappings for inbound > regions. > > We cannot use memblock here or anything like what Linux provides > because it collapses adjacent regions within a larger block, and here > we actually need per-memory controller addresses and sizes, which is > why we resort to manual DT parsing. > > Signed-off-by: Jim Quinlan <jim2101024@gmail.com> > > Conflicts: > drivers/soc/bcm/brcmstb/Makefile That can go. > +++ b/drivers/soc/bcm/brcmstb/memory.c ... > +/* Macro to help extract property data */ > +#define DT_PROP_DATA_TO_U32(b, offs) (fdt32_to_cpu(*(u32*)(b + offs))) Checkpatch complains about missing whitespace after u32. Cheers James