From: Wu Hao <hao.wu@intel.com> To: Alan Tull <atull@kernel.org> Cc: Rob Herring <robh+dt@kernel.org>, Moritz Fischer <mdf@kernel.org>, linux-fpga@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "Kang, Luwei" <luwei.kang@intel.com>, "Zhang, Yi Z" <yi.z.zhang@intel.com>, Tim Whisonant <tim.whisonant@intel.com>, Enno Luebbers <enno.luebbers@intel.com>, Shiva Rao <shiva.rao@intel.com>, Christopher Rauer <christopher.rauer@intel.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org> Subject: Re: [PATCH v2 02/22] fpga: add FPGA device framework Date: Tue, 1 Aug 2017 16:43:26 +0800 [thread overview] Message-ID: <20170801084326.GB26227@hao-dev> (raw) In-Reply-To: <CANk1AXTsBQgX+0hYZA6mMhESApB-MkG9CETWExSPOpf7MXeKFw@mail.gmail.com> On Mon, Jul 31, 2017 at 04:40:16PM -0500, Alan Tull wrote: > On Thu, Jul 27, 2017 at 2:10 PM, Rob Herring <robh+dt@kernel.org> wrote: > > On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull <atull@kernel.org> wrote: > >> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao <hao.wu@intel.com> wrote: > >> > >> Hi Rob, > >> > >> I was hoping to pick your brain a bit on a DT question. > >> > >>> During FPGA device (e.g PCI-based) discovery, platform devices are > >>> registered for different FPGA function units. But the device node path > >>> isn't quite friendly to applications. > >>> > >>> Consider this case, applications want to access child device's sysfs file > >>> for some information. > >>> > >>> 1) Access using bus-based path (e.g PCI) > >>> > >>> /sys/bus/pci/devices/xxxxx/fpga_func_a.0/sysfs_file > >>> > >>> From the path, it's clear which PCI device is the parent, but not perfect > >>> solution for applications. PCI device BDF is not fixed, application may > >>> need to search all PCI device to find the actual FPGA Device. > >>> > >>> 2) Or access using platform device path > >>> > >>> /sys/bus/platform/devices/fpga_func_a.0/sysfs_file > >>> > >>> Applications find the actual function by name easily, but no information > >>> about which fpga device it belongs to. It's quite confusing if multiple > >>> FPGA devices are in one system. > >> > >> There's a proposal for adding sysfs nodes that correspond to each FPGA > >> device., with the devices located on each FPGA under them. It makes > >> it easier to see which device is on which FPGA. > > > > Makes sense. > > > >>> 'FPGA Device' class is introduced to resolve this problem. Each node under > >>> this class represents a fpga device, which may have one or more child > >>> devices. Applications only need to search under this FPGA Device class > >>> folder to find the child device node it needs. > >>> > >>> For example, for the platform has 2 fpga devices, each fpga device has > >>> 3 child devices, the hierarchy looks like this. > >>> > >>> Two nodes are under /sys/class/fpga/: > >>> /sys/class/fpga/fpga.0 > >>> /sys/class/fpga/fpga.1 > >>> > >>> Each node has 1 function A device and 2 function B devices: > >>> /sys/class/fpga/fpga.0/func_a.0 > >>> /sys/class/fpga/fpga.0/func_b.0 > >>> /sys/class/fpga/fpga.0/func_b.1 > >>> > >>> /sys/class/fpga/fpga.1/func_a.1 > >>> /sys/class/fpga/fpga.1/func_b.2 > >>> /sys/class/fpga/fpga.1/func_b.3 > > > > A class is generally what is the function of the device, not how it is > > attached. Seems like what you want here is a new bus type if the > > existing PCI and platform bus types don't work. > > > >> > >> I can see the value of having sysfs nodes that correspond to fpga > >> devices and being able to find devices under them. I'm thinking what > >> that would mean for Device Tree when fpga-dev is used on DT enabled > >> systems. In Device Tree, what is a fpga-dev? > > > > Just properly setting the parent struct device on the functions should > > be enough to figure out which function is in which fpga. I don't see > > why a new class is needed. > > > >> Currently the DT would have a FPGA bridge corresponding to each FPGA's > >> hardware bridge and a heirarchy of bridges, regions and devices under > >> it. On systems that don't support partial reconfiguration under the > >> OS (so not main bridge that was controlled by the OS), there would be > >> a FPGA region, then its child regions, bridges, and devices. > > > > The FPGA bridges could instantiate fpga bus type devices instead of > > platform devices. > > Yes > > Some FPGA use cases already have a base bridge per FPGA that could > serve as this bus. But this use case has a static FPGA image + > reprogrammable child fpga regions. There's no base bridge under Linux > since the FPGA was programmed and the bridge enabled before Linux > boots. An added base bridge that doesn't touch hardware will be > required for this type of use. Hi Alan Does 'base bridge' mentioned above mean a hardware bridge just like PCIe or USB? I tried to use fpga bus type device instead of fpga-dev class today, it works for me, e.g Intel FPGA device PCIe driver could create a fpga bus type dev as a child of PCIe device and its sysfs path will be changed to /sys/bus/fpga/devices/fpga.x/ from /sys/class/fpga/fpga.x/. For now, this fpga bus type device is only used as container device, so no driver needed for it. Do you have any concern on this? I see fpga bus type works fine, but I didn't see other advantages for this case, as we only use it as a container device to represent a FPGA device in sysfs hierarchy. :) Thanks Hao > > > That's really up to Linux and outside the scope of > > the bindings. > > Thanks for the feedback. > > Alan Tull > > > > > Rob
WARNING: multiple messages have this Message-ID (diff)
From: Wu Hao <hao.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> To: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, linux-fpga-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "Kang, Luwei" <luwei.kang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "Zhang, Yi Z" <yi.z.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Tim Whisonant <tim.whisonant-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Enno Luebbers <enno.luebbers-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Shiva Rao <shiva.rao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Christopher Rauer <christopher.rauer-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH v2 02/22] fpga: add FPGA device framework Date: Tue, 1 Aug 2017 16:43:26 +0800 [thread overview] Message-ID: <20170801084326.GB26227@hao-dev> (raw) In-Reply-To: <CANk1AXTsBQgX+0hYZA6mMhESApB-MkG9CETWExSPOpf7MXeKFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Mon, Jul 31, 2017 at 04:40:16PM -0500, Alan Tull wrote: > On Thu, Jul 27, 2017 at 2:10 PM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > > On Thu, Jul 27, 2017 at 11:35 AM, Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > >> On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao <hao.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: > >> > >> Hi Rob, > >> > >> I was hoping to pick your brain a bit on a DT question. > >> > >>> During FPGA device (e.g PCI-based) discovery, platform devices are > >>> registered for different FPGA function units. But the device node path > >>> isn't quite friendly to applications. > >>> > >>> Consider this case, applications want to access child device's sysfs file > >>> for some information. > >>> > >>> 1) Access using bus-based path (e.g PCI) > >>> > >>> /sys/bus/pci/devices/xxxxx/fpga_func_a.0/sysfs_file > >>> > >>> From the path, it's clear which PCI device is the parent, but not perfect > >>> solution for applications. PCI device BDF is not fixed, application may > >>> need to search all PCI device to find the actual FPGA Device. > >>> > >>> 2) Or access using platform device path > >>> > >>> /sys/bus/platform/devices/fpga_func_a.0/sysfs_file > >>> > >>> Applications find the actual function by name easily, but no information > >>> about which fpga device it belongs to. It's quite confusing if multiple > >>> FPGA devices are in one system. > >> > >> There's a proposal for adding sysfs nodes that correspond to each FPGA > >> device., with the devices located on each FPGA under them. It makes > >> it easier to see which device is on which FPGA. > > > > Makes sense. > > > >>> 'FPGA Device' class is introduced to resolve this problem. Each node under > >>> this class represents a fpga device, which may have one or more child > >>> devices. Applications only need to search under this FPGA Device class > >>> folder to find the child device node it needs. > >>> > >>> For example, for the platform has 2 fpga devices, each fpga device has > >>> 3 child devices, the hierarchy looks like this. > >>> > >>> Two nodes are under /sys/class/fpga/: > >>> /sys/class/fpga/fpga.0 > >>> /sys/class/fpga/fpga.1 > >>> > >>> Each node has 1 function A device and 2 function B devices: > >>> /sys/class/fpga/fpga.0/func_a.0 > >>> /sys/class/fpga/fpga.0/func_b.0 > >>> /sys/class/fpga/fpga.0/func_b.1 > >>> > >>> /sys/class/fpga/fpga.1/func_a.1 > >>> /sys/class/fpga/fpga.1/func_b.2 > >>> /sys/class/fpga/fpga.1/func_b.3 > > > > A class is generally what is the function of the device, not how it is > > attached. Seems like what you want here is a new bus type if the > > existing PCI and platform bus types don't work. > > > >> > >> I can see the value of having sysfs nodes that correspond to fpga > >> devices and being able to find devices under them. I'm thinking what > >> that would mean for Device Tree when fpga-dev is used on DT enabled > >> systems. In Device Tree, what is a fpga-dev? > > > > Just properly setting the parent struct device on the functions should > > be enough to figure out which function is in which fpga. I don't see > > why a new class is needed. > > > >> Currently the DT would have a FPGA bridge corresponding to each FPGA's > >> hardware bridge and a heirarchy of bridges, regions and devices under > >> it. On systems that don't support partial reconfiguration under the > >> OS (so not main bridge that was controlled by the OS), there would be > >> a FPGA region, then its child regions, bridges, and devices. > > > > The FPGA bridges could instantiate fpga bus type devices instead of > > platform devices. > > Yes > > Some FPGA use cases already have a base bridge per FPGA that could > serve as this bus. But this use case has a static FPGA image + > reprogrammable child fpga regions. There's no base bridge under Linux > since the FPGA was programmed and the bridge enabled before Linux > boots. An added base bridge that doesn't touch hardware will be > required for this type of use. Hi Alan Does 'base bridge' mentioned above mean a hardware bridge just like PCIe or USB? I tried to use fpga bus type device instead of fpga-dev class today, it works for me, e.g Intel FPGA device PCIe driver could create a fpga bus type dev as a child of PCIe device and its sysfs path will be changed to /sys/bus/fpga/devices/fpga.x/ from /sys/class/fpga/fpga.x/. For now, this fpga bus type device is only used as container device, so no driver needed for it. Do you have any concern on this? I see fpga bus type works fine, but I didn't see other advantages for this case, as we only use it as a container device to represent a FPGA device in sysfs hierarchy. :) Thanks Hao > > > That's really up to Linux and outside the scope of > > the bindings. > > Thanks for the feedback. > > Alan Tull > > > > > Rob
next prev parent reply other threads:[~2017-08-01 8:50 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-26 1:51 [PATCH v2 00/22] Intel FPGA Device Drivers Wu Hao 2017-06-26 1:51 ` Wu Hao 2017-06-26 1:51 ` [PATCH v2 01/22] docs: fpga: add a document for Intel FPGA driver overview Wu Hao 2017-06-26 1:51 ` Wu Hao 2017-07-12 14:51 ` Alan Tull 2017-07-13 4:25 ` Wu Hao 2017-07-13 4:25 ` Wu Hao 2017-07-14 23:59 ` Luebbers, Enno 2017-07-17 20:14 ` Alan Tull 2017-07-18 5:22 ` Greg KH 2017-07-18 5:22 ` Greg KH 2017-07-18 14:32 ` Alan Tull 2017-07-18 14:32 ` Alan Tull 2017-06-26 1:51 ` [PATCH v2 02/22] fpga: add FPGA device framework Wu Hao 2017-06-26 1:51 ` Wu Hao 2017-07-27 16:35 ` Alan Tull 2017-07-27 19:10 ` Rob Herring 2017-07-27 19:10 ` Rob Herring 2017-07-31 21:40 ` Alan Tull 2017-07-31 21:40 ` Alan Tull 2017-08-01 8:43 ` Wu Hao [this message] 2017-08-01 8:43 ` Wu Hao 2017-08-01 21:04 ` Alan Tull 2017-08-02 14:07 ` Wu Hao 2017-08-02 21:01 ` Alan Tull 2017-08-02 21:01 ` Alan Tull 2017-08-07 15:13 ` Alan Tull 2017-08-07 15:13 ` Alan Tull 2017-07-27 16:44 ` Alan Tull 2017-07-28 7:55 ` Wu Hao 2017-07-28 7:55 ` Wu Hao 2017-06-26 1:51 ` [PATCH v2 03/22] fpga: bridge: remove OF dependency for fpga-bridge Wu Hao 2017-06-26 1:51 ` Wu Hao 2017-08-02 21:21 ` Alan Tull 2017-09-25 16:34 ` Moritz Fischer 2017-09-21 19:11 ` Moritz Fischer 2017-09-21 19:11 ` Moritz Fischer 2017-09-21 19:50 ` Alan Tull 2017-09-22 2:15 ` Wu Hao 2017-09-22 2:15 ` Wu Hao 2017-09-23 1:53 ` Alan Tull 2017-09-23 1:53 ` Alan Tull 2017-06-26 1:52 ` [PATCH v2 04/22] fpga: mgr: add region_id to fpga_image_info Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-07-26 18:33 ` Alan Tull 2017-07-26 18:33 ` Alan Tull 2017-07-27 5:14 ` Wu Hao 2017-07-27 5:14 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 05/22] fpga: mgr: add status for fpga-mgr Wu Hao 2017-07-12 15:22 ` Alan Tull 2017-07-12 15:22 ` Alan Tull 2017-07-13 3:11 ` Wu Hao 2017-07-13 3:11 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 06/22] fpga: intel: add FPGA PCIe device driver Wu Hao 2017-08-07 20:43 ` Alan Tull 2017-08-14 12:33 ` Wu, Hao 2017-08-14 12:33 ` Wu, Hao 2017-08-14 12:33 ` Wu, Hao 2017-06-26 1:52 ` [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features Wu Hao 2017-06-26 18:42 ` Moritz Fischer 2017-06-27 3:17 ` Wu Hao 2017-06-27 15:34 ` Alan Tull 2017-06-27 15:34 ` Alan Tull 2017-07-13 17:52 ` Alan Tull 2017-07-13 17:52 ` Alan Tull 2017-07-14 9:22 ` Wu Hao 2017-07-14 9:22 ` Wu Hao 2017-07-17 19:15 ` Alan Tull 2017-07-18 2:29 ` Wu, Hao 2017-09-20 21:24 ` Alan Tull 2017-09-21 19:58 ` Alan Tull 2017-09-22 7:33 ` Wu Hao 2017-09-22 7:33 ` Wu Hao 2017-09-22 7:28 ` Wu Hao 2017-09-27 20:27 ` Alan Tull 2017-09-27 20:27 ` Alan Tull 2017-09-28 9:32 ` Wu Hao 2017-09-28 9:32 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 08/22] fpga: intel: pcie: add chardev support for feature devices Wu Hao 2017-06-26 1:52 ` [PATCH v2 09/22] fpga: intel: pcie: adds fpga_for_each_port callback for fme device Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-08-17 21:31 ` Alan Tull 2017-08-18 7:03 ` Wu Hao 2017-08-18 7:03 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 10/22] fpga: intel: add feature device infrastructure Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 11/22] fpga: intel: add FPGA Management Engine driver basic framework Wu Hao 2017-06-26 1:52 ` [PATCH v2 12/22] fpga: intel: fme: add header sub feature support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-07-17 18:53 ` Alan Tull 2017-07-18 1:17 ` Wu, Hao 2017-07-18 1:17 ` Wu, Hao 2017-07-18 14:33 ` Alan Tull 2017-07-18 14:33 ` Alan Tull 2017-06-26 1:52 ` [PATCH v2 13/22] fpga: intel: fme: add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao 2017-08-17 19:11 ` Alan Tull 2017-06-26 1:52 ` [PATCH v2 14/22] fpga: intel: fme: add partial reconfiguration sub feature support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 15/22] fpga: intel: add fpga manager platform driver for FME Wu Hao 2017-09-25 21:24 ` Moritz Fischer 2017-09-27 1:18 ` Wu Hao 2017-09-27 1:18 ` Wu Hao 2017-09-27 18:54 ` Alan Tull 2017-09-28 8:25 ` Wu Hao 2017-09-28 8:25 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 16/22] fpga: intel: add fpga bridge " Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-08-17 19:34 ` Alan Tull 2017-08-17 19:34 ` Alan Tull 2017-08-17 19:55 ` Moritz Fischer 2017-08-18 3:06 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 17/22] fpga: intel: add fpga region " Wu Hao 2017-07-12 16:09 ` Alan Tull 2017-07-12 16:09 ` Alan Tull 2017-07-13 2:31 ` Wu Hao 2017-07-13 2:31 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 18/22] fpga: intel: add FPGA Accelerated Function Unit driver basic framework Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-08-17 19:00 ` Alan Tull 2017-08-17 19:00 ` Alan Tull 2017-08-18 6:40 ` Wu Hao 2017-08-18 6:40 ` Wu Hao 2017-08-17 19:09 ` Moritz Fischer 2017-08-18 6:42 ` Wu Hao 2017-08-18 6:42 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 19/22] fpga: intel: afu: add header sub feature support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-08-14 21:37 ` Alan Tull 2017-08-16 5:11 ` Wu, Hao 2017-08-16 5:11 ` Wu, Hao 2017-08-16 5:11 ` Wu, Hao 2017-08-17 21:41 ` Alan Tull 2017-06-26 1:52 ` [PATCH v2 20/22] fpga: intel: afu add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-08-17 19:07 ` Alan Tull 2017-08-17 19:12 ` Moritz Fischer 2017-08-18 3:20 ` Wu Hao 2017-08-18 3:20 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 21/22] fpga: intel: afu: add user afu sub feature support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-06-26 1:52 ` [PATCH v2 22/22] fpga: intel: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support Wu Hao 2017-06-26 1:52 ` Wu Hao 2017-07-31 21:41 ` Alan Tull 2017-08-01 7:21 ` Wu Hao 2017-08-01 7:21 ` Wu Hao 2017-08-01 18:15 ` Moritz Fischer 2017-08-02 7:30 ` Wu Hao 2017-08-02 7:30 ` Wu Hao 2017-07-28 13:28 ` [PATCH v2 00/22] Intel FPGA Device Drivers Alan Tull 2017-07-28 13:28 ` Alan Tull
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=20170801084326.GB26227@hao-dev \ --to=hao.wu@intel.com \ --cc=atull@kernel.org \ --cc=christopher.rauer@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=enno.luebbers@intel.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-fpga@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luwei.kang@intel.com \ --cc=mdf@kernel.org \ --cc=robh+dt@kernel.org \ --cc=shiva.rao@intel.com \ --cc=tim.whisonant@intel.com \ --cc=yi.z.zhang@intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.