| Message ID | 20250310-pci_fixup_addr-v10-5-409dafc950d1@nxp.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | PCI: Use device bus range info to cleanup RC Host/EP pci_fixup_addr() | expand |
On Mon, Mar 10, 2025 at 04:16:43PM -0400, Frank Li wrote: > parent_bus_offset in resource_entry can indicate address information just > ahead of PCIe controller. Most system's bus fabric use 1:1 map between > input and output address. but some hardware like i.MX8QXP doesn't use 1:1 > map. See below diagram: > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -478,6 +478,15 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) > bridge->ops = &dw_pcie_ops; > bridge->child_ops = &dw_child_pcie_ops; > > + /* > + * visconti_pcie_cpu_addr_fixup() use pp->io_base, > + * so have to call dw_pcie_init_parent_bus_offset() after init > + * pp->io_base. > + */ > + ret = dw_pcie_init_parent_bus_offset(pci, "config", pp->cfg0_base); > + if (ret) > + return ret; The ordering in dw_pcie_host_init() doesn't look right to me. We have this: dw_pcie_host_init dw_pcie_get_resources dw_pcie_cfg0_setup devm_pci_alloc_host_bridge win = resource_list_first_type(&bridge->windows, IORESOURCE_IO) pp->io_base = pci_pio_to_address(win->res->start) bridge->ops = ... bridge->child_ops = ... dw_pcie_init_parent_bus_offset pp->ops->init devm_pci_alloc_host_bridge() is generic, so it obviously can't depend on any dwc-specific things. I think the ordering should be more like this: dw_pcie_host_init devm_pci_alloc_host_bridge # generic dw_pcie_get_resources # dwc RP and EP dw_pcie_cfg0_setup win = resource_list_first_type(&bridge->windows, IORESOURCE_IO) pp->io_base = pci_pio_to_address(win->res->start) dw_pcie_init_parent_bus_offset bridge->ops = ... bridge->child_ops = ... pp->ops->init and everything in the second block (dw_pcie_cfg0_setup() through dw_pcie_init_parent_bus_offset()) is strictly DT-related resource setup and could all go in a dw_pcie_host_get_resources() or similar. > if (pp->ops->init) { > ret = pp->ops->init(pp); > if (ret) > > -- > 2.34.1 >
On Wed, Mar 12, 2025 at 04:37:57PM -0500, Bjorn Helgaas wrote: > On Mon, Mar 10, 2025 at 04:16:43PM -0400, Frank Li wrote: > > parent_bus_offset in resource_entry can indicate address information just > > ahead of PCIe controller. Most system's bus fabric use 1:1 map between > > input and output address. but some hardware like i.MX8QXP doesn't use 1:1 > > map. See below diagram: > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > > @@ -478,6 +478,15 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) > > bridge->ops = &dw_pcie_ops; > > bridge->child_ops = &dw_child_pcie_ops; > > > > + /* > > + * visconti_pcie_cpu_addr_fixup() use pp->io_base, > > + * so have to call dw_pcie_init_parent_bus_offset() after init > > + * pp->io_base. > > + */ > > + ret = dw_pcie_init_parent_bus_offset(pci, "config", pp->cfg0_base); > > + if (ret) > > + return ret; > > The ordering in dw_pcie_host_init() doesn't look right to me. We have > this: > > dw_pcie_host_init > dw_pcie_get_resources > dw_pcie_cfg0_setup > devm_pci_alloc_host_bridge > win = resource_list_first_type(&bridge->windows, IORESOURCE_IO) > pp->io_base = pci_pio_to_address(win->res->start) > bridge->ops = ... > bridge->child_ops = ... > dw_pcie_init_parent_bus_offset > pp->ops->init > > devm_pci_alloc_host_bridge() is generic, so it obviously can't depend > on any dwc-specific things. I think the ordering should be more like > this: > > dw_pcie_host_init > devm_pci_alloc_host_bridge # generic > dw_pcie_get_resources # dwc RP and EP > > dw_pcie_cfg0_setup > win = resource_list_first_type(&bridge->windows, IORESOURCE_IO) > pp->io_base = pci_pio_to_address(win->res->start) > dw_pcie_init_parent_bus_offset > > bridge->ops = ... > bridge->child_ops = ... > pp->ops->init > > and everything in the second block (dw_pcie_cfg0_setup() through > dw_pcie_init_parent_bus_offset()) is strictly DT-related resource > setup and could all go in a dw_pcie_host_get_resources() or similar. It is not related with these patch series. I can change it if you like. Frank > > > if (pp->ops->init) { > > ret = pp->ops->init(pp); > > if (ret) > > > > -- > > 2.34.1 > >
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c index c57831902686e..eaa6dd4c7edda 100644 --- a/drivers/pci/controller/dwc/pcie-designware-host.c +++ b/drivers/pci/controller/dwc/pcie-designware-host.c @@ -478,6 +478,15 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) bridge->ops = &dw_pcie_ops; bridge->child_ops = &dw_child_pcie_ops; + /* + * visconti_pcie_cpu_addr_fixup() use pp->io_base, + * so have to call dw_pcie_init_parent_bus_offset() after init + * pp->io_base. + */ + ret = dw_pcie_init_parent_bus_offset(pci, "config", pp->cfg0_base); + if (ret) + return ret; + if (pp->ops->init) { ret = pp->ops->init(pp); if (ret)
parent_bus_offset in resource_entry can indicate address information just ahead of PCIe controller. Most system's bus fabric use 1:1 map between input and output address. but some hardware like i.MX8QXP doesn't use 1:1 map. See below diagram: ┌─────────┐ ┌────────────┐ ┌─────┐ │ │ IA: 0x8ff8_0000 │ │ │ CPU ├───►│ ┌────►├─────────────────┐ │ PCI │ └─────┘ │ │ │ IA: 0x8ff0_0000 │ │ │ CPU Addr │ │ ┌─►├─────────────┐ │ │ Controller │ 0x7ff8_0000─┼───┘ │ │ │ │ │ │ │ │ │ │ │ │ │ PCI Addr 0x7ff0_0000─┼──────┘ │ │ └──► IOSpace ─┼────────────► │ │ │ │ │ 0 0x7000_0000─┼────────►├─────────┐ │ │ │ └─────────┘ │ └──────► CfgSpace ─┼────────────► BUS Fabric │ │ │ 0 │ │ │ └──────────► MemSpace ─┼────────────► IA: 0x8000_0000 │ │ 0x8000_0000 └────────────┘ bus@5f000000 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x80000000 0x0 0x70000000 0x10000000>; pcie@5f010000 { compatible = "fsl,imx8q-pcie"; reg = <0x5f010000 0x10000>, <0x8ff00000 0x80000>; reg-names = "dbi", "config"; #address-cells = <3>; #size-cells = <2>; device_type = "pci"; bus-range = <0x00 0xff>; ranges = <0x81000000 0 0x00000000 0x8ff80000 0 0x00010000>, <0x82000000 0 0x80000000 0x80000000 0 0x0ff00000>; ... }; }; Term Intermediate address (IA) here means the address just before PCIe controller. After ATU use this IA instead CPU address, cpu_addr_fixup() can be removed. Use reg-name "config" to detect parent_bus_addr_offset. Suppose the offset is the same for all kinds of address translation. Just set parent_bus_offset, but doesn't use it, so no functional change intended yet. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- change from v9 to v10 - call helper dw_pcie_init_parent_bus_offset() chagne from v8 to v9 - use resoure_entry parent_bus_offset to simple code logic - add check for use_parent_dt_ranges and cpu_addr_fixup to make sure only one set. Change from v7 to v8 - Add dev_warning_once at dw_pcie_iatu_detect() to reminder cpu_addr_fixup() user to correct their code - use 'use_parent_dt_ranges' control enable use dt parent bus node ranges. - rename dw_pcie_get_untranslate_addr to dw_pcie_get_parent_addr(). - of_property_read_reg() already have comments, so needn't add more. - return actual err code from function Change from v6 to v7 Add a resource_size_t parent_bus_addr local varible to fix 32bit build error. | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410291546.kvgEWJv7-lkp@intel.com/ Chagne from v5 to v6 -add comments for of_property_read_reg(). Change from v4 to v5 - remove confused 0x5f00_0000 range in sample dts. - reorder address at above diagram. Change from v3 to v4 - none Change from v2 to v3 - %s/cpu_untranslate_addr/parent_bus_addr/g - update diagram. - improve commit message. Change from v1 to v2 - update because patch1 change get untranslate address method. - add using_dtbus_info in case break back compatibility for exited platform. --- drivers/pci/controller/dwc/pcie-designware-host.c | 9 +++++++++ 1 file changed, 9 insertions(+)