- 15 Jul, 2018 40 commits
-
-
Kang Luwei authored
The Header Register set is always present for FPGA Management Engine (FME), this patch implements init and uinit function for header sub feature and introduces several read-only sysfs interfaces for the capability and status. Sysfs interfaces: * /sys/class/fpga_region/<regionX>/<dfl-fme.x>/ports_num Read-only. Number of ports implemented * /sys/class/fpga_region/<regionX>/<dfl-fme.x>/bitstream_id Read-only. Bitstream (static FPGA region) identifier number. It contains the detailed version and other information of this static FPGA region. * /sys/class/fpga_region/<regionX>/<dfl-fme.x>/bitstream_metadata Read-only. Bitstream (static FPGA region) meta data. It contains the synthesis date, seed and other information of this static FPGA region. Signed-off-by:
Tim Whisonant <tim.whisonant@intel.com> Signed-off-by:
Enno Luebbers <enno.luebbers@intel.com> Signed-off-by:
Shiva Rao <shiva.rao@intel.com> Signed-off-by:
Christopher Rauer <christopher.rauer@intel.com> Signed-off-by:
Kang Luwei <luwei.kang@intel.com> Signed-off-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by:
Wu Hao <hao.wu@intel.com> Acked-by:
Alan Tull <atull@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kang Luwei authored
The FPGA Management Engine (FME) provides power, thermal management, performance counters, partial reconfiguration and other functions. For each function, it is packaged into a private feature linked to the FME feature device in the 'Device Feature List'. It's a platform device created by DFL framework. This patch adds the basic framework of FME platform driver. It defines sub feature drivers to handle the different sub features, including init, uinit and ioctl. It also registers the file operations for the device file. Signed-off-by:
Moritz Fischer <mdf@kernel.org> Signed-off-by:
-
Wu Hao authored
The Device Feature List (DFL) is implemented in MMIO and features are linked via the DFLs. This patch enables pcie driver to prepare enumeration information (e.g. locations of all device feature lists in MMIO) and use common APIs provided by the Device Feature List framework to enumerate each feature device linked. Signed-off-by:
Zhang Yi <yi.z.zhang@intel.com> Signed-off-by:
-
Zhang Yi authored
This patch implements the basic framework of the driver for FPGA PCIe device which implements the Device Feature List (DFL) in its MMIO space. This driver is verified on Intel(R) PCIe-based FPGA DFL devices, including both integrated (e.g. Intel Server Platform with In-package FPGA) and discrete (e.g. Intel FPGA PCIe Acceleration Cards) solutions. Signed-off-by:
-
Wu Hao authored
This patch adds one common function in DFL framework. It uses port_ops get_id callback to get port id and compare it with given value. This function could be used as match function of the dfl_fpga_cdev_find_port function. Signed-off-by:
-
Wu Hao authored
In some cases, other DFL driver modules may need to access some port operations, e.g. disable / enable port for partial reconfiguration in FME module. In order to avoid dependency between port and FME modules, this patch introduces the dfl_fpga_port_ops support in DFL framework. A global dfl_fpga_port_ops list is added in the DFL framework, and it allows other DFL modules to use these port operations registered to this list, even in virtualization case, the port platform device is turned into VF / guest VM and hidden in host, the registered port_ops is still usable. It resolves the dependency issues between modules, but once get port ops API returns a valid port ops, that means related port driver module has been module_get to prevent from unexpected unload, and put port ops API must be invoked after use. These APIs introduced by this patch is listed below: * dfl_fpga_port_ops_add add one port ops to the global list. * dfl_fpga_port_ops_del del one port ops from the global list. * dfl_fpga_port_ops_get / dfl_fpga_port_ops_put get/put the port ops before/after use. Signed-off-by:
-
Xiao Guangrong authored
This patch abstracts the common operations of the sub features and defines the feature_ops data structure, including init, uinit and ioctl function pointers. And this patch adds some common helper functions for FME and AFU drivers, e.g. dfl_feature_dev_use_begin/end which are used to ensure exclusive usage of the feature device file. Signed-off-by:
-
Wu Hao authored
For feature devices, we need a method to find the port dedicated to the device. This patch adds a function dfl_fpga_cdev_find_port for this purpose. e.g. FPGA Management Engine (FME) Partial Reconfiguration sub feature, it uses this function to find dedicated port on the device for PR function implementation. Signed-off-by:
-
Wu Hao authored
For feature devices drivers, both the FPGA Management Engine (FME) and Accelerated Function Unit (AFU) driver need to expose user interfaces via the device file, for example, mmap and ioctls. This patch adds chardev support in the dfl driver for feature devices, FME and AFU. It reserves the chardev regions for FME and AFU and provide interfaces for FME and AFU driver to register their device file operations. Signed-off-by:
-
Wu Hao authored
Device Feature List (DFL) defines a feature list structure that creates a linked list of feature headers within the MMIO space to provide an extensible way of adding features. This patch introduces a kernel module to provide basic infrastructure to support FPGA devices which implement the Device Feature List. Usually there will be different features and their sub features linked into the DFL. This code provides common APIs for feature enumeration, it creates a container device (FPGA base region), walks through the DFLs and creates platform devices for feature devices (Currently it only supports two different feature devices, FPGA Management Engine (FME) and Port which the Accelerator Function Unit (AFU) connected to). In order to enumerate the DFLs, the common APIs required low level driver to provide necessary enumeration information (e.g. address for each device feature list for given device) and fill it to the dfl_fpga_enum_info data structure. Please refer to below description for APIs added for enumeration. Functions for enumeration information preparation: *dfl_fpga_enum_info_alloc allocate enumeration information data structure. *dfl_fpga_enum_info_add_dfl add a device feature list to dfl_fpga_enum_info data structure. *dfl_fpga_enum_info_free free dfl_fpga_enum_info data structure and related resources. Functions for feature device enumeration: *dfl_fpga_feature_devs_enumerate enumerate feature devices and return container device. *dfl_fpga_feature_devs_remove remove feature devices under given container device. Signed-off-by:
-
Wu Hao authored
This patch introduces a compat_id pointer member and sysfs interface for each fpga region, similar as compat_id for fpga manager, it allows applications to read the per region compat_id for compatibility checking before other actions on this fpga-region (e.g. PR). Signed-off-by:
-
Wu Hao authored
This patch introduces compat_id support to fpga manager, it adds a fpga_compat_id pointer to fpga manager data structure to allow fpga manager drivers to save the compatibility id. This compat_id could be used for compatibility checking before doing partial reconfiguration to associated fpga regions. Signed-off-by:
-
Wu Hao authored
This patch adds status sysfs interface for fpga manager, it's a read only interface which allows user to get fpga manager status, including full/partial reconfiguration error and other status information. It adds a status callback to fpga_manager_ops too, allows each fpga_manager driver to define its own method to collect latest status from hardware. The following sysfs file is created: * /sys/class/fpga_manager/<fpga>/status Return status of fpga manager, including reconfiguration errors. Signed-off-by:
-
Wu Hao authored
This patch adds region_id to fpga_image_info data structure, it allows driver to pass region id information to fpga-mgr via fpga_image_info for fpga reconfiguration function. Signed-off-by:
-
Wu Hao authored
Add a document for FPGA Device Feature List (DFL) Framework Overview. Signed-off-by:
-
Robin Murphy authored
Probing the TPIU driver under UBSan triggers an out-of-bounds shift warning in coresight_timeout(): ... [ 5.677530] UBSAN: Undefined behaviour in drivers/hwtracing/coresight/coresight.c:929:16 [ 5.685542] shift exponent 64 is too large for 64-bit type 'long unsigned int' ... On closer inspection things are exponentially out of whack because we're passing a bitmask where a bit number should be. Amusingly, it seems that both calls will find their expected values by sheer luck and appear to succeed: 1 << FFCR_FON_MAN ends up at bit 64 which whilst undefined evaluates as zero in practice, while 1 << FFSR_FT_STOPPED finds bit 2 (TCPresent) which apparently is usually tied high. Following the examples of other drivers, define separate FOO and FOO_BIT macros for masks vs. indices, and put things right. CC: Robert Walker <robert.walker@arm.com> CC: Mike Leach <mike.leach@linaro.org> CC: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: 11595db8 ("coresight: Fix disabling of CoreSight TPIU") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Now that we can use a CATU with a scatter gather table, add support for the TMC ETR to make use of the connected CATU in translate mode. This is done by adding CATU as new buffer mode. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Suzuki K Poulose authored
This patch adds the support for setting up a SG table for use by the CATU. We reuse the tmc_sg_table to represent the table/data pages, even though the table format is different. Similar to ETR SG table, CATU uses a 4KB page size for data buffers as well as page tables. All table entries are 64bit wide and have the following format: 63 12 1 0 x-----------------------------------x | Address [63-12] | SBZ | V | x-----------------------------------x Where [V] -> 0 - Pointer is invalid 1 - Pointer is Valid CATU uses only first half of the page for data page pointers. i.e, single table page will only have 256 page pointers, addressing upto 1MB of data. The second half of a table page contains only two pointers at the end of the page (i.e, pointers at index 510 and 511), which are used as links to the "Previous" and "Next" page tables respectively. The first table page has an "Invalid" previous pointer and the next pointer entry points to the second page table if there is one. Similarly the last table page has an "Invalid" next pointer to indicate the end of the table chain. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: -
Suzuki K Poulose authored
Document CATU device-tree bindings. CATU augments the TMC-ETR by providing an improved Scatter Gather mechanism for streaming trace data to non-contiguous system RAM pages. Cc: devicetree@vger.kernel.org Cc: frowand.list@gmail.com Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Suzuki K Poulose authored
Add the initial support for Coresight Address Translation Unit, which augments the TMC in Coresight SoC-600 by providing an improved Scatter Gather mechanism. CATU is always connected to a single TMC-ETR and converts the AXI address with a translated address (from a given SG table with specific format). The CATU should be programmed in pass through mode and enabled even if the ETR doesn't use the translation by CATU. This patch provides mechanism to enable/disable the CATU always in the pass through mode. We reuse the existing ports mechanism to link the TMC-ETR to the connected CATU. i.e, TMC-ETR:output_port0 -> CATU:input_port0 Reference manual for CATU component is avilable in version r2p0 of : "Arm Coresight System-on-Chip SoC-600 Technical Reference Manual". Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Add a new coresight device type, which do not belong to any of the existing types, i.e, source, sink, link etc. A helper device could be connected to a coresight device, which could augment the functionality of the coresight device. This is intended to cover Coresight Address Translation Unit (CATU) devices, which provide improved Scatter Gather mechanism for TMC ETR. The idea is that the helper device could be controlled by the driver of the device it is attached to (in this case ETR), transparent to the generic coresight driver (and paths). The operations include enable(), disable(), both of which could accept a device specific "data" which the driving device and the helper device could share. Since they don't appear in the coresight "path" tracked by software, we have to ensure that they are powered up/down whenever the master device is turned on. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Clean up our struct a little bit by using a union instead of a struct for tracking the subtype of a device. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
If we fail to find the input / output port for a LINK component while enabling a path, we should fail gracefully rather than assuming port "0". Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Nobody uses the "clk" field in struct coresight_platform_data. Remove it. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
We request for "CORESIGHT_BARRIER_PKT_SIZE" length and we should be happy when we get that size. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
The newly introduced code fails to build in some configurations unless we include the right headers: drivers/hwtracing/coresight/coresight-tmc-etr.c: In function 'tmc_free_table_pages': drivers/hwtracing/coresight/coresight-tmc-etr.c:206:3: error: implicit declaration of function 'vunmap'; did you mean 'iounmap'? [-Werror=implicit-function-declaration] Fixes: 79613ae8715a ("coresight: Add generic TMC sg table framework") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Suzuki K Poulose authored
Now that we can dynamically switch between contiguous memory and SG table depending on the trace buffer size, provide the support for selecting an appropriate buffer size. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Add the support for Scatter-Gather mode to the etr-buf layer. Since we now have two different modes, we choose the backend based on a set of conditions, documented in the code. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
The TMC-ETR can use the target trace buffer in two different modes. Normal physically contiguous mode and a discontiguous list pages in Scatter-Gather mode. Also we have dedicated Coresight component, CATU (Coresight Address Translation Unit) to provide improved scatter-gather mode in Coresight SoC-600. This complicates the management of the buffer used for trace, depending on the mode in which ETR is configured. So, this patch adds a transparent layer for managing the ETR buffer which abstracts the basic operations on the buffer (alloc, free, sync and retrieve the data) and uses the mode specific helpers to do the actual operation. This also allows the ETR driver to choose the best mode for a given use case and adds the flexibility to fallback to a different mode, without duplicating the code. The patch also adds the "normal" flat memory mode and switches the sysfs driver to use the new layer. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
This patch adds support for setting up an SG table used by the TMC ETR inbuilt SG unit. The TMC ETR uses 4K page sized tables to hold pointers to the 4K data pages with the last entry in a table pointing to the next table with the entries, by kind of chaining. The 2 LSBs determine the type of the table entry, to one of : Normal - Points to a 4KB data page. Last - Points to a 4KB data page, but is the last entry in the page table. Link - Points to another 4KB table page with pointers to data. The code takes care of handling the system page size which could be different than 4K. So we could end up putting multiple ETR SG tables in a single system page, vice versa for the data pages. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: -
Suzuki K Poulose authored
This patch introduces a generic sg table data structure and associated operations. An SG table can be used to map a set of Data pages where the trace data could be stored by the TMC ETR. The information about the data pages could be stored in different formats, depending on the type of the underlying SG mechanism (e.g, TMC ETR SG vs Coresight CATU). The generic structure provides book keeping of the pages used for the data as well as the table contents. The table should be filled by the user of the infrastructure. A table can be created by specifying the number of data pages as well as the number of table pages required to hold the pointers, where the latter could be different for different types of tables. The pages are mapped in the appropriate dma data direction mode (i.e, DMA_TO_DEVICE for table pages and DMA_FROM_DEVICE for data pages). The framework can optionally accept a set of allocated data pages (e.g, perf ring buffer) and map them accordingly. The table and data pages are vmap'ed to allow easier access by the drivers. The framework also provides helpers to sync the data written to the pages with appropriate directions. This will be later used by the TMC ETR SG unit and CATU. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
We are about to add the support for ETR builtin scatter-gather mode for dealing with large amount of trace buffers. However, on some of the platforms, using the ETR SG mode can lock up the system due to the way the ETR is connected to the memory subsystem. In SG mode, the ETR performs READ from the scatter-gather table to fetch the next page and regular WRITE of trace data. If the READ operation doesn't complete(due to the memory subsystem issues, which we have seen on a couple of platforms) the trace WRITE cannot proceed leading to issues. So, we by default do not use the SG mode, unless it is known to be safe on the platform. We define a DT property for the TMC node to specify whether we have a proper SG mode. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: John Horley <john.horley@arm.com> Cc: Robert Walker <robert.walker@arm.com> Cc: devicetree@vger.kernel.org Cc: frowand.list@gmail.com Reviewed-by:
-
Suzuki K Poulose authored
Right now we open code filling the trace buffer with synchronization packets when the circular buffer wraps around in different drivers. Move this to a common place. While at it, clean up the barrier_pkt array to strip off the trailing '\0'. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
We don't support ETR in perf mode yet. So, don't even try to enable the hardware, even by mistake. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
We zero out the entire trace buffer used for ETR before it is enabled, for helping with debugging. With the addition of scatter-gather mode, the buffer could be bigger and non-contiguous. Get rid of this step; if someone wants to debug, they can always add it as and when needed. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
At the moment we adjust the buffer pointers for reading the trace data via misc device in the common code for ETF/ETB and ETR. Since we are going to change how we manage the buffer for ETR, let us move the buffer manipulation to the respective driver files, hiding it from the common code. We do so by adding type specific helpers for finding the length of data and the pointer to the buffer, for a given length at a file position. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
Add ETM PIDs of the Arm cortex-A CPUs to the white list of ETMs. While at it add a helper macro to make it easier to add the new entries. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Mathieu Poirier authored
Now that we prevent users from using contextID tracing when PID namespaces are involved there is no client for function coresight_vpid_to_pid(). As such simply remove it. Signed-off-by:
Kim Phillips <kim.phillips@arm.com> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Mathieu Poirier authored
As with ETM3x, the ETM4x tracers can trigger trace acquisition based on contextID value, something that isn't useful when PID namespaces are enabled. Indeed the PID value of a process has a different representation in the kernel and the PID namespace, making the feature confusing and potentially leaking internal kernel information. As such simply return an error when the feature is being used from a PID namespace other than the default one. Signed-off-by:
-
Mathieu Poirier authored
Tracers can trigger trace acquisition based on contextID value, something that isn't useful when PID namespaces are enabled. Indeed the PID value of a process has a different representation in the kernel and the PID namespace, making the feature confusing and potentially leaking internal kernel information. As such simply return an error when the feature is being used from a PID namespace other than the default one. Signed-off-by:
-
