Merge tag 'drm-misc-next-2021-04-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (1539f716) · Commits · EulixOS / Software / Kernel

Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml

+15 −0

Original line number	Diff line number	Diff line
		@@ -34,6 +34,15 @@ properties:
		description: used for reset chip control, RESET_N pin B7.
		maxItems: 1

		vdd10-supply:
		description: Regulator that provides the supply 1.0V power.

		vdd18-supply:
		description: Regulator that provides the supply 1.8V power.

		vdd33-supply:
		description: Regulator that provides the supply 3.3V power.

		ports:
		$ref: /schemas/graph.yaml#/properties/ports

		@@ -55,6 +64,9 @@ properties:
		required:
		- compatible
		- reg
		- vdd10-supply
		- vdd18-supply
		- vdd33-supply
		- ports

		additionalProperties: false
		@@ -72,6 +84,9 @@ examples:
		reg = <0x58>;
		enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
		reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
		vdd10-supply = <&pp1000_mipibrdg>;
		vdd18-supply = <&pp1800_mipibrdg>;
		vdd33-supply = <&pp3300_mipibrdg>;

		ports {
		#address-cells = <1>;

Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml

0 → 100644

+99 −0

Original line number	Diff line number	Diff line
		# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
		%YAML 1.2
		---
		$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
		$schema: http://devicetree.org/meta-schemas/core.yaml#

		title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge

		maintainers:
		- Jagan Teki <jagan@amarulasolutions.com>

		description: \|
		ICN6211 is MIPI-DSI to RGB Converter bridge from chipone.

		It has a flexible configuration of MIPI DSI signal input and
		produce RGB565, RGB666, RGB888 output format.

		properties:
		compatible:
		enum:
		- chipone,icn6211

		reg:
		maxItems: 1
		description: virtual channel number of a DSI peripheral

		enable-gpios:
		description: Bridge EN pin, chip is reset when EN is low.

		vdd1-supply:
		description: A 1.8V/2.5V/3.3V supply that power the MIPI RX.

		vdd2-supply:
		description: A 1.8V/2.5V/3.3V supply that power the PLL.

		vdd3-supply:
		description: A 1.8V/2.5V/3.3V supply that power the RGB output.

		ports:
		$ref: /schemas/graph.yaml#/properties/ports

		properties:
		port@0:
		$ref: /schemas/graph.yaml#/properties/port
		description:
		Video port for MIPI DSI input

		port@1:
		$ref: /schemas/graph.yaml#/properties/port
		description:
		Video port for MIPI DPI output (panel or connector).

		required:
		- port@0
		- port@1

		required:
		- compatible
		- reg
		- enable-gpios
		- ports

		additionalProperties: false

		examples:
		- \|
		#include <dt-bindings/gpio/gpio.h>

		dsi {
		#address-cells = <1>;
		#size-cells = <0>;

		bridge@0 {
		compatible = "chipone,icn6211";
		reg = <0>;
		enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */

		ports {
		#address-cells = <1>;
		#size-cells = <0>;

		port@0 {
		reg = <0>;

		bridge_in_dsi: endpoint {
		remote-endpoint = <&dsi_out_bridge>;
		};
		};

		port@1 {
		reg = <1>;

		bridge_out_panel: endpoint {
		remote-endpoint = <&panel_out_bridge>;
		};
		};
		};
		};
		};

Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml

0 → 100644

+102 −0

Original line number	Diff line number	Diff line
		# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
		%YAML 1.2
		---
		$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912b.yaml#
		$schema: http://devicetree.org/meta-schemas/core.yaml#

		title: Lontium LT8912B MIPI to HDMI Bridge

		maintainers:
		- Adrien Grassein <adrien.grassein@gmail.com>

		description: \|
		The LT8912B is a bridge device which convert DSI to HDMI

		properties:
		compatible:
		enum:
		- lontium,lt8912b

		reg:
		maxItems: 1

		reset-gpios:
		maxItems: 1
		description: GPIO connected to active high RESET pin.

		ports:
		$ref: /schemas/graph.yaml#/properties/ports

		properties:
		port@0:
		$ref: /schemas/graph.yaml#/properties/port
		description:
		Primary MIPI port for MIPI input

		properties:
		endpoint:
		$ref: /schemas/media/video-interfaces.yaml#
		unevaluatedProperties: false

		properties:
		data-lanes: true

		required:
		- data-lanes

		port@1:
		$ref: /schemas/graph.yaml#/properties/port
		description: \|
		HDMI port, should be connected to a node compatible with the
		hdmi-connector binding.

		required:
		- port@0
		- port@1

		required:
		- compatible
		- reg
		- reset-gpios
		- ports

		additionalProperties: false

		examples:
		- \|
		#include <dt-bindings/gpio/gpio.h>

		i2c4 {
		#address-cells = <1>;
		#size-cells = <0>;

		hdmi-bridge@48 {
		compatible = "lontium,lt8912b";
		reg = <0x48>;
		reset-gpios = <&max7323 0 GPIO_ACTIVE_LOW>;

		ports {
		#address-cells = <1>;
		#size-cells = <0>;

		port@0 {
		reg = <0>;

		hdmi_out_in: endpoint {
		data-lanes = <0 1 2 3>;
		remote-endpoint = <&mipi_dsi_out>;
		};
		};

		port@1 {
		reg = <1>;

		endpoint {
		remote-endpoint = <&hdmi_in>;
		};
		};
		};
		};
		};

		...

Documentation/devicetree/bindings/display/panel/panel-simple.yaml

+2 −0

Original line number	Diff line number	Diff line
		@@ -161,6 +161,8 @@ properties:
		# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
		- innolux,g121x1-l03
		# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
		- innolux,n116bca-ea1
		# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
		- innolux,n116bge
		# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
		- innolux,n125hce-gn1

Documentation/driver-api/dma-buf.rst

+76 −0

Original line number	Diff line number	Diff line
		@@ -257,3 +257,79 @@ fences in the kernel. This means:
		userspace is allowed to use userspace fencing or long running compute
		workloads. This also means no implicit fencing for shared buffers in these
		cases.

		Recoverable Hardware Page Faults Implications
		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

		Modern hardware supports recoverable page faults, which has a lot of
		implications for DMA fences.

		First, a pending page fault obviously holds up the work that's running on the
		accelerator and a memory allocation is usually required to resolve the fault.
		But memory allocations are not allowed to gate completion of DMA fences, which
		means any workload using recoverable page faults cannot use DMA fences for
		synchronization. Synchronization fences controlled by userspace must be used
		instead.

		On GPUs this poses a problem, because current desktop compositor protocols on
		Linux rely on DMA fences, which means without an entirely new userspace stack
		built on top of userspace fences, they cannot benefit from recoverable page
		faults. Specifically this means implicit synchronization will not be possible.
		The exception is when page faults are only used as migration hints and never to
		on-demand fill a memory request. For now this means recoverable page
		faults on GPUs are limited to pure compute workloads.

		Furthermore GPUs usually have shared resources between the 3D rendering and
		compute side, like compute units or command submission engines. If both a 3D
		job with a DMA fence and a compute workload using recoverable page faults are
		pending they could deadlock:

		- The 3D workload might need to wait for the compute job to finish and release
		hardware resources first.

		- The compute workload might be stuck in a page fault, because the memory
		allocation is waiting for the DMA fence of the 3D workload to complete.

		There are a few options to prevent this problem, one of which drivers need to
		ensure:

		- Compute workloads can always be preempted, even when a page fault is pending
		and not yet repaired. Not all hardware supports this.

		- DMA fence workloads and workloads which need page fault handling have
		independent hardware resources to guarantee forward progress. This could be
		achieved through e.g. through dedicated engines and minimal compute unit
		reservations for DMA fence workloads.

		- The reservation approach could be further refined by only reserving the
		hardware resources for DMA fence workloads when they are in-flight. This must
		cover the time from when the DMA fence is visible to other threads up to
		moment when fence is completed through dma_fence_signal().

		- As a last resort, if the hardware provides no useful reservation mechanics,
		all workloads must be flushed from the GPU when switching between jobs
		requiring DMA fences or jobs requiring page fault handling: This means all DMA
		fences must complete before a compute job with page fault handling can be
		inserted into the scheduler queue. And vice versa, before a DMA fence can be
		made visible anywhere in the system, all compute workloads must be preempted
		to guarantee all pending GPU page faults are flushed.

		- Only a fairly theoretical option would be to untangle these dependencies when
		allocating memory to repair hardware page faults, either through separate
		memory blocks or runtime tracking of the full dependency graph of all DMA
		fences. This results very wide impact on the kernel, since resolving the page
		on the CPU side can itself involve a page fault. It is much more feasible and
		robust to limit the impact of handling hardware page faults to the specific
		driver.

		Note that workloads that run on independent hardware like copy engines or other
		GPUs do not have any impact. This allows us to keep using DMA fences internally
		in the kernel even for resolving hardware page faults, e.g. by using copy
		engines to clear or copy memory needed to resolve the page fault.

		In some ways this page fault problem is a special case of the `Infinite DMA
		Fences` discussions: Infinite fences from compute workloads are allowed to
		depend on DMA fences, but not the other way around. And not even the page fault
		problem is new, because some other CPU thread in userspace might
		hit a page fault which holds up a userspace fence - supporting page faults on
		GPUs doesn't anything fundamentally new.