public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@nxp.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Rob Herring" <robh@kernel.org>,
	"Saravana Kannan" <saravanak@google.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Richard Zhu" <hongxing.zhu@nxp.com>,
	"Lucas Stach" <l.stach@pengutronix.de>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabio Estevam" <festevam@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	imx@lists.linux.dev
Subject: Re: [PATCH v8 3/7] PCI: dwc: ep: Add bus_addr_base for outbound window
Date: Thu, 16 Jan 2025 15:02:44 -0500	[thread overview]
Message-ID: <Z4ll5Ktyh5kmTzsd@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <20250116194558.GA595994@bhelgaas>

On Thu, Jan 16, 2025 at 01:45:58PM -0600, Bjorn Helgaas wrote:
> On Thu, Jan 16, 2025 at 01:04:16PM -0500, Frank Li wrote:
> > On Thu, Jan 16, 2025 at 09:32:39AM -0600, Bjorn Helgaas wrote:
> > > On Tue, Nov 19, 2024 at 02:44:21PM -0500, Frank Li wrote:
> > > >                    Endpoint
> > > >   ┌───────────────────────────────────────────────┐
> > > >   │                             pcie-ep@5f010000  │
> > > >   │                             ┌────────────────┐│
> > > >   │                             │   Endpoint     ││
> > > >   │                             │   PCIe         ││
> > > >   │                             │   Controller   ││
> > > >   │           bus@5f000000      │                ││
> > > >   │           ┌──────────┐      │                ││
> > > >   │           │          │ Outbound Transfer     ││
> > > >   │┌─────┐    │  Bus     ┼─────►│ ATU  ──────────┬┬─────►
> > > >   ││     │    │  Fabric  │Bus   │                ││PCI Addr
> > > >   ││ CPU ├───►│          │Addr  │                ││0xA000_0000
> > > >   ││     │CPU │          │0x8000_0000            ││
> > > >   │└─────┘Addr└──────────┘      │                ││
> > > >   │       0x7000_0000           └────────────────┘│
> > > >   └───────────────────────────────────────────────┘
> > > >
> > > > Use 'ranges' property in DT to configure the iATU outbound window address.
> > > > The bus fabric generally passes the same address to the PCIe EP controller,
> > > > but some bus fabrics map the address before sending it to the PCIe EP
> > > > controller.
> > > >
> > > > Above diagram, CPU write data to outbound windows address 0x7000_0000, Bus
> > > > fabric map it to 0x8000_0000. ATU should use bus address 0x8000_0000 as
> > > > input address and map to PCI address 0xA000_0000.
> > > >
> > > > Previously, 'cpu_addr_fixup()' was used to handle address conversion. Now,
> > > > the device tree provides this information, preferring a common method.
> > > >
> > > > bus@5f000000 {
> > > > 	compatible = "simple-bus";
> > > > 	ranges = <0x80000000 0x0 0x70000000 0x10000000>;
> > > >
> > > > 	pcie-ep@5f010000 {
> > > > 		reg = <0x80000000 0x10000000>;
> > > > 		reg-names ="addr_space";
> > > > 		...
> > > > 	};
> > > > 	...
> > > > };
> > > >
> > > > 'ranges' in bus@5f000000 descript how address map from CPU address to bus
> > > > address.
> > >
> > > Shouldn't there also be a pcie-ep@5f010000 'ranges' property to
> > > describe the translation for the window from bus addr 0x8000_0000 to
> > > PCI addr 0xA000_0000?
> >
> > Needn't 'ranges' under pcie-ep@5f010000 because history reason. DWC use
> > reg-names "addr_space" descript outbound windows space.
>
> If reg-name "addr_space" is used instead of 'ranges' for some
> historical reason, we should mention that in the commit log so people
> don't assume that this difference is the way it's *supposed* to be
> done.

How about add comments after

reg-names ="addr_space"; // Indicate EP outbound windows space instead use
ranges by histortical reason.

