linux-fpga.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sonal Santan <sonals@xilinx.com>
To: Rob Herring <robh@kernel.org>
Cc: Lizhi Hou <lizhih@xilinx.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
	Max Zhen <maxz@xilinx.com>, Yu Liu <yliu@xilinx.com>,
	Michal Simek <michals@xilinx.com>,
	Stefano Stabellini <stefanos@xilinx.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"trix@redhat.com" <trix@redhat.com>,
	Moritz Fischer <mdf@kernel.org>, Xu Yilun <yilun.xu@intel.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH V9 XRT Alveo 01/14] Documentation: fpga: Add a document describing XRT Alveo drivers
Date: Fri, 22 Oct 2021 04:36:36 +0000	[thread overview]
Message-ID: <SJ0PR02MB8845B91BA06D0444D9466B4FBB809@SJ0PR02MB8845.namprd02.prod.outlook.com> (raw)
In-Reply-To: <CAL_JsqJfyRymB=VxLuQqLpep+Q1Eie48dobv9sC5OizDz0d2DQ@mail.gmail.com>

Thanks for your suggestions and pointers. 

We will look into creating a generic patchset for attaching a device tree for PCIe use case. Will then refactor the XRT Alveo driver to use this new infrastructure.

-Sonal

________________________________________
From: Rob Herring <robh@kernel.org>
Sent: Thursday, October 21, 2021 10:38 AM
To: Sonal Santan
Cc: Lizhi Hou; linux-kernel@vger.kernel.org; linux-fpga@vger.kernel.org; Max Zhen; Yu Liu; Michal Simek; Stefano Stabellini; devicetree@vger.kernel.org; trix@redhat.com; Moritz Fischer; Xu Yilun; David Woodhouse
Subject: Re: [PATCH V9 XRT Alveo 01/14] Documentation: fpga: Add a document describing XRT Alveo drivers

