On Fri, Jul 29, 2022 at 06:33:45AM -0500, Bjorn Helgaas wrote: > On Fri, Jul 29, 2022 at 07:52:20AM +0300, Serge Semin wrote: > > On Thu, Jul 28, 2022 at 05:11:20PM -0500, Bjorn Helgaas wrote: > > > On Fri, Jun 24, 2022 at 05:39:47PM +0300, Serge Semin wrote: > > > > In accordance with the generic PCIe Root Port DT-bindings the "dma-ranges" > > > > property has the same format as the "ranges" property. The only difference > > > > is in their semantics. The "dma-ranges" property describes the PCIe-to-CPU > > > > memory mapping in opposite to the CPU-to-PCIe mapping of the "ranges" > > > > property. Even though the DW PCIe controllers are normally equipped with > > > > the internal Address Translation Unit which inbound and outbound tables > > > > can be used to implement both properties semantics, it was surprising for > > > > me to discover that the host-related part of the DW PCIe driver currently > > > > supports the "ranges" property only while the "dma-ranges" windows are > > > > just ignored. Having the "dma-ranges" supported in the driver would be > > > > very handy for the platforms, that don't tolerate the 1:1 CPU-PCIe memory > > > > mapping and require a customized PCIe memory layout. So let's fix that by > > > > introducing the "dma-ranges" property support. > > > > > Do we have a platform that requires this yet? Or does this fix a bug? > > > > > > I see that dw_pcie_host_init() calls devm_pci_alloc_host_bridge(), > > > which eventually parses "dma-ranges", but I don't see any DWC DT > > > bindings that use it yet. > > > > > > I'm not clear on what value this adds today. > > > > There are several points of having this supported. > > First of all, generic PCIe DT-bindings permit having the dma-ranges > > specified for the PCIe RCs. If so having it unsupported by the driver > > just breaks the bindings or at least makes it incomplete. > > Are there bindings in the tree that are broken and will be fixed by > this? Shortly speaking: explicitly none of them are broken, but implicitly most of them are broken.) As I said the generic DT-bindings permit having the dma-ranges property specified for the PCIe RCs: Link: https://github.com/robherring/dt-schema/blob/master/schemas/pci/pci-bus.yaml#L47 So all the PCIe RC bindings can be equipped with the dma-ranges property. At least dtschema check tool won't print any error if the property is specified for any of the currently available PCIe RC device including DW PCIe RC. But if the dma-ranges aren't supported by the driver having it specified won't give any expected effect. In case of the DW PCIe RC device setting the dma-ranges property up won't change anything because without this patch the dma-ranges won't be accordingly translated to the inbound iATU settings. > > > Second, the main point of this patchset is to add the dma-ranges > > support.) Especially seeing some other PCIe RC drivers do have it > > supported too. > > Finally. It is required for our platform (and for all the platforms > > with similar issues). The problem is that the outbound source window > > base address (on CPU-side) is size-unaligned. It resides at the 128MB > > base address (size is somewhat about ~335MB). In case of the > > one-on-one CPU->PCI mapping the peripherals with relatively big BARs > > (at least of 256MB) and which need the BARs having size-aligned memory > > won't be supported. So we had to remap the PCIe space to the > > size-aligned base address. But in its turn that caused the PCIe-CPU > > memory overlap. So PCIe DMA stopped working for the overlapped memory > > due to the implicit P2P transactions. In order to fix that we had to > > add the dma-ranges support to the DW PCIe driver and use it to remap > > the overlapped memory. So please add this patch to the repo. We really > > need it. > > Does the above apply to the pending Baikal-T1 driver? The problem described above is indeed specific to the Baikal-T1 platform. > If so, let's > just include this patch in that series. Then we'll have a user of > this functionality and we'll be able to exercise and test this code. Basically it can be tested out on any platform, not only on ours. You don't even need to have the problem described above. All you need is a DW PCIe RC-device with the inbound iATU windows support, this patch and a dts file with the dma-ranges specified for the corresponding DT device node. Secondly even if you do move this patch to that series it likely won't be tested by anyone but me, which I and our customer have already done many times here. By postponing the patch merge in you'll just postpone the feature being utilized by the rest of the kernel users and nothing else. I am sure it's working at least in our case. Let's add it to the kernel on this cycle so in case of unexpected problems they could be fixed in the next rc-stages. -Sergey > > Bjorn
