Device Tree support for FPGA Programming

New bindings document for FPGA Region to support programming FPGA's under Device Tree control

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Moritz Fischer <[email protected]>

---

v9:  initial version added to this patchset
v10: s/fpga/FPGA/g

replace DT overlay example with slightly more complicated example move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
Changed to use FPGA bridges framework instead of resets for bridges.
v13: bridge at 0xff20000 -> bridge at ff200000, etc
Leave out directly talking about overlays
Remove regs and clocks directly under simple-fpga-bus in example Use common "firmware-name" binding instead of "fpga-firmware"
v14: Use firmware-name in bindings description
Call it FPGA Area
Remove bindings that specify FPGA Manager and FPGA Bridges
v15: Cleanup as per Rob's comments
Combine usage doc with bindings document
Document as being Altera specific
Additions and changes to add FPGA Bus
v16: Reworked to document FPGA Regions
rename altera-fpga-bus-fpga-area.txt -> fpga-region.txt Remove references that made it sound exclusive to Altera Remove altr, prefix from fpga-bus and fpga-area compatible strings Added Moritz' usage example with Xilinx

Cleaned up unit addresses
v17: Lots of rewrites to try to make things clearer
Clarify that overlay can be rejected if FPGA isn't programmed Add external-fpga-config binding already used in u-boot Change partial-reconfig binding to partial-fpga-config to align
with existing u-boot binding format *-fpga-config
Add a document from Xilinx' website
v18: Fix node names underscores to be hyphens

Fix copy/pasted duplicate nodes in diagram

---
 .../devicetree/bindings/fpga/fpga-region.txt       | 491 +++++++++++++++++++++
 1 file changed, 491 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt

Documentation/devicetree/bindings/fpga/fpga-region.txt new file +222 -0