On Thu, Oct 21, 2021 at 12:36 AM Sonal Santan <sonals@xilinx.com> wrote:
>
> Hello Rob,
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: Tuesday, October 19, 2021 6:03 AM
> > To: Lizhi Hou <lizhih@xilinx.com>
> > Cc: linux-kernel@vger.kernel.org; linux-fpga@vger.kernel.org; Max Zhen
> > <maxz@xilinx.com>; Sonal Santan <sonals@xilinx.com>; Yu Liu
> > <yliu@xilinx.com>; Michal Simek <michals@xilinx.com>; Stefano Stabellini
> > <stefanos@xilinx.com>; devicetree@vger.kernel.org; trix@redhat.com; Moritz
> > Fischer <mdf@kernel.org>; Max Zhen <maxz@xilinx.com>; Xu Yilun
> > <yilun.xu@intel.com>
> > Subject: Re: [PATCH V9 XRT Alveo 01/14] Documentation: fpga: Add a
> > document describing XRT Alveo drivers
> >
> > On Thu, Oct 14, 2021 at 11:12 AM Lizhi Hou <lizhi.hou@xilinx.com> wrote:
> > >
> > > Hello Rob,
> > >
> > > Please help with the review of the proposed FDT usage by Alveo/XRT drivers.
> > >
> > > Thanks,
> > > Lizhi
> > >
> > > On 10/13/21 7:21 PM, Xu Yilun wrote:
> > > > CAUTION: This message has originated from an External Source. Please use
> > proper judgment and caution when opening attachments, clicking links, or
> > responding to this email.
> > > >
> > > >
> > > >>>> +.. _device_tree_usage:
> > > >>>> +
> > > >>>> +Device Tree Usage
> > > >>>> +-----------------
> > > >>>> +
> > > >>>> +The xsabin file stores metadata which advertise HW subsystems
> > > >>>> +present in a partition. The metadata is stored in device tree
> > > >>>> +format with a well defined schema. XRT management driver uses
> > > >>>> +this information to bind *xrt_drivers* to the subsystem
> > > >>>> +instantiations. The xrt_drivers are found in **xrt-lib.ko** kernel
> > module.
> > > >>> I'm still catching up the patchset from the very beginning, and
> > > >>> just finished the Documentation part. So far, I see the DT usage
> > > >>> concern which may impact the architecure a lot, so I should raise it ASAP.
> > > >>>
> > > >>> The concern raised by the DT maintainer:
> > > >>> https://lore.kernel.org/linux-fpga/CAL_JsqLod6FBGFhu7WXtMrB_z7wj8-
> > > >>> up0EetM1QS9M3gjm8d7Q@mail.gmail.com/
> > > >>>
> > > >>> First of all, directly parsing FDT in device drivers is not a
> > > >>> normal usage of DT in linux. It is out of the current DT usage
> > > >>> model. So it should be agreed by DT maintainers.
> > > >> Thanks for reviewing XRT document and providing feedback.
> > > >> Here is the reply from Sonal for Rob's question:
> > > >> https://lore.kernel.org/linux-
> > fpga/BY5PR02MB62604B87C66A1AD139A6F15
> > > >> 3BBF40@BY5PR02MB6260.namprd02.prod.outlook.com/
> > > >> Overall, libfdt is used by XRT driver to parse the metadata which
> > > >> comes with an Alveo board.
> > > >> When XRT driver discovers an Alveo board, it will read a fdt blob
> > > >> from board firmware file resident on the host.
> > > >> By parsing the fdt blob, XRT driver gets information about this
> > > >> Alveo board, such as version, uuid, IPs exposed to PCI BAR, interrupt
> > binding etc.
> > > >> So libfdt is used simply as Alveo metadata parser here. XRT drivers
> > > >> do not interact with system wide DT or present the Alveo device
> > > >> tree to host. For many systems like x86_64, system wide DT is not
> > > >> present but libfdt parsing services will still be needed.
> > > > Yes, I understand the use case.
> > > >
> > > > My concern is, directly parsing an isolated FDT in device driver and
> > > > populate sub devices, skipping the unflattening, this is a new
> > > > working model of device tree usage, but for the same purpose as the
> > > > existing one.
> > > >
> > > > So I really need the confirmation of DT maintainers.
> >
> > Perhaps you could explain why you think you need to use FDT instead of
> > unflattening. Without that, the answer is don't use FDT.
> >
> Xilinx Alveo PCIe cards are predominantly used in x86_64 systems which do not have device tree support compiled into the kernel. XRT driver uses a matching FDT to discover IP subsystems sitting behind the PCIe BARs exposed by an Alveo PCIe card. The FDT blob (as part of an Alveo PCIe card firmware) can be freely downloaded from xilinx.com.

If the kernel is going to consume that FDT blob, then it needs to
follow upstream practices which primarily means all the device
bindings must be documented with schema and reviewed.


> If using an unflattened tree (instead of FDT) is the right solution then we would certainly look into it. Should the PCIe driver then call something like of_fdt_unflatten_tree() with a FDT blob and the kernel would then build an unflattened tree and hang it off the PCIe device node? The FDT blob for a PCIe device is only known to the driver since different PCIe platforms may store it differently: a known location in the PCIe BAR, the flash on the PCIe board or a file on the filesystem. If the kernel can provide a general on demand unflattening service similar to DTO use model, we will have a more scalable solution to describe IP subsystems exposed by a PCIe device and make their discovery data driven. Can this feature also work on x86_64 systems which does not use OF?

There's other similar usecases like this. For example, an FTDI or
similar USB to serial chip that has GPIO, I2C, etc. and could have
downstream devices hanging off of those interfaces. And then you could
plug-in multiple of those devices to the host system. For this to
work, we'd need to create a base tree (if there isn't one) with nodes
for the USB or PCI device(s) and then an overlay for the device can be
applied to those nodes. This is also partially an issue on DT based
systems as the DT node may not exist given these are 'discoverable'
buses. It's a bit easier to solve given the PCI host bridge or USB
controller exists in the DT already.

There's really 2 separate parts here. There's how to attach a DT to a
device on a non-DT system (or DT system with a device not described in
the base DT). The second part is how to describe the PCI device and
downstream devices. This part is no different than any other device.


