diff options
Diffstat (limited to 'Documentation/firmware-guide/acpi/dsd')
| -rw-r--r-- | Documentation/firmware-guide/acpi/dsd/data-node-references.rst | 94 | ||||
| -rw-r--r-- | Documentation/firmware-guide/acpi/dsd/graph.rst | 170 | ||||
| -rw-r--r-- | Documentation/firmware-guide/acpi/dsd/leds.rst | 102 | ||||
| -rw-r--r-- | Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst | 107 | ||||
| -rw-r--r-- | Documentation/firmware-guide/acpi/dsd/phy.rst | 201 |
5 files changed, 674 insertions, 0 deletions
diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst new file mode 100644 index 000000000..ccb4b153e --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -0,0 +1,94 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=================================== +Referencing hierarchical data nodes +=================================== + +:Copyright: |copy| 2018, 2021 Intel Corporation +:Author: Sakari Ailus <sakari.ailus@linux.intel.com> + +ACPI in general allows referring to device objects in the tree only. +Hierarchical data extension nodes may not be referred to directly, hence this +document defines a scheme to implement such references. + +A reference to a _DSD hierarchical data node is a string consisting of a +device object reference followed by a dot (".") and a relative path to a data +node object. Do not use non-string references as this will produce a copy of +the hierarchical data node, not a reference! + +The hierarchical data extension node which is referred to shall be located +directly under its parent object i.e. either the device object or another +hierarchical data extension node [dsd-guide]. + +The keys in the hierarchical data nodes shall consist of the name of the node, +"@" character and the number of the node in hexadecimal notation (without pre- +or postfixes). The same ACPI object shall include the _DSD property extension +with a property "reg" that shall have the same numerical value as the number of +the node. + +In case a hierarchical data extensions node has no numerical value, then the +"reg" property shall be omitted from the ACPI object's _DSD properties and the +"@" character and the number shall be omitted from the hierarchical data +extension key. + + +Example +======= + +In the ASL snippet below, the "reference" _DSD property contains a string +reference to a hierarchical data extension node ANOD under DEV0 under the parent +of DEV1. ANOD is also the final target node of the reference. +:: + + Device (DEV0) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "node@0", "NOD0" }, + Package () { "node@1", "NOD1" }, + } + }) + Name (NOD0, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "random-property", 3 }, + } + }) + Name (NOD1, Package() { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "reg", 1 }, + Package () { "anothernode", "ANOD" }, + } + }) + Name (ANOD, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "random-property", 0 }, + } + }) + } + + Device (DEV1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reference", "^DEV0.ANOD" } + }, + } + }) + } + +Please also see a graph example in +Documentation/firmware-guide/acpi/dsd/graph.rst. + +References +========== + +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst new file mode 100644 index 000000000..d6ae5ffa7 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====== +Graphs +====== + +_DSD +==== + +_DSD (Device Specific Data) [dsd-guide] is a predefined ACPI device +configuration object that can be used to convey information on +hardware features which are not specifically covered by the ACPI +specification [acpi]. There are two _DSD extensions that are relevant +for graphs: property [dsd-guide] and hierarchical data extensions. The +property extension provides generic key-value pairs whereas the +hierarchical data extension supports nodes with references to other +nodes, forming a tree. The nodes in the tree may contain properties as +defined by the property extension. The two extensions together provide +a tree-like structure with zero or more properties (key-value pairs) +in each node of the tree. + +The data structure may be accessed at runtime by using the device_* +and fwnode_* functions defined in include/linux/fwnode.h . + +Fwnode represents a generic firmware node object. It is independent on +the firmware type. In ACPI, fwnodes are _DSD hierarchical data +extensions objects. A device's _DSD object is represented by an +fwnode. + +The data structure may be referenced to elsewhere in the ACPI tables +by using a hard reference to the device itself and an index to the +hierarchical data extension array on each depth. + + +Ports and endpoints +=================== + +The port and endpoint concepts are very similar to those in Devicetree +[devicetree, graph-bindings]. A port represents an interface in a device, and +an endpoint represents a connection to that interface. Also see [data-node-ref] +for generic data node references. + +All port nodes are located under the device's "_DSD" node in the hierarchical +data extension tree. The data extension related to each port node must begin +with "port" and must be followed by the "@" character and the number of the +port as its key. The target object it refers to should be called "PRTX", where +"X" is the number of the port. An example of such a package would be:: + + Package() { "port@4", "PRT4" } + +Further on, endpoints are located under the port nodes. The hierarchical +data extension key of the endpoint nodes must begin with +"endpoint" and must be followed by the "@" character and the number of the +endpoint. The object it refers to should be called "EPXY", where "X" is the +number of the port and "Y" is the number of the endpoint. An example of such a +package would be:: + + Package() { "endpoint@0", "EP40" } + +Each port node contains a property extension key "port", the value of which is +the number of the port. Each endpoint is similarly numbered with a property +extension key "reg", the value of which is the number of the endpoint. Port +numbers must be unique within a device and endpoint numbers must be unique +within a port. If a device object may only has a single port, then the number +of that port shall be zero. Similarly, if a port may only have a single +endpoint, the number of that endpoint shall be zero. + +The endpoint reference uses property extension with "remote-endpoint" property +name followed by a string reference in the same package. [data-node-ref]:: + + "device.datanode" + +In the above example, "X" is the number of the port and "Y" is the number of +the endpoint. + +The references to endpoints must be always done both ways, to the +remote endpoint and back from the referred remote endpoint node. + +A simple example of this is show below:: + + Scope (\_SB.PCI0.I2C2) + { + Device (CAM0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "compatible", Package () { "nokia,smia" } }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@0", "PRT0" }, + } + }) + Name (PRT0, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", "EP00" }, + } + }) + Name (EP00, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", "\\_SB.PCI0.ISP.EP40" }, + } + }) + } + } + + Scope (\_SB.PCI0) + { + Device (ISP) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@4", "PRT4" }, + } + }) + + Name (PRT4, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 4 }, /* CSI-2 port number */ + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", "EP40" }, + } + }) + + Name (EP40, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", "\\_SB.PCI0.I2C2.CAM0.EP00" }, + } + }) + } + } + +Here, the port 0 of the "CAM0" device is connected to the port 4 of +the "ISP" device and vice versa. + + +References +========== + +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. + +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst + +[devicetree] Devicetree. https://www.devicetree.org, referenced 2016-10-03. + +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. + +[dsd-rules] _DSD Device Properties Usage Rules. + Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[graph-bindings] Common bindings for device graphs (Devicetree). + https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml, + referenced 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst new file mode 100644 index 000000000..a97cd07d4 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/leds.rst @@ -0,0 +1,102 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +======================================== +Describing and referring to LEDs in ACPI +======================================== + +Individual LEDs are described by hierarchical data extension [5] nodes under the +device node, the LED driver chip. The "reg" property in the LED specific nodes +tells the numerical ID of each individual LED output to which the LEDs are +connected. [leds] The hierarchical data nodes are named "led@X", where X is the +number of the LED output. + +Referring to LEDs in Device tree is documented in [video-interfaces], in +"flash-leds" property documentation. In short, LEDs are directly referred to by +using phandles. + +ACPI allows (as does DT) using integer arguments after the reference. A +combination of the LED driver device reference and an integer argument, +referring to the "reg" property of the relevant LED, is used to identify +individual LEDs. The value of the "reg" property is a contract between the +firmware and software, it uniquely identifies the LED driver outputs. + +Under the LED driver device, The first hierarchical data extension package list +entry shall contain the string "led@" followed by the number of the LED, +followed by the referred object name. That object shall be named "LED" followed +by the number of the LED. + +Example +======= + +An ASL example of a camera sensor device and a LED driver device for two LEDs is +show below. Objects not relevant for LEDs or the references to them have been +omitted. :: + + Device (LED) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "led@0", LED0 }, + Package () { "led@1", LED1 }, + } + }) + Name (LED0, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "flash-max-microamp", 1000000 }, + Package () { "flash-timeout-us", 200000 }, + Package () { "led-max-microamp", 100000 }, + Package () { "label", "white:flash" }, + } + }) + Name (LED1, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 1 }, + Package () { "led-max-microamp", 10000 }, + Package () { "label", "red:indicator" }, + } + }) + } + + Device (SEN) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { + "flash-leds", + Package () { "^LED.LED0", "^LED.LED1" }, + } + } + }) + } + +where +:: + + LED LED driver device + LED0 First LED + LED1 Second LED + SEN Camera sensor device (or another device the LED is related to) + +References +========== + +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. + +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst + +[devicetree] Devicetree. https://www.devicetree.org, referenced 2019-02-21. + +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. + +[leds] Documentation/devicetree/bindings/leds/common.yaml + +[video-interfaces] Documentation/devicetree/bindings/media/video-interfaces.yaml diff --git a/Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst b/Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst new file mode 100644 index 000000000..d64a396fa --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst @@ -0,0 +1,107 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Motorcomm yt8xxx PHY properties (_DSD) +====================================== + +This document describes ACPI _DSD device properties for Motorcomm yt8xxx +Ethernet PHYs supported by the in-kernel driver in +``drivers/net/phy/motorcomm.c``. + +The properties are exposed on the PHY device object under the MDIO bus ACPI +device (the same objects that are registered via +``fwnode_mdiobus_register_phy()``). MAC-side connection properties such as +``phy-handle`` and ``phy-mode`` are documented in [acpi-mdio-phy]_. + +Property names and semantics are intentionally aligned with the Devicetree +binding [motorcomm-yt8xxx]_ so that the same driver code path +(``device_property_*`` on ``&phydev->mdio.dev``) can consume firmware +described either as Devicetree or ACPI _DSD. + +UUID and placement +================== + +Per [acpi-dsd-properties-rules]_ and [acpi-mdio-phy]_, properties must be +placed in an _DSD package using the standard Device Properties UUID:: + + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") + +Properties +========== + +Unless noted otherwise, integer properties use the same allowed values and +defaults as [motorcomm-yt8xxx]_. + +``rx-internal-delay-ps`` (u32, optional) + RGMII RX internal delay in picoseconds. Only meaningful when the link is + using RGMII modes with RX internal delay; see [motorcomm-yt8xxx]_. + +``tx-internal-delay-ps`` (u32, optional) + RGMII TX internal delay in picoseconds. Only meaningful when the link is + using RGMII modes with TX internal delay; see [motorcomm-yt8xxx]_. + +``motorcomm,clk-out-frequency-hz`` (u32, optional) + Clock output frequency on the PHY clock output pin. Allowed values and + default are defined in [motorcomm-yt8xxx]_. + +``motorcomm,keep-pll-enabled`` (boolean, optional) + If true, keep the PLL enabled even when there is no link (useful for using + the clock output without an Ethernet link). See [motorcomm-yt8xxx]_. + +``motorcomm,auto-sleep-disabled`` (boolean, optional) + If true, disable the PHY auto-sleep behavior described in + [motorcomm-yt8xxx]_. + +``motorcomm,rx-clk-drv-microamp`` (u32, optional) + Drive strength for the ``rx_clk`` RGMII pad in microamps. Allowed values + depend on the configured RGMII LDO voltage; see [motorcomm-yt8xxx]_. + +``motorcomm,rx-data-drv-microamp`` (u32, optional) + Drive strength for the ``rx_data`` and ``rx_ctl`` RGMII pads in microamps. + See [motorcomm-yt8xxx]_. + +``motorcomm,tx-clk-adj-enabled`` (boolean, optional) + Enables adjustments related to ``motorcomm,tx-clk-*-inverted`` usage; see + [motorcomm-yt8xxx]_. + +``motorcomm,tx-clk-10-inverted`` (boolean, optional) +``motorcomm,tx-clk-100-inverted`` (boolean, optional) +``motorcomm,tx-clk-1000-inverted`` (boolean, optional) + Per-speed TX clock inversion options; see [motorcomm-yt8xxx]_. + +ASL example (illustrative) +========================== + +The example below only shows PHY-local _DSD properties. A real platform +still needs a MAC ``phy-handle`` and ``phy-mode`` package as in +[acpi-mdio-phy]_. + +.. code-block:: none + + Scope (\_SB.MDI0) + { + Device (PHY4) + { + Name (_ADR, 0x4) + + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) { "rx-internal-delay-ps", 2100 }, + Package (2) { "tx-internal-delay-ps", 150 }, + Package (2) { "motorcomm,clk-out-frequency-hz", 0 }, + Package (2) { "motorcomm,keep-pll-enabled", 1 }, + Package (2) { "motorcomm,auto-sleep-disabled", 1 }, + } + }) + } + } + +References +========== + +.. [acpi-mdio-phy] Documentation/firmware-guide/acpi/dsd/phy.rst +.. [acpi-dsd-properties-rules] + Documentation/firmware-guide/acpi/DSD-properties-rules.rst +.. [motorcomm-yt8xxx] + Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst new file mode 100644 index 000000000..673ac374f --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -0,0 +1,201 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +MDIO bus and PHYs in ACPI +========================= + +The PHYs on an MDIO bus [phy] are probed and registered using +fwnode_mdiobus_register_phy(). + +Later, for connecting these PHYs to their respective MACs, the PHYs registered +on the MDIO bus have to be referenced. + +This document introduces two _DSD properties that are to be used +for connecting PHYs on the MDIO bus [dsd-properties-rules] to the MAC layer. + +These properties are defined in accordance with the "Device +Properties UUID For _DSD" [dsd-guide] document and the +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device +Data Descriptors containing them. + +phy-handle +---------- +For each MAC node, a device property "phy-handle" is used to reference +the PHY that is registered on an MDIO bus. This is mandatory for +network interfaces that have PHYs connected to MAC via MDIO bus. + +During the MDIO bus driver initialization, PHYs on this bus are probed +using the _ADR object as shown below and are registered on the MDIO bus. + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +Later, during the MAC driver initialization, the registered PHY devices +have to be retrieved from the MDIO bus. For this, the MAC driver needs +references to the previously registered PHYs which are provided +as device object references (e.g. \_SB.MDI0.PHY1). + +phy-mode +-------- +The "phy-mode" _DSD property is used to describe the connection to +the PHY. The valid values for "phy-mode" are defined in [ethernet-controller]. + +managed +------- +Optional property, which specifies the PHY management type. +The valid values for "managed" are defined in [ethernet-controller]. + +fixed-link +---------- +The "fixed-link" is described by a data-only subnode of the +MAC port, which is linked in the _DSD package via +hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b +in accordance with [dsd-guide] "_DSD Implementation Guide" document). +The subnode should comprise a required property ("speed") and +possibly the optional ones - complete list of parameters and +their values are specified in [ethernet-controller]. + +The following ASL example illustrates the usage of these properties. + +DSDT entry for MDIO node +------------------------ + +The MDIO bus has an SoC component (MDIO controller) and a platform +component (PHYs on the MDIO bus). + +a) Silicon Component +This node describes the MDIO controller, MDI0 +--------------------------------------------- + +.. code-block:: none + + Scope(_SB) + { + Device(MDI0) { + Name(_HID, "NXP0006") + Name(_CCA, 1) + Name(_UID, 0) + Name(_CRS, ResourceTemplate() { + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) + { + MDI0_IT + } + }) // end of _CRS for MDI0 + } // end of MDI0 + } + +b) Platform Component +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 +--------------------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +DSDT entries representing MAC nodes +----------------------------------- + +Below are the MAC nodes where PHY nodes are referenced. +phy-mode and phy-handle are used as explained earlier. +------------------------------------------------------ + +.. code-block:: none + + Scope(\_SB.MCE0.PR17) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY1} + } + }) + } + + Scope(\_SB.MCE0.PR18) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} + } + }) + } + +MAC node example where "managed" property is specified. +------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + Package () {"managed", "in-band-status"} + } + }) + } + +MAC node example with a "fixed-link" subnode. +--------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () {"fixed-link", "LNK0"} + } + }) + Name (LNK0, Package(){ // Data-only subnode of port + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"speed", 1000}, + Package () {"full-duplex", 1} + } + }) + } + +References +========== + +[phy] Documentation/networking/phy.rst + +[dsd-properties-rules] + Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[ethernet-controller] + Documentation/devicetree/bindings/net/ethernet-controller.yaml + +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. |