public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Frank Li <Frank.li@nxp.com>
To: Rob Herring <robh@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Abraham I" <kishon@kernel.org>,
	"Saravana Kannan" <saravanak@google.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
	"Jesper Nilsson" <jesper.nilsson@axis.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>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-kernel@axis.com,
	linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>
Subject: Re: [PATCH 0/9] PCI-EP: Add 'ranges' support for PCI endpoint devices
Date: Mon, 23 Sep 2024 15:02:33 -0400	[thread overview]
Message-ID: <ZvG7SXfxhlu684OP@lizhi-Precision-Tower-5810> (raw)
In-Reply-To: <ZvGT4+UaPOmnGh4M@lizhi-Precision-Tower-5810>

On Mon, Sep 23, 2024 at 12:14:27PM -0400, Frank Li wrote:
> On Sat, Sep 21, 2024 at 03:18:50PM -0400, Frank Li wrote:
> > On Sat, Sep 21, 2024 at 09:43:17AM -0500, Rob Herring wrote:
> > > On Thu, Sep 19, 2024 at 5:03 PM Frank Li <Frank.Li@nxp.com> wrote:
> > > >
> > > > The PCI bus device tree supports 'ranges' properties that indicate
> > > > how to convert PCI addresses to CPU addresses. Many PCI controllers
> > > > are dual-role controllers, supporting both Root Complex (RC) and
> > > > Endpoint (EP) modes. The EP side also needs similar information for
> > > > proper address translation.
> > > >
> > > > This commit introduces several changes to add 'ranges' support for
> > > > PCI endpoint devices:
> > > >
> > > > 1. **Modify of_address.c**: Add support for the new `device_type`
> > > >    "pci-ep", enabling it to parse 'ranges' using the same functions
> > > >    as for PCI devices.
> > > >
> > > > 2. **Update DesignWare PCIe EP driver**: Enhance the driver to
> > > >    support 'ranges' when 'addr_space' is missing, maintaining
> > > >    compatibility with existing drivers.
> > > >
> > > > 3. **Update binding documentation**: Modify the device tree bindings
> > > >    to include 'ranges' support and make 'addr_space' an optional
> > > >    entry in 'reg-names'.
> > > >
> > > > 4. **Add i.MX8QXP EP support**: Incorporate support for the
> > > >    i.MX8QXP PCIe EP in the driver.
> > > >
> > > > i.MX8QXP PCIe dts is upstreaming.  Below is pcie-ep part.
> > > >
> > > > pcieb_ep: pcie-ep@5f010000 {
> > > >                 compatible = "fsl,imx8q-pcie-ep";
> > > >                 reg = <0x5f010000 0x00010000>;
> > > >                 reg-names = "dbi";
> > > >                 #address-cells = <3>;
> > > >                 #size-cells = <2>;
> > > >                 device_type = "pci-ep";
> > > >                 ranges = <0x82000000 0 0x80000000 0x70000000 0 0x10000000>;
> > >
> > > How does a PCI endpoint set PCI addresses? Those get assigned by the
> > > PCI host system. They can't be static in DT.
> >
> > PCI address is set by other channel, such as RC write some place in bar0.
> >
> > It indicates EP side outbound windows mapping. See below detail.
> >
> >
> >                                   Endpoint          Root complex
> >                                  ┌───────┐        ┌─────────┐
> >                    ┌─────┐       │ EP    │        │         │      ┌─────┐
> >                    │     │       │ Ctrl  │        │         │      │ CPU │
> >                    │ DDR │       │       │        │ ┌────┐  │      └──┬──┘
> >                    │     │◄──────┼─ATU ◄─┼────────┼─┤BarN│◄─┼─────────┘
> >                    │     │       │       │        │ └────┘  │ Outbound Transfer
> >                    └─────┘       │       │        │         │
> >                                  │       │        │         │
> >                                  │       │        │         │
> >                                  │       │        │         │ Inbound Transfer
> >                                  │       │        │         │      ┌──▼──┐
> >                   ┌───────┐      │       │        │ ┌───────┼─────►│DDR  │
> >                   │       │ outbound Transfer*    │ │       │      └─────┘
> >        ┌─────┐    │ Bus   ┼─────►│ ATU  ─┬────────┼─┘       │
> >        │     │    │ Fabric│Bus   │       │ PCI Addr         │
> >        │ CPU ├───►│       │Addr  │       │ 0xA000_0000      │
> >        │     │CPU │       │0x8000_0000   │        │         │
> >        └─────┘Addr└───────┘      │       │        │         │
> >               0x7000_0000        └───────┘        └─────────┘
> >
> >
> > This ranges descript above diagram Endpoint outbound Transfer*'s
> > information. There are address space (previous use addr_space in reg-name)
> > indicate such informaiton, such as [0x7000_00000, 0xB000_0000] as PCI EP
> > outbound windows. when cpu write 0x7000_0000, data will write to EP ctrl,
> > the ATU in EP ctrl convert to PCI address such 0xA000,0000, then write
> > to RC's DDR>
> >
> > The PCI Addr 0xA000_0000 information was sent to EP driver by use other
> > channel, such as RC write it some place in Bar0.
> >
> > The 'range' here indicated EP side's outbound windows information. Most
> > system CPU address is the same as bus address. but in imx8q, it is
> > difference. Bus fabric convert 0x7000_0000 to 0x8000_00000.
> >
> > So need range indicate such address convertion.
> >
> > >
> > > If you need the PCI address, just read your BAR registers.
> > >
> > > In general, why do you need this when none of the other PCI endpoint
> > > drivers have needed this?
> >
> > Most system, the address is the same. Some system convert is simple, just
> > cut some high address bit, so their driver hardcode it. Maybe imx8QM have
> > first one, they have more than one controller and address map is not
> > such simple.
> >
> > We use customer dt property in downstream kernel, but I think common
> > solution should be better, other drivers can remove their hardcode in
> > future. And it will be more symmetry with PCI host side's property.
>
> I found a more simple the method, will post v2 soon.

V2 post at https://lore.kernel.org/imx/20240923-pcie_ep_range-v2-0-78d2ea434d9f@nxp.com/T/#t
, which more simple and reasonable.

Frank

>
> Frank
>
> >
> > Frank
> > >
> > > Rob


      reply	other threads:[~2024-09-23 19:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-19 22:03 [PATCH 0/9] PCI-EP: Add 'ranges' support for PCI endpoint devices Frank Li
2024-09-19 22:03 ` [PATCH 1/9] dt-bindings: PCI: pci-ep: Document 'ranges' property Frank Li
2024-09-19 22:03 ` [PATCH 2/9] of: address: Add argument 'name' for of_node_is_pcie() Frank Li
2024-09-19 22:03 ` [PATCH 3/9] of: address: Add device type pci-ep Frank Li
2024-09-19 22:03 ` [PATCH 4/9] dt-bindings: PCI: snps,dw-pcie-ep: 'addr_space' not required if 'ranges' present Frank Li
2024-09-19 22:03 ` [PATCH 5/9] PCI: dwc: ep: Replace phys_base and addr_size with range Frank Li
2024-09-19 22:03 ` [PATCH 6/9] PCI: dwc: ep: Use 'ranges' from DT if 'addr_space' is missing Frank Li
2024-09-19 22:03 ` [PATCH 7/9] dt-bindings: PCI: fsl,imx6q-pcie-ep: Add compatible string fsl,imx8q-pcie-ep Frank Li
2024-09-19 22:03 ` [PATCH 8/9] PCI: imx6: Pass correct sub mode when calling phy_set_mode_ext() Frank Li
2024-09-19 22:03 ` [PATCH 9/9] PCI: imx6: Add i.MX8Q PCIe Endpoint (EP) support Frank Li
2024-09-21 14:43 ` [PATCH 0/9] PCI-EP: Add 'ranges' support for PCI endpoint devices Rob Herring
2024-09-21 19:18   ` Frank Li
2024-09-23 16:14     ` Frank Li
2024-09-23 19:02       ` Frank Li [this message]

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=ZvG7SXfxhlu684OP@lizhi-Precision-Tower-5810 \
    --to=frank.li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=hongxing.zhu@nxp.com \
    --cc=imx@lists.linux.dev \
    --cc=jesper.nilsson@axis.com \
    --cc=jingoohan1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kw@linux.com \
    --cc=kwilczynski@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@axis.com \
    --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