diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class-fpga-bridge | 11 | ||||
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class-mei | 16 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/display/ht16k33.txt | 42 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/fpga/fpga-region.txt | 494 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt | 20 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/vendor-prefixes.txt | 1 | ||||
| -rw-r--r-- | Documentation/fpga/fpga-mgr.txt | 43 | ||||
| -rw-r--r-- | Documentation/trace/intel_th.txt | 22 | ||||
| -rw-r--r-- | Documentation/trace/stm.txt | 37 |
10 files changed, 686 insertions, 17 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge b/Documentation/ABI/testing/sysfs-class-fpga-bridge new file mode 100644 index 000000000000..312ae2c579d8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge @@ -0,0 +1,11 @@ +What: /sys/class/fpga_bridge/<bridge>/name +Date: January 2016 +KernelVersion: 4.5 +Contact: Alan Tull <atull@opensource.altera.com> +Description: Name of low level FPGA bridge driver. + +What: /sys/class/fpga_bridge/<bridge>/state +Date: January 2016 +KernelVersion: 4.5 +Contact: Alan Tull <atull@opensource.altera.com> +Description: Show bridge state as "enabled" or "disabled" diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei index 80d9888a8ece..5096a82f4cde 100644 --- a/Documentation/ABI/testing/sysfs-class-mei +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -29,3 +29,19 @@ Description: Display fw status registers content Also number of registers varies between 1 and 6 depending on generation. +What: /sys/class/mei/meiN/hbm_ver +Date: Aug 2016 +KernelVersion: 4.9 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: Display the negotiated HBM protocol version. + + The HBM protocol version negotiated + between the driver and the device. + +What: /sys/class/mei/meiN/hbm_ver_drv +Date: Aug 2016 +KernelVersion: 4.9 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: Display the driver HBM protocol version. + + The HBM protocol version supported by the driver. diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt b/Documentation/devicetree/bindings/display/ht16k33.txt new file mode 100644 index 000000000000..8e5b30b87754 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ht16k33.txt @@ -0,0 +1,42 @@ +Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan +------------------------------------------------------------------------------- + +Required properties: +- compatible: "holtek,ht16k33" +- reg: I2C slave address of the chip. +- interrupt-parent: A phandle pointing to the interrupt controller + serving the interrupt for this chip. +- interrupts: Interrupt specification for the key pressed interrupt. +- refresh-rate-hz: Display update interval in HZ. +- debounce-delay-ms: Debouncing interval time in milliseconds. +- linux,keymap: The keymap for keys as described in the binding + document (devicetree/bindings/input/matrix-keymap.txt). + +Optional properties: +- linux,no-autorepeat: Disable keyrepeat. +- default-brightness-level: Initial brightness level [0-15] (default: 15). + +Example: + +&i2c1 { + ht16k33: ht16k33@70 { + compatible = "holtek,ht16k33"; + reg = <0x70>; + refresh-rate-hz = <20>; + debounce-delay-ms = <50>; + interrupt-parent = <&gpio4>; + interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>; + linux,keymap = < + MATRIX_KEY(2, 0, KEY_F6) + MATRIX_KEY(3, 0, KEY_F8) + MATRIX_KEY(4, 0, KEY_F10) + MATRIX_KEY(5, 0, KEY_F4) + MATRIX_KEY(6, 0, KEY_F2) + MATRIX_KEY(2, 1, KEY_F5) + MATRIX_KEY(3, 1, KEY_F7) + MATRIX_KEY(4, 1, KEY_F9) + MATRIX_KEY(5, 1, KEY_F3) + MATRIX_KEY(6, 1, KEY_F1) + >; + }; +}; diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt new file mode 100644 index 000000000000..3b32ba15a717 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -0,0 +1,494 @@ +FPGA Region Device Tree Binding + +Alan Tull 2016 + + CONTENTS + - Introduction + - Terminology + - Sequence + - FPGA Region + - Supported Use Models + - Device Tree Examples + - Constraints + + +Introduction +============ + +FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in +the Device Tree. FPGA Regions provide a way to program FPGAs under device tree +control. + +This device tree binding document hits some of the high points of FPGA usage and +attempts to include terminology used by both major FPGA manufacturers. This +document isn't a replacement for any manufacturers specifications for FPGA +usage. + + +Terminology +=========== + +Full Reconfiguration + * The entire FPGA is programmed. + +Partial Reconfiguration (PR) + * A section of an FPGA is reprogrammed while the rest of the FPGA is not + affected. + * Not all FPGA's support PR. + +Partial Reconfiguration Region (PRR) + * Also called a "reconfigurable partition" + * A PRR is a specific section of a FPGA reserved for reconfiguration. + * A base (or static) FPGA image may create a set of PRR's that later may + be independently reprogrammed many times. + * The size and specific location of each PRR is fixed. + * The connections at the edge of each PRR are fixed. The image that is loaded + into a PRR must fit and must use a subset of the region's connections. + * The busses within the FPGA are split such that each region gets its own + branch that may be gated independently. + +Persona + * Also called a "partial bit stream" + * An FPGA image that is designed to be loaded into a PRR. There may be + any number of personas designed to fit into a PRR, but only one at at time + may be loaded. + * A persona may create more regions. + +FPGA Bridge + * FPGA Bridges gate bus signals between a host and FPGA. + * FPGA Bridges should be disabled while the FPGA is being programmed to + prevent spurious signals on the cpu bus and to the soft logic. + * FPGA bridges may be actual hardware or soft logic on an FPGA. + * During Full Reconfiguration, hardware bridges between the host and FPGA + will be disabled. + * During Partial Reconfiguration of a specific region, that region's bridge + will be used to gate the busses. Traffic to other regions is not affected. + * In some implementations, the FPGA Manager transparantly handles gating the + buses, eliminating the need to show the hardware FPGA bridges in the + device tree. + * An FPGA image may create a set of reprogrammable regions, each having its + own bridge and its own split of the busses in the FPGA. + +FPGA Manager + * An FPGA Manager is a hardware block that programs an FPGA under the control + of a host processor. + +Base Image + * Also called the "static image" + * An FPGA image that is designed to do full reconfiguration of the FPGA. + * A base image may set up a set of partial reconfiguration regions that may + later be reprogrammed. + + ---------------- ---------------------------------- + | Host CPU | | FPGA | + | | | | + | ----| | ----------- -------- | + | | H | | |==>| Bridge0 |<==>| PRR0 | | + | | W | | | ----------- -------- | + | | | | | | + | | B |<=====>|<==| ----------- -------- | + | | R | | |==>| Bridge1 |<==>| PRR1 | | + | | I | | | ----------- -------- | + | | D | | | | + | | G | | | ----------- -------- | + | | E | | |==>| Bridge2 |<==>| PRR2 | | + | ----| | ----------- -------- | + | | | | + ---------------- ---------------------------------- + +Figure 1: An FPGA set up with a base image that created three regions. Each +region (PRR0-2) gets its own split of the busses that is independently gated by +a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be +reprogrammed independently while the rest of the system continues to function. + + +Sequence +======== + +When a DT overlay that targets a FPGA Region is applied, the FPGA Region will +do the following: + + 1. Disable appropriate FPGA bridges. + 2. Program the FPGA using the FPGA manager. + 3. Enable the FPGA bridges. + 4. The Device Tree overlay is accepted into the live tree. + 5. Child devices are populated. + +When the overlay is removed, the child nodes will be removed and the FPGA Region +will disable the bridges. + + +FPGA Region +=========== + +FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA +Region brings together the elements needed to program on a running system and +add the child devices: + + * FPGA Manager + * FPGA Bridges + * image-specific information needed to to the programming. + * child nodes + +The intended use is that a Device Tree overlay (DTO) can be used to reprogram an +FPGA while an operating system is running. + +An FPGA Region that exists in the live Device Tree reflects the current state. +If the live tree shows a "firmware-name" property or child nodes under a FPGA +Region, the FPGA already has been programmed. A DTO that targets a FPGA Region +and adds the "firmware-name" property is taken as a request to reprogram the +FPGA. After reprogramming is successful, the overlay is accepted into the live +tree. + +The base FPGA Region in the device tree represents the FPGA and supports full +reconfiguration. It must include a phandle to an FPGA Manager. The base +FPGA region will be the child of one of the hardware bridges (the bridge that +allows register access) between the cpu and the FPGA. If there are more than +one bridge to control during FPGA programming, the region will also contain a +list of phandles to the additional hardware FPGA Bridges. + +For partial reconfiguration (PR), each PR region will have an FPGA Region. +These FPGA regions are children of FPGA bridges which are then children of the +base FPGA region. The "Full Reconfiguration to add PRR's" example below shows +this. + +If an FPGA Region does not specify a FPGA Manager, it will inherit the FPGA +Manager specified by its ancestor FPGA Region. This supports both the case +where the same FPGA Manager is used for all of a FPGA as well the case where +a different FPGA Manager is used for each region. + +FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents +shutting down bridges that are upstream from the other active regions while one +region is getting reconfigured (see Figure 1 above). During PR, the FPGA's +hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges +within the static image of the FPGA. + +Required properties: +- compatible : should contain "fpga-region" +- fpga-mgr : should contain a phandle to an FPGA Manager. Child FPGA Regions + inherit this property from their ancestor regions. A fpga-mgr property + in a region will override any inherited FPGA manager. +- #address-cells, #size-cells, ranges : must be present to handle address space + mapping for child nodes. + +Optional properties: +- firmware-name : should contain the name of an FPGA image file located on the + firmware search path. If this property shows up in a live device tree + it indicates that the FPGA has already been programmed with this image. + If this property is in an overlay targeting a FPGA region, it is a + request to program the FPGA with that image. +- fpga-bridges : should contain a list of phandles to FPGA Bridges that must be + controlled during FPGA programming along with the parent FPGA bridge. + This property is optional if the FPGA Manager handles the bridges. + If the fpga-region is the child of a fpga-bridge, the list should not + contain the parent bridge. +- partial-fpga-config : boolean, set if partial reconfiguration is to be done, + otherwise full reconfiguration is done. +- external-fpga-config : boolean, set if the FPGA has already been configured + prior to OS boot up. +- region-unfreeze-timeout-us : The maximum time in microseconds to wait for + bridges to successfully become enabled after the region has been + programmed. +- region-freeze-timeout-us : The maximum time in microseconds to wait for + bridges to successfully become disabled before the region has been + programmed. +- child nodes : devices in the FPGA after programming. + +In the example below, when an overlay is applied targeting fpga-region0, +fpga_mgr is used to program the FPGA. Two bridges are controlled during +programming: the parent fpga_bridge0 and fpga_bridge1. Because the region is +the child of fpga_bridge0, only fpga_bridge1 needs to be specified in the +fpga-bridges property. During programming, these bridges are disabled, the +firmware specified in the overlay is loaded to the FPGA using the FPGA manager +specified in the region. If FPGA programming succeeds, the bridges are +reenabled and the overlay makes it into the live device tree. The child devices +are then populated. If FPGA programming fails, the bridges are left disabled +and the overlay is rejected. The overlay's ranges property maps the lwhps +bridge's region (0xff200000) and the hps bridge's region (0xc0000000) for use by +the two child devices. + +Example: +Base tree contains: + + fpga_mgr: fpga-mgr@ff706000 { + compatible = "altr,socfpga-fpga-mgr"; + reg = <0xff706000 0x1000 + 0xffb90000 0x20>; + interrupts = <0 175 4>; + }; + + fpga_bridge0: fpga-bridge@ff400000 { + compatible = "altr,socfpga-lwhps2fpga-bridge"; + reg = <0xff400000 0x100000>; + resets = <&rst LWHPS2FPGA_RESET>; + clocks = <&l4_main_clk>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + fpga_region0: fpga-region0 { + compatible = "fpga-region"; + fpga-mgr = <&fpga_mgr>; + }; + }; + + fpga_bridge1: fpga-bridge@ff500000 { + compatible = "altr,socfpga-hps2fpga-bridge"; + reg = <0xff500000 0x10000>; + resets = <&rst HPS2FPGA_RESET>; + clocks = <&l4_main_clk>; + }; + +Overlay contains: + +/dts-v1/ /plugin/; +/ { + fragment@0 { + target = <&fpga_region0>; + #address-cells = <1>; + #size-cells = <1>; + __overlay__ { + #address-cells = <1>; + #size-cells = <1>; + + firmware-name = "soc_system.rbf"; + fpga-bridges = <&fpga_bridge1>; + ranges = <0x20000 0xff200000 0x100000>, + <0x0 0xc0000000 0x20000000>; + + gpio@10040 { + compatible = "altr,pio-1.0"; + reg = <0x10040 0x20>; + altr,gpio-bank-width = <4>; + #gpio-cells = <2>; + clocks = <2>; + gpio-controller; + }; + + onchip-memory { + device_type = "memory"; + compatible = "altr,onchipmem-15.1"; + reg = <0x0 0x10000>; + }; + }; + }; +}; + + +Supported Use Models +==================== + +In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and +a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some +uses are specific to a FPGA device. + + * No FPGA Bridges + In this case, the FPGA Manager which programs the FPGA also handles the + bridges behind the scenes. No FPGA Bridge devices are needed for full + reconfiguration. + + * Full reconfiguration with hardware bridges + In this case, there are hardware bridges between the processor and FPGA that + need to be controlled during full reconfiguration. Before the overlay is + applied, the live DT must include the FPGA Manager, FPGA Bridges, and a + FPGA Region. The FPGA Region is the child of the bridge that allows + register access to the FPGA. Additional bridges may be listed in a + fpga-bridges property in the FPGA region or in the device tree overlay. + + * Partial reconfiguration with bridges in the FPGA + In this case, the FPGA will have one or more PRR's that may be programmed + separately while the rest of the FPGA can remain active. To manage this, + bridges need to exist in the FPGA that can gate the buses going to each FPGA + region while the buses are enabled for other sections. Before any partial + reconfiguration can be done, a base FPGA image must be loaded which includes + PRR's with FPGA bridges. The device tree should have a FPGA region for each + PRR. + +Device Tree Examples +==================== + +The intention of this section is to give some simple examples, focusing on +the placement of the elements detailed above, especially: + * FPGA Manager + * FPGA Bridges + * FPGA Region + * ranges + * target-path or target + +For the purposes of this section, I'm dividing the Device Tree into two parts, +each with its own requirements. The two parts are: + * The live DT prior to the overlay being added + * The DT overlay + +The live Device Tree must contain an FPGA Region, an FPGA Manager, and any FPGA +Bridges. The FPGA Region's "fpga-mgr" property specifies the manager by phandle +to handle programming the FPGA. If the FPGA Region is the child of another FPGA +Region, the parent's FPGA Manager is used. If FPGA Bridges need to be involved, +they are specified in the FPGA Region by the "fpga-bridges" property. During +FPGA programming, the FPGA Region will disable the bridges that are in its +"fpga-bridges" list and will re-enable them after FPGA programming has +succeeded. + +The Device Tree Overlay will contain: + * "target-path" or "target" + The insertion point where the the contents of the overlay will go into the + live tree. target-path is a full path, while target is a phandle. + * "ranges" + The address space mapping from processor to FPGA bus(ses). + * "firmware-name" + Specifies the name of the FPGA image file on the firmware search + path. The search path is described in the firmware class documentation. + * "partial-fpga-config" + This binding is a boolean and should be present if partial reconfiguration + is to be done. + * child nodes corresponding to hardware that will be loaded in this region of + the FPGA. + +Device Tree Example: Full Reconfiguration without Bridges +========================================================= + +Live Device Tree contains: + fpga_mgr0: fpga-mgr@f8007000 { + compatible = "xlnx,zynq-devcfg-1.0"; + reg = <0xf8007000 0x100>; + interrupt-parent = <&intc>; + interrupts = <0 8 4>; + clocks = <&clkc 12>; + clock-names = "ref_clk"; + syscon = <&slcr>; + }; + + fpga_region0: fpga-region0 { + compatible = "fpga-region"; + fpga-mgr = <&fpga_mgr0>; + #address-cells = <0x1>; + #size-cells = <0x1>; + ranges; + }; + +DT Overlay contains: +/dts-v1/ /plugin/; +/ { +fragment@0 { + target = <&fpga_region0>; + #address-cells = <1>; + #size-cells = <1>; + __overlay__ { + #address-cells = <1>; + #size-cells = <1>; + + firmware-name = "zynq-gpio.bin"; + + gpio1: gpio@40000000 { + compatible = "xlnx,xps-gpio-1.00.a"; + reg = <0x40000000 0x10000>; + gpio-controller; + #gpio-cells = <0x2>; + xlnx,gpio-width= <0x6>; + }; + }; +}; + +Device Tree Example: Full Reconfiguration to add PRR's +====================================================== + +The base FPGA Region is specified similar to the first example above. + +This example programs the FPGA to have two regions that can later be partially +configured. Each region has its own bridge in the FPGA fabric. + +DT Overlay contains: +/dts-v1/ /plugin/; +/ { + fragment@0 { + target = <&fpga_region0>; + #address-cells = <1>; + #size-cells = <1>; + __overlay__ { + #address-cells = <1>; + #size-cells = <1>; + + firmware-name = "base.rbf"; + + fpga-bridge@4400 { + compatible = "altr,freeze-bridge"; + reg = <0x4400 0x10>; + + fpga_region1: fpga-region1 { + compatible = "fpga-region"; + #address-cells = <0x1>; + #size-cells = <0x1>; + ranges; + }; + }; + + fpga-bridge@4420 { + compatible = "altr,freeze-bridge"; + reg = <0x4420 0x10>; + + fpga_region2: fpga-region2 { + compatible = "fpga-region"; + #address-cells = <0x1>; + #size-cells = <0x1>; + ranges; + }; + }; + }; + }; +}; + +Device Tree Example: Partial Reconfiguration +============================================ + +This example reprograms one of the PRR's set up in the previous example. + +The sequence that occurs when this overlay is similar to the above, the only +differences are that the FPGA is partially reconfigured due to the +"partial-fpga-config" boolean and the only bridge that is controlled during +programming is the FPGA based bridge of fpga_region1. + +/dts-v1/ /plugin/; +/ { + fragment@0 { + target = <&fpga_region1>; + #address-cells = <1>; + #size-cells = <1>; + __overlay__ { + #address-cells = <1>; + #size-cells = <1>; + + firmware-name = "soc_image2.rbf"; + partial-fpga-config; + + gpio@10040 { + compatible = "altr,pio-1.0"; + reg = <0x10040 0x20>; + clocks = <0x2>; + altr,gpio-bank-width = <0x4>; + resetvalue = <0x0>; + #gpio-cells = <0x2>; + gpio-controller; + }; + }; + }; +}; + +Constraints +=========== + +It is beyond the scope of this document to fully describe all the FPGA design +constraints required to make partial reconfiguration work[1] [2] [3], but a few +deserve quick mention. + +A persona must have boundary connections that line up with those of the partion +or region it is designed to go into. + +During programming, transactions through those connections must be stopped and +the connections must be held at a fixed logic level. This can be achieved by +FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration. + +-- +[1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf +[2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf +[3] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt new file mode 100644 index 000000000000..6462e12d8de6 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt @@ -0,0 +1,17 @@ +Broadcom OTP memory controller + +Required Properties: +- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used + in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second + generation Broadcom OTPC which is used in SoC's such as Stingray and supports + 64-bit read/write. +- reg: Base address of the OTP controller. +- brcm,ocotp-size: Amount of memory available, in 32 bit words + +Example: + +otp: otp@0301c800 { + compatible = "brcm,ocotp"; + reg = <0x0301c800 0x2c>; + brcm,ocotp-size = <2048>; +}; diff --git a/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt new file mode 100644 index 000000000000..853b6a754644 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt @@ -0,0 +1,20 @@ +* NXP LPC18xx OTP memory + +Internal OTP (One Time Programmable) memory for NXP LPC18xx/43xx devices. + +Required properties: + - compatible: Should be "nxp,lpc1850-otp" + - reg: Must contain an entry with the physical base address and length + for each entry in reg-names. + - address-cells: must be set to 1. + - size-cells: must be set to 1. + +See nvmem.txt for more information. + +Example: + otp: otp@40045000 { + compatible = "nxp,lpc1850-otp"; + reg = <0x40045000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 56a257b7c4d7..98371753a08f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -127,6 +127,7 @@ hitex Hitex Development Tools holt Holt Integrated Circuits, Inc. honeywell Honeywell hp Hewlett Packard +holtek Holtek Semiconductor, Inc. i2se I2SE GmbH ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. diff --git a/Documentation/fpga/fpga-mgr.txt b/Documentation/fpga/fpga-mgr.txt index ce3e84fa9023..86ee5078fd03 100644 --- a/Documentation/fpga/fpga-mgr.txt +++ b/Documentation/fpga/fpga-mgr.txt @@ -18,31 +18,37 @@ API Functions: To program the FPGA from a file or from a buffer: ------------------------------------------------- - int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, + int fpga_mgr_buf_load(struct fpga_manager *mgr, + struct fpga_image_info *info, const char *buf, size_t count); Load the FPGA from an image which exists as a buffer in memory. - int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags, + int fpga_mgr_firmware_load(struct fpga_manager *mgr, + struct fpga_image_info *info, const char *image_name); Load the FPGA from an image which exists as a file. The image file must be on -the firmware search path (see the firmware class documentation). - -For both these functions, flags == 0 for normal full reconfiguration or -FPGA_MGR_PARTIAL_RECONFIG for partial reconfiguration. If successful, the FPGA -ends up in operating mode. Return 0 on success or a negative error code. +the firmware search path (see the firmware class documentation). If successful, +the FPGA ends up in operating mode. Return 0 on success or a negative error +code. +A FPGA design contained in a FPGA image file will likely have particulars that +affect how the image is programmed to the FPGA. These are contained in struct +fpga_image_info. Currently the only such particular is a single flag bit +indicating whether the image is for full or partial reconfiguration. To get/put a reference to a FPGA manager: ----------------------------------------- struct fpga_manager *of_fpga_mgr_get(struct device_node *node); + struct fpga_manager *fpga_mgr_get(struct device *dev); + +Given a DT node or device, get an exclusive reference to a FPGA manager. void fpga_mgr_put(struct fpga_manager *mgr); -Given a DT node, get an exclusive reference to a FPGA manager or release -the reference. +Release the reference. To register or unregister the low level FPGA-specific driver: @@ -70,8 +76,11 @@ struct device_node *mgr_node = ... char *buf = ... int count = ... +/* struct with information about the FPGA image to program. */ +struct fpga_image_info info; + /* flags indicates whether to do full or partial reconfiguration */ -int flags = 0; +info.flags = 0; int ret; @@ -79,7 +88,7 @@ int ret; struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node); /* Load the buffer to the FPGA */ -ret = fpga_mgr_buf_load(mgr, flags, buf, count); +ret = fpga_mgr_buf_load(mgr, &info, buf, count); /* Release the FPGA manager */ fpga_mgr_put(mgr); @@ -96,8 +105,11 @@ struct device_node *mgr_node = ... /* FPGA image is in this file which is in the firmware search path */ const char *path = "fpga-image-9.rbf" +/* struct with information about the FPGA image to program. */ +struct fpga_image_info info; + /* flags indicates whether to do full or partial reconfiguration */ -int flags = 0; +info.flags = 0; int ret; @@ -105,7 +117,7 @@ int ret; struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node); /* Get the firmware image (path) and load it to the FPGA */ -ret = fpga_mgr_firmware_load(mgr, flags, path); +ret = fpga_mgr_firmware_load(mgr, &info, path); /* Release the FPGA manager */ fpga_mgr_put(mgr); @@ -157,7 +169,10 @@ The programming sequence is: 2. .write (may be called once or multiple times) 3. .write_complete -The .write_init function will prepare the FPGA to receive the image data. +The .write_init function will prepare the FPGA to receive the image data. The +buffer passed into .write_init will be atmost .initial_header_size bytes long, +if the whole bitstream is not immediately available then the core code will +buffer up at least this much before starting. The .write function writes a buffer to the FPGA. The buffer may be contain the whole FPGA image or may be a smaller chunk of an FPGA image. In the latter diff --git a/Documentation/trace/intel_th.txt b/Documentation/trace/intel_th.txt index f7fc5ba5df8d..f92070e7dde0 100644 --- a/Documentation/trace/intel_th.txt +++ b/Documentation/trace/intel_th.txt @@ -97,3 +97,25 @@ $ echo 0 > /sys/bus/intel_th/devices/0-msc0/active # and now you can collect the trace from the device node: $ cat /dev/intel_th0/msc0 > my_stp_trace + +Host Debugger Mode +================== + +It is possible to configure the Trace Hub and control its trace +capture from a remote debug host, which should be connected via one of +the hardware debugging interfaces, which will then be used to both +control Intel Trace Hub and transfer its trace data to the debug host. + +The driver needs to be told that such an arrangement is taking place +so that it does not touch any capture/port configuration and avoids +conflicting with the debug host's configuration accesses. The only +activity that the driver will perform in this mode is collecting +software traces to the Software Trace Hub (an stm class device). The +user is still responsible for setting up adequate master/channel +mappings that the decoder on the receiving end would recognize. + +In order to enable the host mode, set the 'host_mode' parameter of the +'intel_th' kernel module to 'y'. None of the virtual output devices +will show up on the intel_th bus. Also, trace configuration and +capture controlling attribute groups of the 'gth' device will not be +exposed. The 'sth' device will operate as usual. diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt index ea035f9dbfd7..11cff47eecce 100644 --- a/Documentation/trace/stm.txt +++ b/Documentation/trace/stm.txt @@ -69,12 +69,43 @@ stm device's channel mmio region is 64 bytes and hardware page size is width==64, you should be able to mmap() one page on this file descriptor and obtain direct access to an mmio region for 64 channels. +Examples of STM devices are Intel(R) Trace Hub [1] and Coresight STM +[2]. + +stm_source +========== + For kernel-based trace sources, there is "stm_source" device class. Devices of this class can be connected and disconnected to/from -stm devices at runtime via a sysfs attribute. +stm devices at runtime via a sysfs attribute called "stm_source_link" +by writing the name of the desired stm device there, for example: -Examples of STM devices are Intel(R) Trace Hub [1] and Coresight STM -[2]. +$ echo dummy_stm.0 > /sys/class/stm_source/console/stm_source_link + +For examples on how to use stm_source interface in the kernel, refer +to stm_console or stm_heartbeat drivers. + +Each stm_source device will need to assume a master and a range of +channels, depending on how many channels it requires. These are +allocated for the device according to the policy configuration. If +there's a node in the root of the policy directory that matches the +stm_source device's name (for example, "console"), this node will be +used to allocate master and channel numbers. If there's no such policy +node, the stm core will pick the first contiguous chunk of channels +within the first available master. Note that the node must exist +before the stm_source device is connected to its stm device. + +stm_console +=========== + +One implementation of this interface also used in the example above is +the "stm_console" driver, which basically provides a one-way console +for kernel messages over an stm device. + +To configure the master/channel pair that will be assigned to this +console in the STP stream, create a "console" policy entry (see the +beginning of this text on how to do that). When initialized, it will +consume one channel. [1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf [2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html |