linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Lizhi Hou <lizhi.hou@xilinx.com>
Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, yilun.xu@intel.com, maxz@xilinx.com,
	sonal.santan@xilinx.com, yliu@xilinx.com,
	michal.simek@xilinx.com, stefanos@xilinx.com, trix@redhat.com,
	mdf@kernel.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 RESEND 0/4] Infrastructure to define apertures in a PCIe device with a flattened device tree
Date: Thu, 10 Mar 2022 13:27:04 -0600	[thread overview]
Message-ID: <20220310192704.GA168467@bhelgaas> (raw)
In-Reply-To: <20220305052304.726050-1-lizhi.hou@xilinx.com>

On Fri, Mar 04, 2022 at 09:23:00PM -0800, Lizhi Hou wrote:
> Hello,

Why is this a resend?  I see
https://lore.kernel.org/r/20220305051105.725838-1-lizhi.hou@xilinx.com,
which looks like it was posted just a few minutes before this.  I
assume this "RESEND" is identical?

> This V1 of patch series is to provide the required pci OF interfaces for
> the PCIe device which uses flattened device tree to describe apertures in
> its PCIe BARs. e.g, Xilinx Alveo PCIe accelerator. This requires a base
> device tree which contains nodes for PCIe devices. A PCIe device driver
> can then overlay a flattened device tree on the PCIe device tree node.
> There are two separate parts for this to work. First, not all system has
> a base device tree created by default. Thus, a patch to create an empty
> device tree root node has been submitted.
>   https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xilinx.com/
> Second, PCIe is self discoverable bus and there might not be a device tree
> node created for PCIe device. This patch provides a new interface to create
> a ‘pci-ep-bus’ node under the base device tree root node. PCIe device
> driver may call this interface in its probe routine to create device tree
> node, then overlays its device tree to the node.
> For the overlayed device tree nodes, each node presents a hardware aperture
> implemented in its PCIe BARs. The aperture register address consists of BAR
> index and offset. It uses the following encoding:
>   0xIooooooo 0xoooooooo
> Where:
>   I = BAR index
>   ooooooo oooooooo = BAR offset
> The ‘pci-ep-bus’ node been created is compatible with ‘simple-bus’ and
> contains ‘ranges’ property for translating aperture address to CPU address.
> The last patch enhances of_overlay_fdt_apply(). The ‘pci-ep-bus’ device
> node is created dynamically. The flattened device tree may not specify an
> fixed target overlay path in front. Instead, a relative path to the
> ‘pci-ep-bus’ node is specified in the flattened tree. Thus, a new
> parameter is added to point the target base node which is ‘pci-ep-bus’
> node in this case. Then the entire overlay target path is target base node
> path plus the relative path specified in the flattened device tree.

s/pci/PCI/ (capitalize acronyms above, also in other subjects, commit
logs, and code comments)

s/PCIe/PCI/ (in most cases, the above is not PCIe-specific)

Please add blank lines between paragraphs to make this easier to read.

The above tells *what* this series does, but not *why* we need it.

Apparently you want to describe PCI BARs in DT.  Normally the PCI core
discovers devices and BARs using the PCI enumeration process (read
config space looking for a Device ID, read standard BAR locations
(unimplemented BARs are hardwired to zero)).  Obviously you know all
of this.  What we need here (and in the commit log for the relevant
patch) is some explanation about why this standard process doesn't
work and you need to do something via DT.

I'm guessing this is for the case where Linux is running *on* the
endpoint, so instead of enumerating devices from the perspective of a
PCI host controller, it's on the "other" side of the device, e.g., as
described in Documentation/PCI/endpoint/pci-endpoint.rst

So the commit log should mention that and explain why we need this new
DT support.  The endpoint support has been around for a while, so this
should explain what's different about Xilinx Alveo and why it needs
this new stuff.

Bjorn

      parent reply	other threads:[~2022-03-10 19:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-05  5:23 [PATCH V1 RESEND 0/4] Infrastructure to define apertures in a PCIe device with a flattened device tree Lizhi Hou
2022-03-05  5:23 ` [PATCH V1 RESEND 1/4] pci: add interface to create pci-ep device tree node Lizhi Hou
2022-03-10 10:02   ` Dan Carpenter
2022-03-10 19:34   ` Bjorn Helgaas
2022-06-21 15:12   ` Manivannan Sadhasivam
2022-03-05  5:23 ` [PATCH V1 RESEND 2/4] Documentation: devicetree: bindings: add binding for PCIe endpoint bus Lizhi Hou
2022-03-06 15:37   ` Tom Rix
2022-03-07 14:07     ` Rob Herring
2022-04-22 21:57       ` Lizhi Hou
2022-05-13 15:19         ` Lizhi Hou
2022-06-21 15:06   ` Manivannan Sadhasivam
2022-03-05  5:23 ` [PATCH V1 RESEND 3/4] fpga: xrt: management physical function driver Lizhi Hou
2022-06-21 15:16   ` Manivannan Sadhasivam
2022-03-05  5:23 ` [PATCH V1 RESEND 4/4] of: enhance overlay applying interface to specific target base node Lizhi Hou
2022-03-10 20:07   ` Rob Herring
2022-03-10 19:27 ` Bjorn Helgaas [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=20220310192704.GA168467@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lizhi.hou@xilinx.com \
    --cc=maxz@xilinx.com \
    --cc=mdf@kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=robh@kernel.org \
    --cc=sonal.santan@xilinx.com \
    --cc=stefanos@xilinx.com \
    --cc=trix@redhat.com \
    --cc=yilun.xu@intel.com \
    --cc=yliu@xilinx.com \
    /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;
as well as URLs for NNTP newsgroup(s).