new file mode 100644
index 0000000..cfac8c2
@@ -0,0 +1,491 @@
+FPGA Region Device Tree Binding
+
+Alan Tull 2016
+
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Overview
+ - Constraints
+ - FPGA Region
+ - Supported Use Models
+ - Sequence
+ - Device Tree Examples
+
+
+Introduction
+============
+
+FPGA Regions are introduced as a way to solve the problem of how to program an
+FPGA under an operating system and have the new hardware show up in the device
+tree.  By adding these bindings to the Device Tree, a system can have the
+information needed to program the FPGA and add the desired hardware, and also
+the information about the devices to be added to the Device Tree once the
+programming has succeeded.
+
+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 white papers and
+specifications for FPGA usage.
+
+
+Terminology
+===========
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+ * A section of the FPGA is reprogrammed while the rest of the FPGA is not
+   affected. Not all FPGA's support this.
+
+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 Manager
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+
+
+    ----------------       ------------------------------
+    |  Host CPU    |       |           FPGA             |
+    |              |       |                            |
+    |          ----|       |       -------    --------  |
+    |          | H |       |   |==>| FB0 |<==>| PRR0 |  |
+    |          | W |       |   |   -------    --------  |
+    |          |   |       |   |                        |
+    |          | B |<=====>|<==|   -------    --------  |
+    |          | R |       |   |==>| FB1 |<==>| PRR1 |  |
+    |          | I |       |   |   -------    --------  |
+    |          | D |       |   |                        |
+    |          | G |       |   |   -------    --------  |
+    |          | E |       |   |==>| FB2 |<==>| PRR2 |  |
+    |          ----|       |       -------    --------  |
+    |              |       |                            |
+    ----------------       ------------------------------
+
+Figure 1: An FPGA set up with a base image that created three regions.  Each
+region gets its own split of the busses that can be independently gated by an
+soft logic bridge in the FPGA.  The contents of each PRR can be reprogrammed
+independently while the rest of the system continues to function.
+
+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.
+ * FPGA bridges may be actual hardware or soft logic on the FPGA.
+ * During Full Reconfiguration, hardware bridges between the host and FPGA
+   will be disabled to prevent spurious data on the bus.
+ * These hardware FPGA Bridges may not be needed in implementations where the
+   FPGA Manager transparantly handles gating the buses.
+ * A base FPGA image may create a set of reprogrammable regions, each having
+   its own split of the busses that is gated by its own bridge in the FPGA.
+ * During Partial Reconfiguration of a specific region, the region's bridge
+   will be used to gate the busses.  Traffic to other regions is not affected.
+
+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.
+
+
+Overview
+========
+
+This binding introduces the FPGA Region which supports full or partial
+reconfiguration of a FPGA under device tree control.
+
+In the device tree, an FPGA Region brings together the devices (FPGA Managers
+and FPGA Bridges) needed to be able to program an FPGA device.  The FPGA Region
+also includes child nodes that are the devices that exist in the FPGA.
+
+The base FPGA Region in the device tree is required to include a phandle to an
+FPGA Manager.  This region also contains a list of phandles to the hardware FPGA
+Bridges, if any.  This base FPGA Region corresponds to the whole FPGA and is
+used for full reconfiguration.
+
+FPGA Regions that are children of the base FPGA region inherit the parent's FPGA
+Manager but specify their own bridges.  These child regions correspond to
+partial reconfiguration regions in the FPGA.  The bridges they specify will be
+FPGA Bridges within the static image of the FPGA.
+
+The intended use is that device tree overlays can be used to reprogram an FPGA
+while an operating system is running.  In that case, the live device tree will
+contain an FPGA Manager, FPGA Bridges, and the base FPGA Region.  The device
+tree overlays contain the name of the FPGA image file to be programmed and the
+child devices that will be contained in the FPGA after programming.
+
+When such a device tree overlay is applied, it is targeted to one of the
+existing FPGA regions.  A few things must happen in the OS's implementation
+before the overlay can be accepted into the live tree.  The OS will attempt to
+program the FPGA using the firmware that the overlay specifies.  That
+reprogramming sequence is detailed below (see the Sequence section).  If
+programming fails, the overlay is rejected.  If programming succeeds, the
+overlay is added into the live tree and correctly shows what firmware the FPGA
+has been programmed with.  Child nodes in the overlay are added and those
+devices are populated.
+
+The base FPGA Region supports full reconfiguration of the FPGA device.  If the
+FPGA image loaded contains the logic that creates a set of Partial
+Reconfiguration Regions, then the overlay that programs the FPGA should also add
+a set of FPGA Regions as children of the original FPGA Region.  The child FPGA
+Regions do not need to specify an FPGA Manager as they will use the ancestor
+region's FPGA Manager.
+
+
+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.
+
+FPGA Region
+===========
+
+An FPGA Region specifies the devices (FPGA Manager and FPGA Bridges ) needed to
+reconfigure a FPGA device.
+
+In the live Device Tree, an FPGA Region reflects the current configuration of
+the device.  If the live tree shows a "firmware-name" property under a FPGA
+Region, the FPGA already has been programmed with that firmware.
+
+A device tree overlay that targets a FPGA Region and adds the "firmware-name"
+property and child nodes is a request to reprogram the FPGA and, if successful,
+add the child nodes.  If reprogramming is not successful, the overlay must be
+rejected and not added to the live tree.
+
+Required properties:
+- compatible   : should contain "fpga-region"
+- fpga-mgr     : should contain a phandle to an FPGA Manager.  Child FPGA
+		 Regions inherit this property from the parent, so it
+		 should be left out for any child FPGA Regions.
+- fpga-bridges : should contain a list of phandles to FPGA Bridges.  This
+		 property is optional if the FPGA Manager controls the
+		 bridges during reprogramming.
+- #address-cells, #size-cells, ranges: must be present to handle address space
+  mapping for children.
+
+Properties added in an overlay:
+- 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
+  can only mean that the FPGA has already been programmed with this image.
+- partial-fpga-config : boolean property should be defined if partial
+  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
+  is done.
+- external-fpga-config : boolean property should be defined if the FPGA
+  has already been configured.  Then the FPGA Region can be used to add
+  child nodes for the devices that are in the FPGA.
+- child nodes : devices in the FPGA after programming.
+
+In the example below, when an overlay is applied targeting base_fpga_region,
+fpgamgr at ff706000 is used to program the FPGA and the bridge specified is
+controlled during the programming.  During programming, the bridges listed in
+that region 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 jtag_uart and led_pio child devices are then populated.  If
+FPGA programming fails, the bridges are left disabled and the overlay is
+rejected.
+
+Example:
+Base tree contains:
+
+	fpga_mgr0: fpgamgr at ff706000 {
+		compatible = "altr,socfpga-fpga-mgr";
+		reg = <0xff706000 0x1000
+		       0xffb90000 0x4>;
+		interrupts = <0 175 4>;
+	};