> > > >>> Current FPGA framework modifies kernel's live tree by DT overlay,
> > > >>> when FPGA is dynamically reprogrammed and new HW devices appear.
> > > >>> See Documentation/devicetree/bindings/fpga/fpga-region.txt.
> > > >>>
> > > >>> Then something less important:
> > > >>>
> > > >>>     1. The bindings should be documented in
> > Documentation/devicetree/bindings/.
> >
> > Yes.
> >
> > > >>>     2. Are all the example DT usage conform to the exsiting bindings? I
> > > >>>        didn't go through all device classes, but remember like the
> > > >>>        interrupt-controller should have a "interrupt-controller" property,
> > and
> > > >>>        the PCI properties are also different from PCI bindings.
> >
> > They don't, but should. I can't tell what you are trying to do here, but it looks
> > like a mess.
> >
> Will appreciate any pointers on existing PCIe use case for the device tree.

Documentation/devicetree/bindings/pci/ and there's the PCI bus schema
here[1]. There's also the OpenFirmware PCI spec[2].

Rob

[1] https://github.com/devicetree-org/dt-schema/blob/main/schemas/pci/pci-bus.yaml
[2] https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf

  reply	other threads:[~2021-10-22  4:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 16:05 [PATCH V9 XRT Alveo 00/14] XRT Alveo driver overview Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 01/14] Documentation: fpga: Add a document describing XRT Alveo drivers Lizhi Hou
2021-10-12  5:09   ` Xu Yilun
2021-10-13 19:13     ` Lizhi Hou
2021-10-14  2:21       ` Xu Yilun
2021-10-14 16:12         ` Lizhi Hou
2021-10-19  4:32           ` Sonal Santan
2021-10-19 13:02           ` Rob Herring
2021-10-21  5:36             ` Sonal Santan
2021-10-21 17:38               ` Rob Herring
2021-10-22  4:36                 ` Sonal Santan [this message]
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 02/14] fpga: xrt: driver metadata helper functions Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 03/14] fpga: xrt: xclbin file " Lizhi Hou
2021-10-19  8:30   ` Xu Yilun
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 04/14] fpga: xrt: xrt-lib driver manager Lizhi Hou
2021-08-19 12:14   ` Tom Rix
2021-08-21 16:44     ` Moritz Fischer
2021-08-22 14:06       ` Tom Rix
2021-09-10 21:34       ` Lizhi Hou
2021-09-14 13:27         ` Tom Rix
2021-09-27 22:21           ` Sonal Santan
2021-09-27 22:44             ` Sonal Santan
2021-09-28  1:59             ` Xu Yilun
2021-10-25  8:01   ` Xu Yilun
2021-10-26  0:47     ` Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 05/14] fpga: xrt: group driver Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 06/14] fpga: xrt: char dev node helper functions Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 07/14] fpga: xrt: root driver infrastructure Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 08/14] fpga: xrt: " Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 09/14] fpga: xrt: management physical function driver (root) Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 10/14] fpga: xrt: main driver for management function device Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 11/14] fpga: xrt: fpga-mgr and region implementation for xclbin download Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 12/14] fpga: xrt: ICAP driver Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 13/14] fpga: xrt: partition isolation driver Lizhi Hou
2021-08-02 16:05 ` [PATCH V9 XRT Alveo 14/14] fpga: xrt: Kconfig and Makefile updates for XRT drivers Lizhi Hou

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=SJ0PR02MB8845B91BA06D0444D9466B4FBB809@SJ0PR02MB8845.namprd02.prod.outlook.com \
    --to=sonals@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhih@xilinx.com \
    --cc=maxz@xilinx.com \
    --cc=mdf@kernel.org \
    --cc=michals@xilinx.com \
    --cc=robh@kernel.org \
    --cc=stefanos@xilinx.com \
    --cc=trix@redhat.com \
    --cc=yilun.xu@intel.com \
    --cc=yliu@xilinx.com \
    --subject='Re: [PATCH V9 XRT Alveo 01/14] Documentation: fpga: Add a document describing XRT Alveo drivers' \
    /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

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).