On Fri, 31 Mar 2017, Wu Hao wrote:
On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote:
On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote:
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.
'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
This following APIs are provided by FPGA device framework:
* fpga_dev_create
Create fpga device under the given parent device.
* fpga_dev_destroy
Destroy fpga device
The following sysfs files are created:
* /sys/class/fpga/<fpga.x>/name
Name of the fpga device.
How does this interact with the existing "fpga class" that is in the
kernel already?
The fpga-dev introduced by this patch, is only a container device, and
I completely understand the need for a container device. The fpga-region
is also primarily a container, and in some cases the fpga-region may
represent the entire fpga. Over time this code may become redundant.
drivers could register different functions under it. Per my understanding,
the existing "fpga class", including fpga-region, fpga-bridge and
fpga-manager, is used to provide reconfiguration function for FPGA. So
driver can create child node using this existing "fpga class" to provide
FPGA reconfiguration function, and more nodes under this container for
different functions for given FPGA device.
For Intel FPGA device, partial reconfiguration is only one function of
Intel FPGA Management Engine (FME). FME driver creates fpga_manager under
below path for partial reconfiguration, and other interfaces for more
functions, e.g power management, virtualization support and etc.
/sys/class/fpga/<fpga.x>/<intel-fpga-fme.x>/fpga_manager
Thanks
Hao
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
