From: Rob Herring <robh+dt@kernel.org> To: Alan Tull <atull@kernel.org> Cc: Wu Hao <hao.wu@intel.com>, 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: Thu, 27 Jul 2017 14:10:01 -0500 [thread overview] Message-ID: <CAL_JsqJfGJwDcXtpBs73TsSKTCwfAPywgyTPwzy1GQotJ7DTzw@mail.gmail.com> (raw) In-Reply-To: <CANk1AXRoxz7nOY--UYfBtg-3kGFy0gqCz0cbF9mOvzU2+EdzpA@mail.gmail.com> 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. That's really up to Linux and outside the scope of the bindings. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Wu Hao <hao.wu-ral2JQCrhuEAvxtiuMwx3w@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: Thu, 27 Jul 2017 14:10:01 -0500 [thread overview] Message-ID: <CAL_JsqJfGJwDcXtpBs73TsSKTCwfAPywgyTPwzy1GQotJ7DTzw@mail.gmail.com> (raw) In-Reply-To: <CANk1AXRoxz7nOY--UYfBtg-3kGFy0gqCz0cbF9mOvzU2+EdzpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 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. That's really up to Linux and outside the scope of the bindings. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-27 19:10 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 [this message] 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 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=CAL_JsqJfGJwDcXtpBs73TsSKTCwfAPywgyTPwzy1GQotJ7DTzw@mail.gmail.com \ --to=robh+dt@kernel.org \ --cc=atull@kernel.org \ --cc=christopher.rauer@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=enno.luebbers@intel.com \ --cc=hao.wu@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=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.