Documentation/devicetree/bindings/fpga/fpga-region.txt new file +190 -0

+		compatible = "fpga-region";
+		fpga-mgr = <&fpga_mgr0>;
+		fpga-bridges = <&fpga_bridge0>;
+
+		#address-cells = <0x1>;
+		#size-cells = <0x1>;
+		ranges = <0 0xff200000 0x100000>;
+	};
+
+/dts-v1/ /plugin/;
+/ {
+	fragment at 0 {
+		target-path = "/soc/base_fpga_region";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		__overlay__ {
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			firmware-name = "soc_system.rbf";
+
+			jtag_uart: serial at 20000 {
+				compatible = "altr,juart-1.0";
+				reg = <0x20000 0x8>;
+				interrupt-parent = <&intc>;
+				interrupts = <0 42 4>;
+			};
+
+			led_pio: gpio at 10040 {
+				compatible = "altr,pio-1.0";
+				reg = <0x10040 0x20>;
+				altr,gpio-bank-width = <4>;
+				#gpio-cells = <2>;
+				gpio-controller;
+			};
+		};
+	};
+};
+
+Supported Use Models
+====================
+
+Here's a list of supported use models.  We may need to add more.  Some uses are
+specific to one FPGA device or another.
+
+In all cases the live DT must specify the FPGA Manager, FPGA Bridges (if any),
+and a FPGA Region.  The target of the Device Tree Overlay is the FPGA Region.
+
+ * No FPGA Bridges
+   In this case, the FPGA Manager which programs the FPGA also handles the
+   bridges.  No FPGA Bridge devices are needed for full reconfiguration.
+
+ * Full reconfiguration with bridges
+   In this case, there are hardware bridges between the processor and FPGA that
+   need to be disabled during full reconfiguration.  Before the overlay is
+   applied, the live DT must include the FPGA Manager, FPGA Bridges, and a
+   base FPGA Region which contains phandles to the FPGA Manager and Bridges.
+
+ * Partial reconfiguration with bridges in the FPGA
+   In this case, the FPGA will have more than one PRR that will be programmed
+   separately.  While one PRR is being programmed, other PRR's may be active
+   on the bus.  To manage this, FPGA Bridges need to exist in the FPGA
+   that can gate the buses going to one 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.  This can be done by doing full reconfiguration using an overlay
+   that contains the FPGA image that sets up the regions in the FPGA fabric.
+   The overlay would also contain FPGA Regions that will become children of
+   the original base FPGA Region.
+
+Sequence
+========
+
+When a DT overlay is loaded, the FPGA Region will be notified and will do the
+following:
+ 1. Disable the FPGA Bridges.
+ 2. Use the the FPGA manager core to program the FPGA.
+ 3. Enable the FPGA Bridges.
+ 4. Call of_platform_populate resulting in device drivers getting probed.
+
+When the overlay is removed, the FPGA Region will be notified and will disable
+the bridges and the child nodes will be removed.
+
+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: fpgamgr at 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>;
+	};
+
+	base_fpga_region {
+		compatible = "fpga-region";
+		fpga-mgr = <&fpga_mgr0>;
+		#address-cells = <0x1>;
+		#size-cells = <0x1>;
+		ranges;
+	};
+
+DT Overlay contains:
+/dts-v1/ /plugin/;
+/ {
+fragment at 0 {
+	target = <&base_fpga_region>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+	__overlay__ {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		firmware-name = "zynq-gpio.bin";
+
+		gpio1: gpio at 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 at 0 {
+		target-path = "/soc/base_fpga_region";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		__overlay__ {
+			#address-cells = <1>;
+		        #size-cells = <1>;
+
+			firmware-name = "base.rbf";
+
+			fpga_bridge1_0: fpga-bridge at 4400 {

Documentation/devicetree/bindings/fpga/fpga-region.txt new file +6 -0

+				compatible = "fpga-region";
+				fpga-bridges = <&fpga_bridge1_0>;
+				#address-cells = <0x1>;
+				#size-cells = <0x1>;
+				ranges;
+			};

Add bindings documentation for Altera SOCFPGA bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Matthew Gerlach <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

---

v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version

remove Linux specific notes such as references to sysfs move non-DT specific documentation elsewhere
remove bindings that would have been used to pass configuration clean up formatting
v13: Remove 'label' property
Change property from init-val to bridge-enable
Fix email address
v14: Add resets
Change order of bridges to put lw bridge (controlling bridge) first
v15: No change in this patch for v15 of this patch set
v16: Added regs property, cleaned up unit addresses
v17: No change to this patch in v17 of patch set
v18: Changed to not need reset-names property
node names as fpga-bridge at ...
labels as fpga_bridge
Add address of fpgaportrst to give and address for f2s bridge

---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt     | 16 +++++++++
 .../bindings/fpga/altera-hps2fpga-bridge.txt       | 39 ++++++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

Quoted 28 lines · Alan Tull

Add bindings documentation for Altera SOCFPGA bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Matthew Gerlach <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

---

v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version

remove Linux specific notes such as references to sysfs move non-DT specific documentation elsewhere
remove bindings that would have been used to pass configuration clean up formatting
v13: Remove 'label' property
Change property from init-val to bridge-enable
Fix email address
v14: Add resets
Change order of bridges to put lw bridge (controlling bridge) first
v15: No change in this patch for v15 of this patch set
v16: Added regs property, cleaned up unit addresses
v17: No change to this patch in v17 of patch set
v18: Changed to not need reset-names property
node names as fpga-bridge at ...
labels as fpga_bridge
Add address of fpgaportrst to give and address for f2s bridge

Quoted 6 lines

---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt     | 16 +++++++++
 .../bindings/fpga/altera-hps2fpga-bridge.txt       | 39 ++++++++++++++++++++++
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

Acked-by Rob Herring <[email protected]>

This framework adds API functions for enabling/ disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges during FPGA reprogramming and to enable FPGA bridges when FPGA reprogramming is done. This framework is be manufacturer-agnostic, allowing it to be used in interfaces that use the FPGA Manager Framework to reprogram FPGA's.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
Get/put an exclusive reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
Register/unregister a device-specific low level FPGA Bridge driver.

Get an exclusive reference to a bridge and add it to a list:
* fpga_bridge_get_to_list

To enable/disable/put a set of bridges that are on a list:
* fpga_bridges_enable
* fpga_bridges_disable
* fpga_bridges_put

Signed-off-by Alan Tull <[email protected]>

---

v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus

Remove sysfs
Improve get/put functions, get the low level driver too. Clean up class implementation
Add kernel doc documentation
Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
Clean up debugging
Remove unneeded #include in .h
Remove unnecessary prints
Remove 'label' DT binding.
Document the mutex
v14: Allow bridges with no ops
*const* struct fpga_bridge_ops
Add functions to git/put/enable/disable list of bridges Add list node to struct fpga_bridge
Do of_node_get/put in of_fpga_bridge_get()
Add r/o attributes: name and state
v15: No change in this patch for v15 of this patch set
v16: Remove of_get_fpga_bus function
v17: No change to this patch in v17 of patch set
v18: No change to this patch in v18 of patch set

---
 drivers/fpga/Kconfig             |   7 +
 drivers/fpga/Makefile            |   3 +
 drivers/fpga/fpga-bridge.c       | 388 +++++++++++++++++++++++++++++++++++++++
 include/linux/fpga/fpga-bridge.h |  55 ++++++
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

drivers/fpga/Kconfig +0 -0

index d614102..46e20af 100644

Quoted 74 lines · Alan Tull

This framework adds API functions for enabling/ disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges during FPGA reprogramming and to enable FPGA bridges when FPGA reprogramming is done. This framework is be manufacturer-agnostic, allowing it to be used in interfaces that use the FPGA Manager Framework to reprogram FPGA's.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
Get/put an exclusive reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
Register/unregister a device-specific low level FPGA Bridge driver.

Get an exclusive reference to a bridge and add it to a list:
* fpga_bridge_get_to_list

To enable/disable/put a set of bridges that are on a list:
* fpga_bridges_enable
* fpga_bridges_disable
* fpga_bridges_put

Signed-off-by Alan Tull <[email protected]>

---

v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus

Remove sysfs
Improve get/put functions, get the low level driver too. Clean up class implementation
Add kernel doc documentation
Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
Clean up debugging
Remove unneeded #include in .h
Remove unnecessary prints
Remove 'label' DT binding.
Document the mutex
v14: Allow bridges with no ops
*const* struct fpga_bridge_ops
Add functions to git/put/enable/disable list of bridges Add list node to struct fpga_bridge
Do of_node_get/put in of_fpga_bridge_get()
Add r/o attributes: name and state
v15: No change in this patch for v15 of this patch set
v16: Remove of_get_fpga_bus function
v17: No change to this patch in v17 of patch set
v18: No change to this patch in v18 of patch set

---
 drivers/fpga/Kconfig             |   7 +
 drivers/fpga/Makefile            |   3 +
 drivers/fpga/fpga-bridge.c       | 388 +++++++++++++++++++++++++++++++++++++++
 include/linux/fpga/fpga-bridge.h |  55 ++++++
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

drivers/fpga/Kconfig +0 -0

index d614102..46e20af 100644
@@ -25,6 +25,13 @@ config FPGA_MGR_ZYNQ_FPGA
        help
          FPGA manager driver support for Xilinx Zynq FPGAs.
 

drivers/fpga/Kconfig config FPGA_MGR_ZYNQ_FPGA · line 29

Quoted 2 lines

drivers/fpga/Kconfig +2 -0

+config FPGA_BRIDGE
+       bool "FPGA Bridge Framework"

Same here. A bool Kconfig but module.h etc. used in the driver.

Either make the code modular with a tristate if there is a valid use case for that, or get rid of the modular references.

Thanks,
Paul.
--

Supports Altera SOCFPGA bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga

Allows enabling/disabling the bridges through the FPGA Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling of the ports that been configured early on. This is due to a hardware limitation where the read, write, and command ports on the fpga2sdram bridge can only be reconfigured while there are no transactions to the sdram, i.e. when running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to enable or disable the bridge during probe. If the property does not exist, the driver will leave the bridge in its current state.

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Matthew Gerlach <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

---

v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version

Get rid of the sysfs interface
fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
Change property from init-val to bridge-enable Checkpatch cleanup
Fix email address
v14: use module_platform_driver
remove unused struct field and some #defines don't really need exclamation points on error msgs *const* struct fpga_bridge_ops
v15: No change in this patch for v15 of this patch set
v16: No change in this patch for v16 of this patch set
v17: No change to this patch for v17 of this patch set
v18: Eliminate need to specify reset names since only one reset

---
 drivers/fpga/Kconfig             |   7 ++
 drivers/fpga/Makefile            |   1 +
 drivers/fpga/altera-fpga2sdram.c | 174 ++++++++++++++++++++++++++++++++
 drivers/fpga/altera-hps2fpga.c   | 213 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

drivers/fpga/Kconfig +7 -0

index ec81e21..b346166 100644
@@ -39,6 +39,13 @@ config FPGA_BRIDGE
          Say Y here if you want to support bridges connected between host
         processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+       bool "Altera SoCFPGA FPGA Bridges"
+       depends on ARCH_SOCFPGA && FPGA_BRIDGE
+       help
+         Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+         devices.
+
 endif # FPGA
 
 endmenu

drivers/fpga/Makefile +1 -0

index 8d746c3..e658436 100644
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)      += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)              += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)      += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)              += fpga-region.o

drivers/fpga/altera-fpga2sdram.c new file +30 -0

new file mode 100644
index 0000000..91f4a40
@@ -0,0 +1,174 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *

Quoted 116 lines · Alan Tull

Supports Altera SOCFPGA bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga

Allows enabling/disabling the bridges through the FPGA Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling of the ports that been configured early on. This is due to a hardware limitation where the read, write, and command ports on the fpga2sdram bridge can only be reconfigured while there are no transactions to the sdram, i.e. when running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to enable or disable the bridge during probe. If the property does not exist, the driver will leave the bridge in its current state.

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Matthew Gerlach <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

---

v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version

Get rid of the sysfs interface
fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
Change property from init-val to bridge-enable Checkpatch cleanup
Fix email address
v14: use module_platform_driver
remove unused struct field and some #defines don't really need exclamation points on error msgs *const* struct fpga_bridge_ops
v15: No change in this patch for v15 of this patch set
v16: No change in this patch for v16 of this patch set
v17: No change to this patch for v17 of this patch set
v18: Eliminate need to specify reset names since only one reset

---
 drivers/fpga/Kconfig             |   7 ++
 drivers/fpga/Makefile            |   1 +
 drivers/fpga/altera-fpga2sdram.c | 174 ++++++++++++++++++++++++++++++++
 drivers/fpga/altera-hps2fpga.c   | 213 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

drivers/fpga/Kconfig +7 -0

index ec81e21..b346166 100644
@@ -39,6 +39,13 @@ config FPGA_BRIDGE
          Say Y here if you want to support bridges connected between host
         processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+       bool "Altera SoCFPGA FPGA Bridges"
+       depends on ARCH_SOCFPGA && FPGA_BRIDGE
+       help
+         Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+         devices.
+
 endif # FPGA
 
 endmenu

drivers/fpga/Makefile +1 -0

index 8d746c3..e658436 100644
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)      += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)              += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)      += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)              += fpga-region.o

