Hi Bjorn, On 20:08 Mon 07 Oct , Bjorn Helgaas wrote: ... > It's common that PCI bus addresses are identical to CPU physical > addresses, but by no means universal. More details in > Documentation/core-api/dma-api-howto.rst > > > [2] I still think that the of_pci_set_address() function should be amended > > to avoid generating invalid 64 address when 32 bit flag is set. > > > > As you noted, fixing [2] will incidentally also let [1] work: I think > > we can try to solve [1] the proper way and maybe defer [2] for a separate > > patch. > > To solve [1] I've dropped this patch and tried to solve it from devicetree, > > modifying the following mapping: > > > > pcie@120000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>; > > > > so we now have a 1:1 64 bit mapping from 0x1f_00000000 to 0x1f_00000000. > > That's the wrong thing to change. pcie@120000 is fine; it's pci@0 > that's incorrect. > > pcie@120000 is the host bridge, and its "ranges" must describe the > address translation it performs between the primary (CPU) side and the > secondary (PCI) side. Either this offset is built into the hardware > and can't be changed, or the offset is configured by firmware and the > DT has to match. > > So I think this description is correct: > > pcie@120000: <0x2000000 0x0 0x00000000 0x1f 0x00000000 0x0 0xfffffffc>; > > which means we have an aperture from CPU physical addresses to PCI bus > addresses like this: > > Host bridge: [mem 0x1f_00000000-0x1f_fffffffb window] (bus address 0x00000000-0xfffffffb) > > > I thought it would result in something like this: > > > > pcie@120000: <0x3000000 0x1f 0x00 0x1f 0x00 0x00 0xfffffffc>; > > pci@0 : <0x82000000 0x1f 0x00 0x82000000 0x1f 0x00 0x00 0x600000>; > > dev@0,0 : <0x01 0x00 0x00 0x82010000 0x1f 0x00 0x00 0x400000>; > > rp1@0 : <0xc0 0x40000000 0x01 0x00 0x00 0x00 0x400000>; > > > > but it fails instead (err: "can't assign; no space") in pci_assign_resource() > > function trying to match the size using pci_clip_resource_to_region(). It turned > > out that the clipping is done against 32 bit memory region 'pci_32_bit',and > > this is failing because the original region addresses to be clipped wxxiereas 64 > > bit wide. The 'culprit' seems to be the function devm_of_pci_get_host_bridge_resources() > > dropping IORESOURCE_MEM_64 on any memory resource, which seems to be a change > > somewhat specific to a RK3399 case (see commit 3bd6b8271ee66), but I'm not sure > > whether it can be considered generic. > > I think the problem is that we're building the pci@0 (Root Port) > "ranges" incorrectly. pci@0 is a PCI-PCI bridge, which cannot do any > address translation, so its parent and child address spaces must both > be inside the pcie@120000 *child* address space. > > > Also, while taking a look at the resulting devicetree, I'm a bit confused by the > > fact that the parent address generated by of_pci_prop_ranges() for the pci@0,0 > > bridge seems to be taken from the parent address of the pcie@120000 node. Shouldn't > > it be taken from the child address of pcie@120000, instead? > > Yes, this is exactly the problem. The pci@0 parent and child > addresses in "ranges" are both in the PCI address space. But we > start with pdev->resource[N], which is a CPU address. To get the PCI > address, we need to apply pci_bus_address(). If the host bridge > windows are set up correctly, the window->offset used in > pcibios_resource_to_bus() should yield the PCI bus address. You mean something like this, I think: @@ -129,7 +129,7 @@ static int of_pci_prop_ranges(struct pci_dev *pdev, struct of_changeset *ocs, if (of_pci_get_addr_flags(&res[j], &flags)) continue; - val64 = res[j].start; + val64 = pci_bus_address(pdev, &res[j] - pdev->resource); of_pci_set_address(pdev, rp[i].parent_addr, val64, 0, flags, false); if (pci_is_bridge(pdev)) { > > I think it should look like this: > > pci@0: <0x82000000 0x0 0x00000000 0x82000000 0x0 0x00000000 0x0 0x600000>; indeed, with the above patch applied, the result is exactly as you expected. > > By default lspci shows you the CPU addresses for BARs, so you should > see something like this: > > 00:02.0 PCI bridge > Memory behind bridge: 1f00000000-1ffffffffb > Capabilities: [40] Express Root Port > > If you run "lspci -b", it will show you PCI bus addresses instead, > which should look like this: > > 00:02.0 PCI bridge > Memory behind bridge: 00000000-fffffffb > Capabilities: [40] Express Root Port > > > > But I don't think it works in general because there's no requirement > > > that the host bridge address translation be that simple. For example, > > > if we have two host bridges, and we want each to have 2GB of 32-bit > > > PCI address space starting at 0x0, it might look like this: > > > > > > 0x00000002_00000000 -> PCI 0x00000000 (subtract 0x00000002_00000000) > > > 0x00000002_80000000 -> PCI 0x00000000 (subtract 0x00000002_80000000) > > > > > > In this case simply ignoring the high 32 bits of the CPU address isn't > > > the correct translation for the second host bridge. I think we should > > > look at each host bridge's "ranges", find the difference between its > > > parent and child addresses, and apply the same difference to > > > everything below that bridge. > > > > Not sure I've got this scenario straight: can you please provide the topology > > and the bit setting (32/64 bit) for those ranges? Also, is this scenario coming > > from a real use case or is it hypothetical? > > This scenario is purely hypothetical, but it's a legal topology that > we should handle correctly. It's two host bridges, with independent > PCI hierarchies below them: > > Host bridge A: [mem 0x2_00000000-0x2_7fffffff window] (bus address 0x00000000-0x7fffffff) > Host bridge B: [mem 0x2_80000000-0x2_ffffffff window] (bus address 0x00000000-0x7fffffff) > > Bridge A has an MMIO aperture at CPU addresses > 0x2_00000000-0x2_7fffffff, and when it initiates PCI transactions on > its secondary side, the PCI address is CPU_addr - 0x2_00000000. > > Similarly, bridge B has an MMIO aperture at CPU addresses > 0x2_80000000-0x2_ffffffff, and when it initiates PCI transactions on > its secondary side, the PCI address is CPU_addr - 0x2_80000000. > > Both hierarchies use PCI bus addresses in the 0x00000000-0x7fffffff > range. In a topology like this, you can't convert a bus address back > to a CPU address unless you know which hierarchy it's in. > pcibios_bus_to_resource() takes a pci_bus pointer, which tells you > which hierarchy (and which host bridge address translation) to use. Agreed. While I think about how to adjust that specific patch,i let's drop it from this patchset since the aforementioned change is properly fixing the translation issue. > > Bjora Many thanks, Andrea