From: Jim Quinlan <jim2101024@gmail.com> To: Christoph Hellwig <hch@lst.de> Cc: linux-kernel@vger.kernel.org, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Bjorn Helgaas <bhelgaas@google.com>, Brian Norris <computersforpeace@gmail.com>, Gregory Fong <gregory.0xf0@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>, linux-pci <linux-pci@vger.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v5 11/12] ARM64: add dma remap for BrcmSTB PCIe Date: Fri, 21 Sep 2018 14:29:45 -0400 [thread overview] Message-ID: <CANCKTBuk9KyabrL7u6RvCp4eu+3mT=9Dvo4wvo99KF6iKVwWRw@mail.gmail.com> (raw) In-Reply-To: <20180919144119.GB29096@lst.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: jim2101024@gmail.com (Jim Quinlan) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 11/12] ARM64: add dma remap for BrcmSTB PCIe Date: Fri, 21 Sep 2018 14:29:45 -0400 [thread overview] Message-ID: <CANCKTBuk9KyabrL7u6RvCp4eu+3mT=9Dvo4wvo99KF6iKVwWRw@mail.gmail.com> (raw) In-Reply-To: <20180919144119.GB29096@lst.de> 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
next prev parent reply other threads:[~2018-09-21 18:30 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-19 14:31 [PATCH v5 00/12] PCI: brcmstb: Add Broadcom Settopbox PCIe support (resend) Jim Quinlan 2018-09-19 14:31 ` [PATCH v5 01/12] soc: bcm: brcmstb: add memory API Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-19 14:31 ` [PATCH v5 02/12] dt-bindings: pci: add DT docs for Brcmstb PCIe device Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-20 9:06 ` Jonas Gorski 2018-09-20 9:06 ` Jonas Gorski 2018-09-20 9:06 ` Jonas Gorski 2018-09-21 18:00 ` Jim Quinlan 2018-09-21 18:00 ` Jim Quinlan 2018-09-21 18:00 ` Jim Quinlan 2018-09-19 14:31 ` [PATCH v5 03/12] PCI: brcmstb: add Broadcom STB PCIe host controller driver Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-19 14:31 ` [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-19 14:31 ` Jim Quinlan 2018-09-20 2:19 ` Ard Biesheuvel 2018-09-20 2:19 ` Ard Biesheuvel 2018-09-20 20:55 ` Florian Fainelli 2018-09-20 20:55 ` Florian Fainelli 2018-09-20 21:04 ` Ard Biesheuvel 2018-09-20 21:04 ` Ard Biesheuvel 2018-09-20 21:31 ` Florian Fainelli 2018-09-20 21:31 ` Florian Fainelli 2018-09-20 21:33 ` Ard Biesheuvel 2018-09-20 21:33 ` Ard Biesheuvel 2018-09-20 21:39 ` Florian Fainelli 2018-09-20 21:39 ` Florian Fainelli 2018-09-21 17:40 ` Jim Quinlan 2018-09-21 17:40 ` Jim Quinlan 2018-09-24 8:25 ` Ard Biesheuvel 2018-09-24 8:25 ` Ard Biesheuvel 2018-09-24 15:01 ` Jim Quinlan 2018-09-24 15:01 ` Jim Quinlan 2018-09-26 2:59 ` Florian Fainelli 2018-09-26 2:59 ` Florian Fainelli 2018-09-26 7:59 ` Ard Biesheuvel 2018-09-26 7:59 ` Ard Biesheuvel 2018-09-26 10:56 ` Robin Murphy 2018-09-26 10:56 ` Robin Murphy 2018-10-01 18:13 ` Florian Fainelli 2018-10-01 18:13 ` Florian Fainelli 2019-06-27 16:55 ` Stefan Wahren 2019-06-27 16:55 ` Stefan Wahren 2018-09-19 14:32 ` [PATCH v5 05/12] PCI: brcmstb: add MSI capability Jim Quinlan 2018-09-19 14:32 ` Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 06/12] MIPS: BMIPS: add dma remap for BrcmSTB PCIe Jim Quinlan 2018-09-26 22:07 ` Paul Burton 2018-09-26 22:07 ` Paul Burton 2018-09-28 21:48 ` Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 07/12] PCI/MSI: enable PCI_MSI_IRQ_DOMAIN support for MIPS Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 08/12] MIPS: BMIPS: add PCI bindings for 7425, 7435 Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 09/12] MIPS: BMIPS: enable PCI Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 10/12] ARM64: declare __phys_to_dma on ARCH_HAS_PHYS_TO_DMA Jim Quinlan 2018-09-19 14:32 ` Jim Quinlan 2018-09-19 14:37 ` Christoph Hellwig 2018-09-19 14:37 ` Christoph Hellwig 2018-09-19 14:32 ` [PATCH v5 11/12] ARM64: add dma remap for BrcmSTB PCIe Jim Quinlan 2018-09-19 14:32 ` Jim Quinlan 2018-09-19 14:32 ` Jim Quinlan 2018-09-19 14:41 ` Christoph Hellwig 2018-09-19 14:41 ` Christoph Hellwig 2018-09-19 14:41 ` Christoph Hellwig 2018-09-21 18:29 ` Jim Quinlan [this message] 2018-09-21 18:29 ` Jim Quinlan 2018-09-19 14:32 ` [PATCH v5 12/12] ARM: " Jim Quinlan 2018-09-19 14:32 ` Jim Quinlan 2019-03-20 23:15 ` [PATCH v5 00/12] PCI: brcmstb: Add Broadcom Settopbox PCIe support (resend) Bjorn Helgaas 2019-03-20 23:22 ` Florian Fainelli -- strict thread matches above, loose matches on Subject: below -- 2018-09-06 20:42 [PATCH v5 00/12] PCI: brcmstb: Add Broadcom Settopbox PCIe support Jim Quinlan 2018-09-06 20:43 ` [PATCH v5 11/12] ARM64: add dma remap for BrcmSTB PCIe Jim Quinlan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CANCKTBuk9KyabrL7u6RvCp4eu+3mT=9Dvo4wvo99KF6iKVwWRw@mail.gmail.com' \ --to=jim2101024@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bhelgaas@google.com \ --cc=computersforpeace@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=gregory.0xf0@gmail.com \ --cc=hch@lst.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.