drivers/fpga/altera-fpga2sdram.c new file +30 -0

new file mode 100644
index 0000000..91f4a40
@@ -0,0 +1,174 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *

drivers/fpga/altera-fpga2sdram.c line 40

Quoted 10 lines

drivers/fpga/altera-fpga2sdram.c new file +10 -0

+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include <linux/fpga/fpga-bridge.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h

Please don't use module.h in drivers controlled by a bool Kconfig setting.

THanks,
Paul.

Quoted 6 lines

Please don't use module.h in drivers controlled by a bool Kconfig setting.

THanks,
Paul.

Thanks for the feedback. Can you provide an example of what you would consider to be proper usage in the kernel?

Hi Alan,

Quoted 9 lines · atull

Quoted 6 lines

Please don't use module.h in drivers controlled by a bool Kconfig setting.

THanks,
Paul.

Thanks for the feedback. Can you provide an example of what you would consider to be proper usage in the kernel?

I think Paul is suggesting to use

static int __init alt_fpga_bridge_init(void)

{
        platform_driver_register(&alt_fpga_bridge_driver);
}

device_initcall(alt_fpga_bridge_init);

or better:

builtin_platform_driver(&alt_fpga_bridge_driver);

Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Cheers,

Moritz

Quoted 22 lines · [Re: [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support] On 08/08/2016…

Hi Alan,

Quoted 9 lines · atull

Quoted 6 lines

Please don't use module.h in drivers controlled by a bool Kconfig setting.

THanks,
Paul.

Thanks for the feedback. Can you provide an example of what you would consider to be proper usage in the kernel?

I think Paul is suggesting to use

static int __init alt_fpga_bridge_init(void)

{
        platform_driver_register(&alt_fpga_bridge_driver);
}

Quoted 7 lines

device_initcall(alt_fpga_bridge_init);

or better:

builtin_platform_driver(&alt_fpga_bridge_driver);

Like for example in: drivers/cpuidle/cpuidle-mvebu-v7.c

Yes, pretty much that -- if you have a bool Kconfig, you should be using builtin registration functions, and have no need for module.h or anything MODULE_<xyz> or any module_init/module_exit calls.

An empty file containing nothing but #include <linux/module.h> will cause cpp to emit about 750k of goop, so we really should only be using it for drivers that are genuinely modular; i.e. tristate Kconfig.

Thanks,
Paul.
--

Quoted 4 lines

Cheers,

Moritz

Supports Altera SOCFPGA bridges:
* fpga2sdram
* fpga2hps
* hps2fpga
* lwhps2fpga

Allows enabling/disabling the bridges through the FPGA Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling of the ports that been configured early on. This is due to a hardware limitation where the read, write, and command ports on the fpga2sdram bridge can only be reconfigured while there are no transactions to the sdram, i.e. when running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to enable or disable the bridge during probe. If the property does not exist, the driver will leave the bridge in its current state.

Signed-off-by Alan Tull <[email protected]>

Signed-off-by Matthew Gerlach <[email protected]>

Signed-off-by Dinh Nguyen <[email protected]>

drivers/fpga/altera-fpga2sdram.c new file +6 -0

+static inline int _alt_fpga2sdram_enable_set(struct alt_fpga2sdram_data *priv,
+					     bool enable)
+{
+	return regmap_update_bits(priv->sdrctl, ALT_SDR_CTL_FPGAPORTRST_OFST,
+				  priv->mask, enable ? priv->mask : 0);
+}

v18 has very minimal changes to address comments about the device tree bindings and device tree examples in the bindings document.

The diffstat from v17 is:

  4 files changed, 11 insertions(+), 18 deletions(-)

If there are more changes, it would be easier to
send these upstream and just start adding small
patches to fix whatever else.

Alan Tull (6):
fpga: add bindings document for fpga region
ARM: socfpga: add bindings document for fpga bridge drivers add sysfs document for fpga bridge class
fpga: add fpga bridge framework
fpga: fpga-region: device tree control for FPGA
ARM: socfpga: fpga bridge driver support

 Documentation/ABI/testing/sysfs-class-fpga-bridge  |  11 +
 .../bindings/fpga/altera-fpga2sdram-bridge.txt     |  16 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt       |  39 ++
 .../devicetree/bindings/fpga/fpga-region.txt       | 491 ++++++++++++++++++
 drivers/fpga/Kconfig                               |  21 +
 drivers/fpga/Makefile                              |   7 +
 drivers/fpga/altera-fpga2sdram.c                   | 174 +++++++
 drivers/fpga/altera-hps2fpga.c                     | 213 ++++++++
 drivers/fpga/fpga-bridge.c                         | 388 ++++++++++++++
 drivers/fpga/fpga-region.c                         | 555 +++++++++++++++++++++
 include/linux/fpga/fpga-bridge.h                   |  55 ++
 include/linux/fpga/fpga-mgr.h                      |   2 +
 12 files changed, 1972 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 drivers/fpga/fpga-region.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

Signature · 1 line

2.9.1