>
> I only see "addr_space" mentioned in
> Documentation/devicetree/bindings/pci/*-ep.yaml, so I assume
> this "addr_space" usage only applies to endpoints?

Yes, "addr_space" usage only applies to endpoints.

>
> > > > Use `of_property_read_reg()` to obtain the bus address and set it to the
> > > > ATU correctly, eliminating the need for vendor-specific cpu_addr_fixup().
> > >
> > > Why is this different from [1], where parent_bus_addr comes from the
> > > 'ranges' property?  Isn't this the same exact kind of address
> > > translation for both RC and EP mode?
> >
> > The method is the same, but space means is difference.
> >
> > RC side:
> >    regs, 1: controller register, 2: config space, (although it should be
> > in ranges)
> >    ranges, (IO range and Memory range).
> >
> > EP side:
> >    regs, 1: controller register, 2: outbound windows space.("addr_space")
> >
> > All regs need call of_property_read_reg() to get untranslated address.
> > ranges:  use "parent_bus_addr" in [1].
>
> I think we should at least use the same name ("parent_bus_addr", not
> "bus_addr_base") and probably also figure out a wrapper or similar way
> to use 'ranges' for future endpoint drivers and fall back to
> "addr_space" for DWC.

Okay for name parent_bus_addr.
Do you need me to respin it? Or you change it by yourself?

Frank

>
> > > [1] https://lore.kernel.org/r/20241119-pci_fixup_addr-v8-1-c4bfa5193288@nxp.com
>
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > > @@ -410,6 +410,7 @@ struct dw_pcie_ep {
> > > >  	struct list_head	func_list;
> > > >  	const struct dw_pcie_ep_ops *ops;
> > > >  	phys_addr_t		phys_base;
> > > > +	u64			bus_addr_base;
> > > >  	size_t			addr_size;
> > > >  	size_t			page_size;
> > > >  	u8			bar_to_atu[PCI_STD_NUM_BARS];

  reply	other threads:[~2025-01-16 20:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19 19:44 [PATCH v8 0/7] PCI: dwc: opitimaze RC Host/EP pci_fixup_addr() Frank Li
2024-11-19 19:44 ` [PATCH v8 1/7] of: address: Add parent_bus_addr to struct of_pci_range Frank Li
2024-11-19 19:44 ` [PATCH v8 2/7] PCI: dwc: Use devicetree 'ranges' property to get rid of cpu_addr_fixup() callback Frank Li
2024-11-24 14:33   ` Manivannan Sadhasivam
2025-01-16  1:47     ` Krzysztof Wilczyński
2025-01-16  1:56       ` Frank Li
2025-01-16 23:13   ` Bjorn Helgaas
2025-01-16 23:29     ` Bjorn Helgaas
2025-01-17 15:42       ` Frank Li
2025-01-23 15:21         ` Frank Li
2025-01-23 19:04           ` Bjorn Helgaas
2025-01-23 19:15             ` Frank Li
2025-01-27 15:24               ` Niklas Cassel
2025-01-23 19:09         ` Bjorn Helgaas
2025-01-17 15:50     ` Frank Li
2024-11-19 19:44 ` [PATCH v8 3/7] PCI: dwc: ep: Add bus_addr_base for outbound window Frank Li
2025-01-16 15:32   ` Bjorn Helgaas
2025-01-16 18:04     ` Frank Li
2025-01-16 19:45       ` Bjorn Helgaas
2025-01-16 20:02         ` Frank Li [this message]
2025-01-16 22:49           ` Bjorn Helgaas
2025-01-17 14:35             ` Manivannan Sadhasivam
2025-01-17 15:17               ` Frank Li
2024-11-19 19:44 ` [PATCH v8 4/7] PCI: imx6: Remove cpu_addr_fixup() Frank Li
2024-11-19 19:44 ` [PATCH v8 5/7] dt-bindings: PCI: fsl,imx6q-pcie-ep: Add compatible string fsl,imx8q-pcie-ep Frank Li
2024-11-19 19:44 ` [PATCH v8 6/7] PCI: imx6: Pass correct sub mode when calling phy_set_mode_ext() Frank Li
2024-11-19 19:44 ` [PATCH v8 7/7] PCI: imx6: Add i.MX8Q PCIe Endpoint (EP) support Frank Li
2024-11-24 14:38 ` [PATCH v8 0/7] PCI: dwc: opitimaze RC Host/EP pci_fixup_addr() Manivannan Sadhasivam
2024-12-10 22:16   ` Frank Li
2024-12-19 19:55     ` Frank Li
2025-01-06 17:14       ` Frank Li
2025-01-07 17:59         ` Frank Li
2025-01-16  1:56         ` Krzysztof Wilczyński
2025-01-15 11:42 ` Krzysztof Wilczyński

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=Z4ll5Ktyh5kmTzsd@lizhi-Precision-Tower-5810 \
    --to=frank.li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=hongxing.zhu@nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=jingoohan1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=saravanak@google.com \
    --cc=shawnguo@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox