| Message ID | 1537367527-20773-12-git-send-email-jim2101024@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | PCI: brcmstb: Add Broadcom Settopbox PCIe support (resend) | expand |
On Wed, Sep 19, 2018 at 10:32:06AM -0400, Jim Quinlan wrote: > +#if defined(CONFIG_ARM64) Please use plain #ifdef where possible. > +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) > +{ > + return brcm_phys_to_dma(dev, paddr); > +} > + > +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr) > +{ > + return brcm_dma_to_phys(dev, dev_addr); > +} > +#endif How is this going to work for a kernel with BrcmSTB built in, but running on a more standard arm64 SOC? I suspect we really just want a set of ranges hanging off struct device (conditional on a config option). Each SoC can then fill it at boot time, and if it is non-NULL the DMA code will use it instead of calling __phys_to_dma and __dma_to_phys. In fact the single range version could probably just replace the existing dma_pfn_offset field.
On Wed, Sep 19, 2018 at 10:41 AM Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Sep 19, 2018 at 10:32:06AM -0400, Jim Quinlan wrote: > > +#if defined(CONFIG_ARM64) > > Please use plain #ifdef where possible. > > > +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) > > +{ > > + return brcm_phys_to_dma(dev, paddr); > > +} > > + > > +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr) > > +{ > > + return brcm_dma_to_phys(dev, dev_addr); > > +} > > +#endif > > How is this going to work for a kernel with BrcmSTB built in, but running > on a more standard arm64 SOC? Sorry for the delay in my response. It would work because the dma_ranges would be empty/null and identity mapping would happen, but yes, all __dma_to_phys and __phys_to_dma calls would be wasting time going through the brcm functions. We would have to take BRCMSTB=y out of the defconfig. Florian would probably NAK that idea. Please remember that the reason for this approach is because in your response to V4 you suggested that "Override phys_to_dma and dma_to_phys as mips and x86 [sta2x11] do for similar situations" and "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". > > I suspect we really just want a set of ranges hanging off struct device > (conditional on a config option). Each SoC can then fill it at boot > time, and if it is non-NULL the DMA code will use it instead of > calling __phys_to_dma and __dma_to_phys. In fact the single range > version could probably just replace the existing dma_pfn_offset > field. If this was a config option then BRCMSTB=y in defconfig would set this for all ARM64, just like the above case, correct? And would this work with SWIOTLB? Also, do you think others would use it, or would I be adding code in the DMA API only because of one unusual PCIe host controller design? Keep in mind that although you didn't like the approach of V4 -- which intercepted DMA ops to make the appropriate mapping and was not compatible with SWIOTLB -- at least it kept the code restricted to oru driver. Thanks, Jim
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig index 8daa621..4394430 100644 --- a/drivers/pci/controller/Kconfig +++ b/drivers/pci/controller/Kconfig @@ -284,6 +284,7 @@ config PCIE_BRCMSTB depends on OF && PCI_MSI depends on SOC_BRCMSTB default ARCH_BRCMSTB || BMIPS_GENERIC + select ARCH_HAS_PHYS_TO_DMA if ARM64 help Say Y here to enable PCIe host controller support for Broadcom Settop Box SOCs. A Broadcom SOC will may have diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c index a805d87..ae9df8e 100644 --- a/drivers/pci/controller/pcie-brcmstb.c +++ b/drivers/pci/controller/pcie-brcmstb.c @@ -974,6 +974,18 @@ phys_addr_t brcm_dma_to_phys(struct device *dev, dma_addr_t dev_addr) return (phys_addr_t)dev_addr; } +#if defined(CONFIG_ARM64) +dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) +{ + return brcm_phys_to_dma(dev, paddr); +} + +phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr) +{ + return brcm_dma_to_phys(dev, dev_addr); +} +#endif + static int brcm_pcie_add_controller(struct brcm_pcie *pcie) { int i, ret = 0;
The BrcmSTB PCIe controller needs to remap DMA accesses to it because of the requirements of its interface with the SOC memory controllers. Signed-off-by: Jim Quinlan <jim2101024@gmail.com> --- drivers/pci/controller/Kconfig | 1 + drivers/pci/controller/pcie-brcmstb.c | 12 ++++++++++++ 2 files changed, 13 insertions(+)