[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

This adds bindings for a virtual display to be used with displays
inside entirely virtual environments which do not emulate things
like monitors but just need timing information to be supplied to
its display controller.

This is inspired by earlier work by Liviu Dudau.

Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
new file mode 100644
index 000000000000..ea4f5a91ab94
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
@@ -0,0 +1,62 @@
+Virtual Display Bridge
+
+This represents a display that is contained within an emulated
+environment.
+
+This means that the display engine mainly expects some timing
+parameters to be written into it, and after that the emulator will
+respond by creating a virtual display with the requested
+resolution characteristics.
+
+As the operating system cannot "detect" such a display, rather the
+emulator will respond to what the controller outputs, a
+chicken-and-egg problem needs to be solved: the resolution and
+timing characteristics need to be defined and set up somewhere.
+
+The virtual display bridge solves this by defining a bridge with
+all timing characteristics encoded into the device tree node.
+
+Required properies:
+- compatible: shall be "virtual-display-bridge"
+
+Required subnodes:
+- display-timings: contains in turn a display timing node
+  see display-timing.txt
+- ports: contains the display ports, see media/video-interfaces.txt
+
+Example:
+
+bridge {
+	compatible = "virtual-display-bridge";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	display-timings {
+		/* Some standard VGA timing */
+		timing0 {
+			clock-frequency = <23750>;
+			hactive = <640>;
+			vactive = <480>;
+			hfront-porch = <48>;
+			hback-porch = <16>;
+			hsync-len = <96>;
+			vfront-porch = <33>;
+			vback-porch = <9>;
+			vsync-len = <3>;
+			vrefresh = <60>;
+		};
+	};
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			display_bridge_in: endpoint {
+				remote-endpoint = <&foo>;
+			};
+		};
+	};
+};
-- 
2.17.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

This adds bindings for a virtual display to be used with displays
inside entirely virtual environments which do not emulate things
like monitors but just need timing information to be supplied to
its display controller.

This is inspired by earlier work by Liviu Dudau.

Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Ryan Harkin <ryan.harkin@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
new file mode 100644
index 000000000000..ea4f5a91ab94
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
@@ -0,0 +1,62 @@
+Virtual Display Bridge
+
+This represents a display that is contained within an emulated
+environment.
+
+This means that the display engine mainly expects some timing
+parameters to be written into it, and after that the emulator will
+respond by creating a virtual display with the requested
+resolution characteristics.
+
+As the operating system cannot "detect" such a display, rather the
+emulator will respond to what the controller outputs, a
+chicken-and-egg problem needs to be solved: the resolution and
+timing characteristics need to be defined and set up somewhere.
+
+The virtual display bridge solves this by defining a bridge with
+all timing characteristics encoded into the device tree node.
+
+Required properies:
+- compatible: shall be "virtual-display-bridge"
+
+Required subnodes:
+- display-timings: contains in turn a display timing node
+  see display-timing.txt
+- ports: contains the display ports, see media/video-interfaces.txt
+
+Example:
+
+bridge {
+	compatible = "virtual-display-bridge";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	display-timings {
+		/* Some standard VGA timing */
+		timing0 {
+			clock-frequency = <23750>;
+			hactive = <640>;
+			vactive = <480>;
+			hfront-porch = <48>;
+			hback-porch = <16>;
+			hsync-len = <96>;
+			vfront-porch = <33>;
+			vback-porch = <9>;
+			vsync-len = <3>;
+			vrefresh = <60>;
+		};
+	};
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port at 0 {
+			reg = <0>;
+
+			display_bridge_in: endpoint {
+				remote-endpoint = <&foo>;
+			};
+		};
+	};
+};
-- 
2.17.1

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 24.08.2018 14:23, Linus Walleij wrote:
> This adds bindings for a virtual display to be used with displays
> inside entirely virtual environments which do not emulate things
> like monitors but just need timing information to be supplied to
> its display controller.
>
> This is inspired by earlier work by Liviu Dudau.

If this is pure virtual then it should be connected to other pure
virtual components.
What will be this virtual bridge attached to? I expect some virtual
encoder, virtual crtc? If yes then why don't you create whole virtual
drm pipeline in one patchset?
Could you describe more what do you want to do.
And one more thing, you are defining virtual panel but you are using
drm_bridge framework, why not drm_panel?

Regards
Andrzej

>
> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> Cc: Ryan Harkin <ryan.harkin@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
>  1 file changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> new file mode 100644
> index 000000000000..ea4f5a91ab94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> @@ -0,0 +1,62 @@
> +Virtual Display Bridge
> +
> +This represents a display that is contained within an emulated
> +environment.
> +
> +This means that the display engine mainly expects some timing
> +parameters to be written into it, and after that the emulator will
> +respond by creating a virtual display with the requested
> +resolution characteristics.
> +
> +As the operating system cannot "detect" such a display, rather the
> +emulator will respond to what the controller outputs, a
> +chicken-and-egg problem needs to be solved: the resolution and
> +timing characteristics need to be defined and set up somewhere.
> +
> +The virtual display bridge solves this by defining a bridge with
> +all timing characteristics encoded into the device tree node.
> +
> +Required properies:
> +- compatible: shall be "virtual-display-bridge"
> +
> +Required subnodes:
> +- display-timings: contains in turn a display timing node
> +  see display-timing.txt
> +- ports: contains the display ports, see media/video-interfaces.txt
> +
> +Example:
> +
> +bridge {
> +	compatible = "virtual-display-bridge";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	display-timings {
> +		/* Some standard VGA timing */
> +		timing0 {
> +			clock-frequency = <23750>;
> +			hactive = <640>;
> +			vactive = <480>;
> +			hfront-porch = <48>;
> +			hback-porch = <16>;
> +			hsync-len = <96>;
> +			vfront-porch = <33>;
> +			vback-porch = <9>;
> +			vsync-len = <3>;
> +			vrefresh = <60>;
> +		};
> +	};
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port@0 {
> +			reg = <0>;
> +
> +			display_bridge_in: endpoint {
> +				remote-endpoint = <&foo>;
> +			};
> +		};
> +	};
> +};


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 24.08.2018 14:23, Linus Walleij wrote:
> This adds bindings for a virtual display to be used with displays
> inside entirely virtual environments which do not emulate things
> like monitors but just need timing information to be supplied to
> its display controller.
>
> This is inspired by earlier work by Liviu Dudau.

If this is pure virtual then it should be connected to other pure
virtual components.
What will be this virtual bridge attached to? I expect some virtual
encoder, virtual crtc? If yes then why don't you create whole virtual
drm pipeline in one patchset?
Could you describe more what do you want to do.
And one more thing, you are defining virtual panel but you are using
drm_bridge framework, why not drm_panel?

Regards
Andrzej

>
> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> Cc: Ryan Harkin <ryan.harkin@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
>  1 file changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> new file mode 100644
> index 000000000000..ea4f5a91ab94
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> @@ -0,0 +1,62 @@
> +Virtual Display Bridge
> +
> +This represents a display that is contained within an emulated
> +environment.
> +
> +This means that the display engine mainly expects some timing
> +parameters to be written into it, and after that the emulator will
> +respond by creating a virtual display with the requested
> +resolution characteristics.
> +
> +As the operating system cannot "detect" such a display, rather the
> +emulator will respond to what the controller outputs, a
> +chicken-and-egg problem needs to be solved: the resolution and
> +timing characteristics need to be defined and set up somewhere.
> +
> +The virtual display bridge solves this by defining a bridge with
> +all timing characteristics encoded into the device tree node.
> +
> +Required properies:
> +- compatible: shall be "virtual-display-bridge"
> +
> +Required subnodes:
> +- display-timings: contains in turn a display timing node
> +  see display-timing.txt
> +- ports: contains the display ports, see media/video-interfaces.txt
> +
> +Example:
> +
> +bridge {
> +	compatible = "virtual-display-bridge";
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	display-timings {
> +		/* Some standard VGA timing */
> +		timing0 {
> +			clock-frequency = <23750>;
> +			hactive = <640>;
> +			vactive = <480>;
> +			hfront-porch = <48>;
> +			hback-porch = <16>;
> +			hsync-len = <96>;
> +			vfront-porch = <33>;
> +			vback-porch = <9>;
> +			vsync-len = <3>;
> +			vrefresh = <60>;
> +		};
> +	};
> +
> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		port at 0 {
> +			reg = <0>;
> +
> +			display_bridge_in: endpoint {
> +				remote-endpoint = <&foo>;
> +			};
> +		};
> +	};
> +};

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> On 24.08.2018 14:23, Linus Walleij wrote:
> > This adds bindings for a virtual display to be used with displays
> > inside entirely virtual environments which do not emulate things
> > like monitors but just need timing information to be supplied to
> > its display controller.
> >
> > This is inspired by earlier work by Liviu Dudau.
>
> If this is pure virtual then it should be connected to other pure
> virtual components.

OK it's a bit of half-half but outside of my grasp, I am just trying
to support legacy systems.

The device tree is there:
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi

The latter contains the CLCD which is the display driver.

In RTSM, which is an ARM product I do not develop and
cannot make changes to, there is an emulated CLCD. So
that part appear as if it was real hardware. Like in QEMU.

But the display does not have any emulation. The raw
output from the CLCD is latched out to the screen.

I do not know exactly know how the RTSM emulator
actually works, but I suspect that the little graphic window
on the screeen adapts to what gets written into the
CLCD control registers, so anything goes, more or less.

To satisfy the CLCD with some timings and resolution,
this bridge gives it that, from the device tree, in a way
that clearly conveys that "this is not a real thing".

The old code uses DPI. This is not DPI, not even close
to it. It worked simply because all the DPI really does is
what this patch does: provide timings.

By contrast on QEMU I have patches the emulator to
properly represent the I2C DDC link and provide EDID
so that is all fine.

I cannot patch RTSM to emulate I2C and DDC. It's not
open source. But the device tree in the kernel supports
this "machine" and so, I have to maintain it when modernizng
the fbdev driver to a DRM driver.

I'm sorry RTSM is half/half. Not my fault. I can't fix...

> And one more thing, you are defining virtual panel but you are using
> drm_bridge framework, why not drm_panel?

This was discussed before in the previous patch set:
https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html

Essentially, it's because the display driver is just connected
to "something" not a panel and a bridge is likely the best I
can come up with - a bridge over to a virtual display.

A patch to add "VGA", "SGA" and "XGA" to the simple panels
was NACKed (sort of, politely):
https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html

Also it was noted that it would be nice to have something that
would make it easy to change resolutions on these virtual
display things. Voila.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> On 24.08.2018 14:23, Linus Walleij wrote:
> > This adds bindings for a virtual display to be used with displays
> > inside entirely virtual environments which do not emulate things
> > like monitors but just need timing information to be supplied to
> > its display controller.
> >
> > This is inspired by earlier work by Liviu Dudau.
>
> If this is pure virtual then it should be connected to other pure
> virtual components.

OK it's a bit of half-half but outside of my grasp, I am just trying
to support legacy systems.

The device tree is there:
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi

The latter contains the CLCD which is the display driver.

In RTSM, which is an ARM product I do not develop and
cannot make changes to, there is an emulated CLCD. So
that part appear as if it was real hardware. Like in QEMU.

But the display does not have any emulation. The raw
output from the CLCD is latched out to the screen.

I do not know exactly know how the RTSM emulator
actually works, but I suspect that the little graphic window
on the screeen adapts to what gets written into the
CLCD control registers, so anything goes, more or less.

To satisfy the CLCD with some timings and resolution,
this bridge gives it that, from the device tree, in a way
that clearly conveys that "this is not a real thing".

The old code uses DPI. This is not DPI, not even close
to it. It worked simply because all the DPI really does is
what this patch does: provide timings.

By contrast on QEMU I have patches the emulator to
properly represent the I2C DDC link and provide EDID
so that is all fine.

I cannot patch RTSM to emulate I2C and DDC. It's not
open source. But the device tree in the kernel supports
this "machine" and so, I have to maintain it when modernizng
the fbdev driver to a DRM driver.

I'm sorry RTSM is half/half. Not my fault. I can't fix...

> And one more thing, you are defining virtual panel but you are using
> drm_bridge framework, why not drm_panel?

This was discussed before in the previous patch set:
https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html

Essentially, it's because the display driver is just connected
to "something" not a panel and a bridge is likely the best I
can come up with - a bridge over to a virtual display.

A patch to add "VGA", "SGA" and "XGA" to the simple panels
was NACKed (sort of, politely):
https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html

Also it was noted that it would be nice to have something that
would make it easy to change resolutions on these virtual
display things. Voila.

Yours,
Linus Walleij

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 28.08.2018 15:45, Linus Walleij wrote:
> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>
>> On 24.08.2018 14:23, Linus Walleij wrote:
>>> This adds bindings for a virtual display to be used with displays
>>> inside entirely virtual environments which do not emulate things
>>> like monitors but just need timing information to be supplied to
>>> its display controller.
>>>
>>> This is inspired by earlier work by Liviu Dudau.
>> If this is pure virtual then it should be connected to other pure
>> virtual components.
> OK it's a bit of half-half but outside of my grasp, I am just trying
> to support legacy systems.
>
> The device tree is there:
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>
> The latter contains the CLCD which is the display driver.
>
> In RTSM, which is an ARM product I do not develop and
> cannot make changes to, there is an emulated CLCD. So
> that part appear as if it was real hardware. Like in QEMU.
>
> But the display does not have any emulation. The raw
> output from the CLCD is latched out to the screen.
>
> I do not know exactly know how the RTSM emulator
> actually works, but I suspect that the little graphic window
> on the screeen adapts to what gets written into the
> CLCD control registers, so anything goes, more or less.
>
> To satisfy the CLCD with some timings and resolution,
> this bridge gives it that, from the device tree, in a way
> that clearly conveys that "this is not a real thing".
>
> The old code uses DPI. This is not DPI, not even close
> to it. It worked simply because all the DPI really does is
> what this patch does: provide timings.
>
> By contrast on QEMU I have patches the emulator to
> properly represent the I2C DDC link and provide EDID
> so that is all fine.
>
> I cannot patch RTSM to emulate I2C and DDC. It's not
> open source. But the device tree in the kernel supports
> this "machine" and so, I have to maintain it when modernizng
> the fbdev driver to a DRM driver.
>
> I'm sorry RTSM is half/half. Not my fault. I can't fix...

I do not know the platform, so I  I have dug little bit, but I wan't
call it  thorough research. Just please be kind if I wrote sth stupid.
What I have found:
1. DTS shows CLCD is pl111.
2. pl111 documentation says it's output interface supports STN and TFT
up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
DPI.

If it is correct, dpi panel seems to be OK. And I think it is less
important how the emulator works, more important is that it should
emulate pl111, including it's output interfaces.

Regards
Andrzej
>
>> And one more thing, you are defining virtual panel but you are using
>> drm_bridge framework, why not drm_panel?
> This was discussed before in the previous patch set:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>
> Essentially, it's because the display driver is just connected
> to "something" not a panel and a bridge is likely the best I
> can come up with - a bridge over to a virtual display.
>
> A patch to add "VGA", "SGA" and "XGA" to the simple panels
> was NACKed (sort of, politely):
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>
> Also it was noted that it would be nice to have something that
> would make it easy to change resolutions on these virtual
> display things. Voila.



>
> Yours,
> Linus Walleij
>
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 28.08.2018 15:45, Linus Walleij wrote:
> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>
>> On 24.08.2018 14:23, Linus Walleij wrote:
>>> This adds bindings for a virtual display to be used with displays
>>> inside entirely virtual environments which do not emulate things
>>> like monitors but just need timing information to be supplied to
>>> its display controller.
>>>
>>> This is inspired by earlier work by Liviu Dudau.
>> If this is pure virtual then it should be connected to other pure
>> virtual components.
> OK it's a bit of half-half but outside of my grasp, I am just trying
> to support legacy systems.
>
> The device tree is there:
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>
> The latter contains the CLCD which is the display driver.
>
> In RTSM, which is an ARM product I do not develop and
> cannot make changes to, there is an emulated CLCD. So
> that part appear as if it was real hardware. Like in QEMU.
>
> But the display does not have any emulation. The raw
> output from the CLCD is latched out to the screen.
>
> I do not know exactly know how the RTSM emulator
> actually works, but I suspect that the little graphic window
> on the screeen adapts to what gets written into the
> CLCD control registers, so anything goes, more or less.
>
> To satisfy the CLCD with some timings and resolution,
> this bridge gives it that, from the device tree, in a way
> that clearly conveys that "this is not a real thing".
>
> The old code uses DPI. This is not DPI, not even close
> to it. It worked simply because all the DPI really does is
> what this patch does: provide timings.
>
> By contrast on QEMU I have patches the emulator to
> properly represent the I2C DDC link and provide EDID
> so that is all fine.
>
> I cannot patch RTSM to emulate I2C and DDC. It's not
> open source. But the device tree in the kernel supports
> this "machine" and so, I have to maintain it when modernizng
> the fbdev driver to a DRM driver.
>
> I'm sorry RTSM is half/half. Not my fault. I can't fix...

I do not know the platform, so I? I have dug little bit, but I wan't
call it? thorough research. Just please be kind if I wrote sth stupid.
What I have found:
1. DTS shows CLCD is pl111.
2. pl111 documentation says it's output interface supports STN and TFT
up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
DPI.

If it is correct, dpi panel seems to be OK. And I think it is less
important how the emulator works, more important is that it should
emulate pl111, including it's output interfaces.

Regards
Andrzej
>
>> And one more thing, you are defining virtual panel but you are using
>> drm_bridge framework, why not drm_panel?
> This was discussed before in the previous patch set:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>
> Essentially, it's because the display driver is just connected
> to "something" not a panel and a bridge is likely the best I
> can come up with - a bridge over to a virtual display.
>
> A patch to add "VGA", "SGA" and "XGA" to the simple panels
> was NACKed (sort of, politely):
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>
> Also it was noted that it would be nice to have something that
> would make it easy to change resolutions on these virtual
> display things. Voila.



>
> Yours,
> Linus Walleij
>
>

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> On 28.08.2018 15:45, Linus Walleij wrote:
> > On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> >
> >> On 24.08.2018 14:23, Linus Walleij wrote:
> >>> This adds bindings for a virtual display to be used with displays
> >>> inside entirely virtual environments which do not emulate things
> >>> like monitors but just need timing information to be supplied to
> >>> its display controller.
> >>>
> >>> This is inspired by earlier work by Liviu Dudau.
> >> If this is pure virtual then it should be connected to other pure
> >> virtual components.
> > OK it's a bit of half-half but outside of my grasp, I am just trying
> > to support legacy systems.
> >
> > The device tree is there:
> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> >
> > The latter contains the CLCD which is the display driver.
> >
> > In RTSM, which is an ARM product I do not develop and
> > cannot make changes to, there is an emulated CLCD. So
> > that part appear as if it was real hardware. Like in QEMU.
> >
> > But the display does not have any emulation. The raw
> > output from the CLCD is latched out to the screen.
> >
> > I do not know exactly know how the RTSM emulator
> > actually works, but I suspect that the little graphic window
> > on the screeen adapts to what gets written into the
> > CLCD control registers, so anything goes, more or less.
> >
> > To satisfy the CLCD with some timings and resolution,
> > this bridge gives it that, from the device tree, in a way
> > that clearly conveys that "this is not a real thing".
> >
> > The old code uses DPI. This is not DPI, not even close
> > to it. It worked simply because all the DPI really does is
> > what this patch does: provide timings.
> >
> > By contrast on QEMU I have patches the emulator to
> > properly represent the I2C DDC link and provide EDID
> > so that is all fine.
> >
> > I cannot patch RTSM to emulate I2C and DDC. It's not
> > open source. But the device tree in the kernel supports
> > this "machine" and so, I have to maintain it when modernizng
> > the fbdev driver to a DRM driver.
> >
> > I'm sorry RTSM is half/half. Not my fault. I can't fix...
> 
> I do not know the platform, so I  I have dug little bit, but I wan't
> call it  thorough research. Just please be kind if I wrote sth stupid.
> What I have found:
> 1. DTS shows CLCD is pl111.
> 2. pl111 documentation says it's output interface supports STN and TFT
> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> DPI.
> 
> If it is correct, dpi panel seems to be OK. And I think it is less
> important how the emulator works, more important is that it should
> emulate pl111, including it's output interfaces.

Yeah, unfortunately that ship has sailed a long time ago. The emulator
people thought emulating the register interface is good enough and took
liberties on how the behaviour was "emulated". End result: output
interfaces are not the same.

Best regards,
Liviu

> 
> Regards
> Andrzej
> >
> >> And one more thing, you are defining virtual panel but you are using
> >> drm_bridge framework, why not drm_panel?
> > This was discussed before in the previous patch set:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
> >
> > Essentially, it's because the display driver is just connected
> > to "something" not a panel and a bridge is likely the best I
> > can come up with - a bridge over to a virtual display.
> >
> > A patch to add "VGA", "SGA" and "XGA" to the simple panels
> > was NACKed (sort of, politely):
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
> >
> > Also it was noted that it would be nice to have something that
> > would make it easy to change resolutions on these virtual
> > display things. Voila.
> 
> 
> 
> >
> > Yours,
> > Linus Walleij
> >
> >
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> On 28.08.2018 15:45, Linus Walleij wrote:
> > On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> >
> >> On 24.08.2018 14:23, Linus Walleij wrote:
> >>> This adds bindings for a virtual display to be used with displays
> >>> inside entirely virtual environments which do not emulate things
> >>> like monitors but just need timing information to be supplied to
> >>> its display controller.
> >>>
> >>> This is inspired by earlier work by Liviu Dudau.
> >> If this is pure virtual then it should be connected to other pure
> >> virtual components.
> > OK it's a bit of half-half but outside of my grasp, I am just trying
> > to support legacy systems.
> >
> > The device tree is there:
> > arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> > arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> >
> > The latter contains the CLCD which is the display driver.
> >
> > In RTSM, which is an ARM product I do not develop and
> > cannot make changes to, there is an emulated CLCD. So
> > that part appear as if it was real hardware. Like in QEMU.
> >
> > But the display does not have any emulation. The raw
> > output from the CLCD is latched out to the screen.
> >
> > I do not know exactly know how the RTSM emulator
> > actually works, but I suspect that the little graphic window
> > on the screeen adapts to what gets written into the
> > CLCD control registers, so anything goes, more or less.
> >
> > To satisfy the CLCD with some timings and resolution,
> > this bridge gives it that, from the device tree, in a way
> > that clearly conveys that "this is not a real thing".
> >
> > The old code uses DPI. This is not DPI, not even close
> > to it. It worked simply because all the DPI really does is
> > what this patch does: provide timings.
> >
> > By contrast on QEMU I have patches the emulator to
> > properly represent the I2C DDC link and provide EDID
> > so that is all fine.
> >
> > I cannot patch RTSM to emulate I2C and DDC. It's not
> > open source. But the device tree in the kernel supports
> > this "machine" and so, I have to maintain it when modernizng
> > the fbdev driver to a DRM driver.
> >
> > I'm sorry RTSM is half/half. Not my fault. I can't fix...
> 
> I do not know the platform, so I? I have dug little bit, but I wan't
> call it? thorough research. Just please be kind if I wrote sth stupid.
> What I have found:
> 1. DTS shows CLCD is pl111.
> 2. pl111 documentation says it's output interface supports STN and TFT
> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> DPI.
> 
> If it is correct, dpi panel seems to be OK. And I think it is less
> important how the emulator works, more important is that it should
> emulate pl111, including it's output interfaces.

Yeah, unfortunately that ship has sailed a long time ago. The emulator
people thought emulating the register interface is good enough and took
liberties on how the behaviour was "emulated". End result: output
interfaces are not the same.

Best regards,
Liviu

> 
> Regards
> Andrzej
> >
> >> And one more thing, you are defining virtual panel but you are using
> >> drm_bridge framework, why not drm_panel?
> > This was discussed before in the previous patch set:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
> >
> > Essentially, it's because the display driver is just connected
> > to "something" not a panel and a bridge is likely the best I
> > can come up with - a bridge over to a virtual display.
> >
> > A patch to add "VGA", "SGA" and "XGA" to the simple panels
> > was NACKed (sort of, politely):
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
> >
> > Also it was noted that it would be nice to have something that
> > would make it easy to change resolutions on these virtual
> > display things. Voila.
> 
> 
> 
> >
> > Yours,
> > Linus Walleij
> >
> >
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 29.08.2018 12:01, Liviu Dudau wrote:
> On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
>> On 28.08.2018 15:45, Linus Walleij wrote:
>>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>>>
>>>> On 24.08.2018 14:23, Linus Walleij wrote:
>>>>> This adds bindings for a virtual display to be used with displays
>>>>> inside entirely virtual environments which do not emulate things
>>>>> like monitors but just need timing information to be supplied to
>>>>> its display controller.
>>>>>
>>>>> This is inspired by earlier work by Liviu Dudau.
>>>> If this is pure virtual then it should be connected to other pure
>>>> virtual components.
>>> OK it's a bit of half-half but outside of my grasp, I am just trying
>>> to support legacy systems.
>>>
>>> The device tree is there:
>>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>>
>>> The latter contains the CLCD which is the display driver.
>>>
>>> In RTSM, which is an ARM product I do not develop and
>>> cannot make changes to, there is an emulated CLCD. So
>>> that part appear as if it was real hardware. Like in QEMU.
>>>
>>> But the display does not have any emulation. The raw
>>> output from the CLCD is latched out to the screen.
>>>
>>> I do not know exactly know how the RTSM emulator
>>> actually works, but I suspect that the little graphic window
>>> on the screeen adapts to what gets written into the
>>> CLCD control registers, so anything goes, more or less.
>>>
>>> To satisfy the CLCD with some timings and resolution,
>>> this bridge gives it that, from the device tree, in a way
>>> that clearly conveys that "this is not a real thing".
>>>
>>> The old code uses DPI. This is not DPI, not even close
>>> to it. It worked simply because all the DPI really does is
>>> what this patch does: provide timings.
>>>
>>> By contrast on QEMU I have patches the emulator to
>>> properly represent the I2C DDC link and provide EDID
>>> so that is all fine.
>>>
>>> I cannot patch RTSM to emulate I2C and DDC. It's not
>>> open source. But the device tree in the kernel supports
>>> this "machine" and so, I have to maintain it when modernizng
>>> the fbdev driver to a DRM driver.
>>>
>>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
>> I do not know the platform, so I  I have dug little bit, but I wan't
>> call it  thorough research. Just please be kind if I wrote sth stupid.
>> What I have found:
>> 1. DTS shows CLCD is pl111.
>> 2. pl111 documentation says it's output interface supports STN and TFT
>> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
>> DPI.
>>
>> If it is correct, dpi panel seems to be OK. And I think it is less
>> important how the emulator works, more important is that it should
>> emulate pl111, including it's output interfaces.
> Yeah, unfortunately that ship has sailed a long time ago. The emulator
> people thought emulating the register interface is good enough and took
> liberties on how the behaviour was "emulated". End result: output
> interfaces are not the same.

So what is wrong/missing with dpi panel?

Regards
Andrzej

>
> Best regards,
> Liviu
>
>> Regards
>> Andrzej
>>>> And one more thing, you are defining virtual panel but you are using
>>>> drm_bridge framework, why not drm_panel?
>>> This was discussed before in the previous patch set:
>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>>>
>>> Essentially, it's because the display driver is just connected
>>> to "something" not a panel and a bridge is likely the best I
>>> can come up with - a bridge over to a virtual display.
>>>
>>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
>>> was NACKed (sort of, politely):
>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>>>
>>> Also it was noted that it would be nice to have something that
>>> would make it easy to change resolutions on these virtual
>>> display things. Voila.
>>
>>
>>> Yours,
>>> Linus Walleij
>>>
>>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 29.08.2018 12:01, Liviu Dudau wrote:
> On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
>> On 28.08.2018 15:45, Linus Walleij wrote:
>>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>>>
>>>> On 24.08.2018 14:23, Linus Walleij wrote:
>>>>> This adds bindings for a virtual display to be used with displays
>>>>> inside entirely virtual environments which do not emulate things
>>>>> like monitors but just need timing information to be supplied to
>>>>> its display controller.
>>>>>
>>>>> This is inspired by earlier work by Liviu Dudau.
>>>> If this is pure virtual then it should be connected to other pure
>>>> virtual components.
>>> OK it's a bit of half-half but outside of my grasp, I am just trying
>>> to support legacy systems.
>>>
>>> The device tree is there:
>>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>>
>>> The latter contains the CLCD which is the display driver.
>>>
>>> In RTSM, which is an ARM product I do not develop and
>>> cannot make changes to, there is an emulated CLCD. So
>>> that part appear as if it was real hardware. Like in QEMU.
>>>
>>> But the display does not have any emulation. The raw
>>> output from the CLCD is latched out to the screen.
>>>
>>> I do not know exactly know how the RTSM emulator
>>> actually works, but I suspect that the little graphic window
>>> on the screeen adapts to what gets written into the
>>> CLCD control registers, so anything goes, more or less.
>>>
>>> To satisfy the CLCD with some timings and resolution,
>>> this bridge gives it that, from the device tree, in a way
>>> that clearly conveys that "this is not a real thing".
>>>
>>> The old code uses DPI. This is not DPI, not even close
>>> to it. It worked simply because all the DPI really does is
>>> what this patch does: provide timings.
>>>
>>> By contrast on QEMU I have patches the emulator to
>>> properly represent the I2C DDC link and provide EDID
>>> so that is all fine.
>>>
>>> I cannot patch RTSM to emulate I2C and DDC. It's not
>>> open source. But the device tree in the kernel supports
>>> this "machine" and so, I have to maintain it when modernizng
>>> the fbdev driver to a DRM driver.
>>>
>>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
>> I do not know the platform, so I? I have dug little bit, but I wan't
>> call it? thorough research. Just please be kind if I wrote sth stupid.
>> What I have found:
>> 1. DTS shows CLCD is pl111.
>> 2. pl111 documentation says it's output interface supports STN and TFT
>> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
>> DPI.
>>
>> If it is correct, dpi panel seems to be OK. And I think it is less
>> important how the emulator works, more important is that it should
>> emulate pl111, including it's output interfaces.
> Yeah, unfortunately that ship has sailed a long time ago. The emulator
> people thought emulating the register interface is good enough and took
> liberties on how the behaviour was "emulated". End result: output
> interfaces are not the same.

So what is wrong/missing with dpi panel?

Regards
Andrzej

>
> Best regards,
> Liviu
>
>> Regards
>> Andrzej
>>>> And one more thing, you are defining virtual panel but you are using
>>>> drm_bridge framework, why not drm_panel?
>>> This was discussed before in the previous patch set:
>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>>>
>>> Essentially, it's because the display driver is just connected
>>> to "something" not a panel and a bridge is likely the best I
>>> can come up with - a bridge over to a virtual display.
>>>
>>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
>>> was NACKed (sort of, politely):
>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>>>
>>> Also it was noted that it would be nice to have something that
>>> would make it easy to change resolutions on these virtual
>>> display things. Voila.
>>
>>
>>> Yours,
>>> Linus Walleij
>>>
>>>

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote:
> On 29.08.2018 12:01, Liviu Dudau wrote:
> > On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> >> On 28.08.2018 15:45, Linus Walleij wrote:
> >>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> >>>
> >>>> On 24.08.2018 14:23, Linus Walleij wrote:
> >>>>> This adds bindings for a virtual display to be used with displays
> >>>>> inside entirely virtual environments which do not emulate things
> >>>>> like monitors but just need timing information to be supplied to
> >>>>> its display controller.
> >>>>>
> >>>>> This is inspired by earlier work by Liviu Dudau.
> >>>> If this is pure virtual then it should be connected to other pure
> >>>> virtual components.
> >>> OK it's a bit of half-half but outside of my grasp, I am just trying
> >>> to support legacy systems.
> >>>
> >>> The device tree is there:
> >>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> >>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> >>>
> >>> The latter contains the CLCD which is the display driver.
> >>>
> >>> In RTSM, which is an ARM product I do not develop and
> >>> cannot make changes to, there is an emulated CLCD. So
> >>> that part appear as if it was real hardware. Like in QEMU.
> >>>
> >>> But the display does not have any emulation. The raw
> >>> output from the CLCD is latched out to the screen.
> >>>
> >>> I do not know exactly know how the RTSM emulator
> >>> actually works, but I suspect that the little graphic window
> >>> on the screeen adapts to what gets written into the
> >>> CLCD control registers, so anything goes, more or less.
> >>>
> >>> To satisfy the CLCD with some timings and resolution,
> >>> this bridge gives it that, from the device tree, in a way
> >>> that clearly conveys that "this is not a real thing".
> >>>
> >>> The old code uses DPI. This is not DPI, not even close
> >>> to it. It worked simply because all the DPI really does is
> >>> what this patch does: provide timings.
> >>>
> >>> By contrast on QEMU I have patches the emulator to
> >>> properly represent the I2C DDC link and provide EDID
> >>> so that is all fine.
> >>>
> >>> I cannot patch RTSM to emulate I2C and DDC. It's not
> >>> open source. But the device tree in the kernel supports
> >>> this "machine" and so, I have to maintain it when modernizng
> >>> the fbdev driver to a DRM driver.
> >>>
> >>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
> >> I do not know the platform, so I  I have dug little bit, but I wan't
> >> call it  thorough research. Just please be kind if I wrote sth stupid.
> >> What I have found:
> >> 1. DTS shows CLCD is pl111.
> >> 2. pl111 documentation says it's output interface supports STN and TFT
> >> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> >> DPI.
> >>
> >> If it is correct, dpi panel seems to be OK. And I think it is less
> >> important how the emulator works, more important is that it should
> >> emulate pl111, including it's output interfaces.
> > Yeah, unfortunately that ship has sailed a long time ago. The emulator
> > people thought emulating the register interface is good enough and took
> > liberties on how the behaviour was "emulated". End result: output
> > interfaces are not the same.
> 
> So what is wrong/missing with dpi panel?

Linus explained in the links he quoted below. I'll let him add more if
he has additional information.

Best regards,
Liviu

> 
> Regards
> Andrzej
> 
> >
> > Best regards,
> > Liviu
> >
> >> Regards
> >> Andrzej
> >>>> And one more thing, you are defining virtual panel but you are using
> >>>> drm_bridge framework, why not drm_panel?
> >>> This was discussed before in the previous patch set:
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
> >>>
> >>> Essentially, it's because the display driver is just connected
> >>> to "something" not a panel and a bridge is likely the best I
> >>> can come up with - a bridge over to a virtual display.
> >>>
> >>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
> >>> was NACKed (sort of, politely):
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
> >>>
> >>> Also it was noted that it would be nice to have something that
> >>> would make it easy to change resolutions on these virtual
> >>> display things. Voila.
> >>
> >>
> >>> Yours,
> >>> Linus Walleij
> >>>
> >>>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote:
> On 29.08.2018 12:01, Liviu Dudau wrote:
> > On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> >> On 28.08.2018 15:45, Linus Walleij wrote:
> >>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> >>>
> >>>> On 24.08.2018 14:23, Linus Walleij wrote:
> >>>>> This adds bindings for a virtual display to be used with displays
> >>>>> inside entirely virtual environments which do not emulate things
> >>>>> like monitors but just need timing information to be supplied to
> >>>>> its display controller.
> >>>>>
> >>>>> This is inspired by earlier work by Liviu Dudau.
> >>>> If this is pure virtual then it should be connected to other pure
> >>>> virtual components.
> >>> OK it's a bit of half-half but outside of my grasp, I am just trying
> >>> to support legacy systems.
> >>>
> >>> The device tree is there:
> >>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
> >>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
> >>>
> >>> The latter contains the CLCD which is the display driver.
> >>>
> >>> In RTSM, which is an ARM product I do not develop and
> >>> cannot make changes to, there is an emulated CLCD. So
> >>> that part appear as if it was real hardware. Like in QEMU.
> >>>
> >>> But the display does not have any emulation. The raw
> >>> output from the CLCD is latched out to the screen.
> >>>
> >>> I do not know exactly know how the RTSM emulator
> >>> actually works, but I suspect that the little graphic window
> >>> on the screeen adapts to what gets written into the
> >>> CLCD control registers, so anything goes, more or less.
> >>>
> >>> To satisfy the CLCD with some timings and resolution,
> >>> this bridge gives it that, from the device tree, in a way
> >>> that clearly conveys that "this is not a real thing".
> >>>
> >>> The old code uses DPI. This is not DPI, not even close
> >>> to it. It worked simply because all the DPI really does is
> >>> what this patch does: provide timings.
> >>>
> >>> By contrast on QEMU I have patches the emulator to
> >>> properly represent the I2C DDC link and provide EDID
> >>> so that is all fine.
> >>>
> >>> I cannot patch RTSM to emulate I2C and DDC. It's not
> >>> open source. But the device tree in the kernel supports
> >>> this "machine" and so, I have to maintain it when modernizng
> >>> the fbdev driver to a DRM driver.
> >>>
> >>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
> >> I do not know the platform, so I? I have dug little bit, but I wan't
> >> call it? thorough research. Just please be kind if I wrote sth stupid.
> >> What I have found:
> >> 1. DTS shows CLCD is pl111.
> >> 2. pl111 documentation says it's output interface supports STN and TFT
> >> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> >> DPI.
> >>
> >> If it is correct, dpi panel seems to be OK. And I think it is less
> >> important how the emulator works, more important is that it should
> >> emulate pl111, including it's output interfaces.
> > Yeah, unfortunately that ship has sailed a long time ago. The emulator
> > people thought emulating the register interface is good enough and took
> > liberties on how the behaviour was "emulated". End result: output
> > interfaces are not the same.
> 
> So what is wrong/missing with dpi panel?

Linus explained in the links he quoted below. I'll let him add more if
he has additional information.

Best regards,
Liviu

> 
> Regards
> Andrzej
> 
> >
> > Best regards,
> > Liviu
> >
> >> Regards
> >> Andrzej
> >>>> And one more thing, you are defining virtual panel but you are using
> >>>> drm_bridge framework, why not drm_panel?
> >>> This was discussed before in the previous patch set:
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
> >>>
> >>> Essentially, it's because the display driver is just connected
> >>> to "something" not a panel and a bridge is likely the best I
> >>> can come up with - a bridge over to a virtual display.
> >>>
> >>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
> >>> was NACKed (sort of, politely):
> >>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
> >>>
> >>> Also it was noted that it would be nice to have something that
> >>> would make it easy to change resolutions on these virtual
> >>> display things. Voila.
> >>
> >>
> >>> Yours,
> >>> Linus Walleij
> >>>
> >>>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 29.08.2018 13:00, Liviu Dudau wrote:
> On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote:
>> On 29.08.2018 12:01, Liviu Dudau wrote:
>>> On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
>>>> On 28.08.2018 15:45, Linus Walleij wrote:
>>>>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>>>>>
>>>>>> On 24.08.2018 14:23, Linus Walleij wrote:
>>>>>>> This adds bindings for a virtual display to be used with displays
>>>>>>> inside entirely virtual environments which do not emulate things
>>>>>>> like monitors but just need timing information to be supplied to
>>>>>>> its display controller.
>>>>>>>
>>>>>>> This is inspired by earlier work by Liviu Dudau.
>>>>>> If this is pure virtual then it should be connected to other pure
>>>>>> virtual components.
>>>>> OK it's a bit of half-half but outside of my grasp, I am just trying
>>>>> to support legacy systems.
>>>>>
>>>>> The device tree is there:
>>>>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
>>>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>>>>
>>>>> The latter contains the CLCD which is the display driver.
>>>>>
>>>>> In RTSM, which is an ARM product I do not develop and
>>>>> cannot make changes to, there is an emulated CLCD. So
>>>>> that part appear as if it was real hardware. Like in QEMU.
>>>>>
>>>>> But the display does not have any emulation. The raw
>>>>> output from the CLCD is latched out to the screen.
>>>>>
>>>>> I do not know exactly know how the RTSM emulator
>>>>> actually works, but I suspect that the little graphic window
>>>>> on the screeen adapts to what gets written into the
>>>>> CLCD control registers, so anything goes, more or less.
>>>>>
>>>>> To satisfy the CLCD with some timings and resolution,
>>>>> this bridge gives it that, from the device tree, in a way
>>>>> that clearly conveys that "this is not a real thing".
>>>>>
>>>>> The old code uses DPI. This is not DPI, not even close
>>>>> to it. It worked simply because all the DPI really does is
>>>>> what this patch does: provide timings.
>>>>>
>>>>> By contrast on QEMU I have patches the emulator to
>>>>> properly represent the I2C DDC link and provide EDID
>>>>> so that is all fine.
>>>>>
>>>>> I cannot patch RTSM to emulate I2C and DDC. It's not
>>>>> open source. But the device tree in the kernel supports
>>>>> this "machine" and so, I have to maintain it when modernizng
>>>>> the fbdev driver to a DRM driver.
>>>>>
>>>>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
>>>> I do not know the platform, so I  I have dug little bit, but I wan't
>>>> call it  thorough research. Just please be kind if I wrote sth stupid.
>>>> What I have found:
>>>> 1. DTS shows CLCD is pl111.
>>>> 2. pl111 documentation says it's output interface supports STN and TFT
>>>> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
>>>> DPI.
>>>>
>>>> If it is correct, dpi panel seems to be OK. And I think it is less
>>>> important how the emulator works, more important is that it should
>>>> emulate pl111, including it's output interfaces.
>>> Yeah, unfortunately that ship has sailed a long time ago. The emulator
>>> people thought emulating the register interface is good enough and took
>>> liberties on how the behaviour was "emulated". End result: output
>>> interfaces are not the same.
>> So what is wrong/missing with dpi panel?
> Linus explained in the links he quoted below. I'll let him add more if
> he has additional information.

In links below Linus proposed VGA, for me it seems incorrect pl111, does
not produce analog VGA signal. Why do you (or Linus) want to use it. It
does not make sense.
SVGA and XGA are worse, they do not identify video signal standard, they
identify only resolution.

My question still stands: what is wrong/missing with dpi panel?

I did not analyze details, but pl111 output seems to be DPI compatible.
Please note that DPI standard (unlike DSI) is a kind of
post-implementation standard - it was created to describe existing
display parallel interfaces, which are identified using different names:
RGB, parallel, TFT(?), LCD, panel,... So even if documentation says
nothing about DPI it does not mean it is not DPI 'compliant'. Usually
most digital interfaces with 24-lines for RGB data, VSYNC, HSYNC, PCLK
and DE signals can be treated as DPI interfaces.

Regards
Andrzej


>
> Best regards,
> Liviu
>
>> Regards
>> Andrzej
>>
>>> Best regards,
>>> Liviu
>>>
>>>> Regards
>>>> Andrzej
>>>>>> And one more thing, you are defining virtual panel but you are using
>>>>>> drm_bridge framework, why not drm_panel?
>>>>> This was discussed before in the previous patch set:
>>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>>>>>
>>>>> Essentially, it's because the display driver is just connected
>>>>> to "something" not a panel and a bridge is likely the best I
>>>>> can come up with - a bridge over to a virtual display.
>>>>>
>>>>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
>>>>> was NACKed (sort of, politely):
>>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>>>>>
>>>>> Also it was noted that it would be nice to have something that
>>>>> would make it easy to change resolutions on these virtual
>>>>> display things. Voila.
>>>>
>>>>> Yours,
>>>>> Linus Walleij
>>>>>
>>>>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 29.08.2018 13:00, Liviu Dudau wrote:
> On Wed, Aug 29, 2018 at 12:23:18PM +0200, Andrzej Hajda wrote:
>> On 29.08.2018 12:01, Liviu Dudau wrote:
>>> On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
>>>> On 28.08.2018 15:45, Linus Walleij wrote:
>>>>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
>>>>>
>>>>>> On 24.08.2018 14:23, Linus Walleij wrote:
>>>>>>> This adds bindings for a virtual display to be used with displays
>>>>>>> inside entirely virtual environments which do not emulate things
>>>>>>> like monitors but just need timing information to be supplied to
>>>>>>> its display controller.
>>>>>>>
>>>>>>> This is inspired by earlier work by Liviu Dudau.
>>>>>> If this is pure virtual then it should be connected to other pure
>>>>>> virtual components.
>>>>> OK it's a bit of half-half but outside of my grasp, I am just trying
>>>>> to support legacy systems.
>>>>>
>>>>> The device tree is there:
>>>>> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts
>>>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>>>>
>>>>> The latter contains the CLCD which is the display driver.
>>>>>
>>>>> In RTSM, which is an ARM product I do not develop and
>>>>> cannot make changes to, there is an emulated CLCD. So
>>>>> that part appear as if it was real hardware. Like in QEMU.
>>>>>
>>>>> But the display does not have any emulation. The raw
>>>>> output from the CLCD is latched out to the screen.
>>>>>
>>>>> I do not know exactly know how the RTSM emulator
>>>>> actually works, but I suspect that the little graphic window
>>>>> on the screeen adapts to what gets written into the
>>>>> CLCD control registers, so anything goes, more or less.
>>>>>
>>>>> To satisfy the CLCD with some timings and resolution,
>>>>> this bridge gives it that, from the device tree, in a way
>>>>> that clearly conveys that "this is not a real thing".
>>>>>
>>>>> The old code uses DPI. This is not DPI, not even close
>>>>> to it. It worked simply because all the DPI really does is
>>>>> what this patch does: provide timings.
>>>>>
>>>>> By contrast on QEMU I have patches the emulator to
>>>>> properly represent the I2C DDC link and provide EDID
>>>>> so that is all fine.
>>>>>
>>>>> I cannot patch RTSM to emulate I2C and DDC. It's not
>>>>> open source. But the device tree in the kernel supports
>>>>> this "machine" and so, I have to maintain it when modernizng
>>>>> the fbdev driver to a DRM driver.
>>>>>
>>>>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
>>>> I do not know the platform, so I? I have dug little bit, but I wan't
>>>> call it? thorough research. Just please be kind if I wrote sth stupid.
>>>> What I have found:
>>>> 1. DTS shows CLCD is pl111.
>>>> 2. pl111 documentation says it's output interface supports STN and TFT
>>>> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
>>>> DPI.
>>>>
>>>> If it is correct, dpi panel seems to be OK. And I think it is less
>>>> important how the emulator works, more important is that it should
>>>> emulate pl111, including it's output interfaces.
>>> Yeah, unfortunately that ship has sailed a long time ago. The emulator
>>> people thought emulating the register interface is good enough and took
>>> liberties on how the behaviour was "emulated". End result: output
>>> interfaces are not the same.
>> So what is wrong/missing with dpi panel?
> Linus explained in the links he quoted below. I'll let him add more if
> he has additional information.

In links below Linus proposed VGA, for me it seems incorrect pl111, does
not produce analog VGA signal. Why do you (or Linus) want to use it. It
does not make sense.
SVGA and XGA are worse, they do not identify video signal standard, they
identify only resolution.

My question still stands: what is wrong/missing with dpi panel?

I did not analyze details, but pl111 output seems to be DPI compatible.
Please note that DPI standard (unlike DSI) is a kind of
post-implementation standard - it was created to describe existing
display parallel interfaces, which are identified using different names:
RGB, parallel, TFT(?), LCD, panel,... So even if documentation says
nothing about DPI it does not mean it is not DPI 'compliant'. Usually
most digital interfaces with 24-lines for RGB data, VSYNC, HSYNC, PCLK
and DE signals can be treated as DPI interfaces.

Regards
Andrzej


>
> Best regards,
> Liviu
>
>> Regards
>> Andrzej
>>
>>> Best regards,
>>> Liviu
>>>
>>>> Regards
>>>> Andrzej
>>>>>> And one more thing, you are defining virtual panel but you are using
>>>>>> drm_bridge framework, why not drm_panel?
>>>>> This was discussed before in the previous patch set:
>>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183516.html
>>>>>
>>>>> Essentially, it's because the display driver is just connected
>>>>> to "something" not a panel and a bridge is likely the best I
>>>>> can come up with - a bridge over to a virtual display.
>>>>>
>>>>> A patch to add "VGA", "SGA" and "XGA" to the simple panels
>>>>> was NACKed (sort of, politely):
>>>>> https://lists.freedesktop.org/archives/dri-devel/2018-July/183698.html
>>>>>
>>>>> Also it was noted that it would be nice to have something that
>>>>> would make it easy to change resolutions on these virtual
>>>>> display things. Voila.
>>>>
>>>>> Yours,
>>>>> Linus Walleij
>>>>>
>>>>>

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Wed, Aug 29, 2018 at 2:16 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> My question still stands: what is wrong/missing with dpi panel?

Hopefully described with my other answer :)

> I did not analyze details, but pl111 output seems to be DPI compatible.

This patch set is not trying to support the electronic device
PL111 at all. I am trying to support an emulator which has a
half-done emulation of the PL111 registers.

The other panels actually attached to real world instances
of PL111 made in silicon, all have proper drivers in
drivers/gpu/drm/panel already.

All real electronics are already covered. They use:
drivers/gpu/drm/panel/panel-arm-versatile.c
drivers/gpu/drm/bridge/dumb-vga-dac.c

All QEMU emulators are already covered (by making
QEMU emulation behave like real hardware). It now
uses DDC by way of dumb-vga-dac.c.

This virtual display in this emulator is the missing final piece to
convert the PL111 fbdev driver over to use DRM.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Wed, Aug 29, 2018 at 2:16 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> My question still stands: what is wrong/missing with dpi panel?

Hopefully described with my other answer :)

> I did not analyze details, but pl111 output seems to be DPI compatible.

This patch set is not trying to support the electronic device
PL111 at all. I am trying to support an emulator which has a
half-done emulation of the PL111 registers.

The other panels actually attached to real world instances
of PL111 made in silicon, all have proper drivers in
drivers/gpu/drm/panel already.

All real electronics are already covered. They use:
drivers/gpu/drm/panel/panel-arm-versatile.c
drivers/gpu/drm/bridge/dumb-vga-dac.c

All QEMU emulators are already covered (by making
QEMU emulation behave like real hardware). It now
uses DDC by way of dumb-vga-dac.c.

This virtual display in this emulator is the missing final piece to
convert the PL111 fbdev driver over to use DRM.

Yours,
Linus Walleij

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Wed, Aug 29, 2018 at 12:23 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> On 29.08.2018 12:01, Liviu Dudau wrote:
> > On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> >> On 28.08.2018 15:45, Linus Walleij wrote:
> >>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> >>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
> >> I do not know the platform, so I  I have dug little bit, but I wan't
> >> call it  thorough research. Just please be kind if I wrote sth stupid.
> >> What I have found:
> >> 1. DTS shows CLCD is pl111.
> >> 2. pl111 documentation says it's output interface supports STN and TFT
> >> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> >> DPI.
> >>
> >> If it is correct, dpi panel seems to be OK. And I think it is less
> >> important how the emulator works, more important is that it should
> >> emulate pl111, including it's output interfaces.
> >
> > Yeah, unfortunately that ship has sailed a long time ago. The emulator
> > people thought emulating the register interface is good enough and took
> > liberties on how the behaviour was "emulated". End result: output
> > interfaces are not the same.
>
> So what is wrong/missing with dpi panel?

I suppose you are referring to:
Documentation/devicetree/bindings/display/panel/panel-dpi.txt

In short, the following is what is wrong with "dpi-panel":

cd drivers/gpu/drm/panel
grep 'panel-dpi'
<empty string>

This is because the DRM subsystem does not seem to support
any "generic DPI panel" (compatible = "dpi-panel") like fbdev does.

I guess I *could* add support for it to panel-simple.c, but is that
what we want?

The problem I would personally have with it is that "panel-dpi" is
a bus format or transport mechanism, not a real panel.

Everything else in panel-simple has a proper compatible string
to the actual display following the "vendor,product" convention.

Essentially (IMO) "panel-dpi" as compatible string is no better
than "virtual-display-bridge" as suggested in this patch. It is even
a worse fit since all the stuff that DPI includes (like electronic
signals a, b, c...) certainly does not exist in the RTSMv8 emulator.
What it does (as I explained) is just read what was written into
the x/y and color depth resolution registers and slap something
into the emulator window based on that. It doesn't generate
or even attempt to emulate any electronic signals. And this
emulator is what I am trying to support in the first place.

So I would really like to hear what Thierry has to say about using
"panel-dpi" for that before trying that approach.

I feel it would be equivalent to just add a panel with the name
"arm,rtsmv8" into panel-simple and stop trying to be generic,
is this what we want? I'm fine with it, I just want to progress
the patch series in some way.

Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Linus Walleij]

On Wed, Aug 29, 2018 at 12:23 PM Andrzej Hajda <a.hajda@samsung.com> wrote:
> On 29.08.2018 12:01, Liviu Dudau wrote:
> > On Wed, Aug 29, 2018 at 11:58:20AM +0200, Andrzej Hajda wrote:
> >> On 28.08.2018 15:45, Linus Walleij wrote:
> >>> On Mon, Aug 27, 2018 at 1:53 PM Andrzej Hajda <a.hajda@samsung.com> wrote:

> >>> I'm sorry RTSM is half/half. Not my fault. I can't fix...
> >> I do not know the platform, so I  I have dug little bit, but I wan't
> >> call it  thorough research. Just please be kind if I wrote sth stupid.
> >> What I have found:
> >> 1. DTS shows CLCD is pl111.
> >> 2. pl111 documentation says it's output interface supports STN and TFT
> >> up to 24-bit bus. I do not know STN, but TFT seems to be compatible with
> >> DPI.
> >>
> >> If it is correct, dpi panel seems to be OK. And I think it is less
> >> important how the emulator works, more important is that it should
> >> emulate pl111, including it's output interfaces.
> >
> > Yeah, unfortunately that ship has sailed a long time ago. The emulator
> > people thought emulating the register interface is good enough and took
> > liberties on how the behaviour was "emulated". End result: output
> > interfaces are not the same.
>
> So what is wrong/missing with dpi panel?

I suppose you are referring to:
Documentation/devicetree/bindings/display/panel/panel-dpi.txt

In short, the following is what is wrong with "dpi-panel":

cd drivers/gpu/drm/panel
grep 'panel-dpi'
<empty string>

This is because the DRM subsystem does not seem to support
any "generic DPI panel" (compatible = "dpi-panel") like fbdev does.

I guess I *could* add support for it to panel-simple.c, but is that
what we want?

The problem I would personally have with it is that "panel-dpi" is
a bus format or transport mechanism, not a real panel.

Everything else in panel-simple has a proper compatible string
to the actual display following the "vendor,product" convention.

Essentially (IMO) "panel-dpi" as compatible string is no better
than "virtual-display-bridge" as suggested in this patch. It is even
a worse fit since all the stuff that DPI includes (like electronic
signals a, b, c...) certainly does not exist in the RTSMv8 emulator.
What it does (as I explained) is just read what was written into
the x/y and color depth resolution registers and slap something
into the emulator window based on that. It doesn't generate
or even attempt to emulate any electronic signals. And this
emulator is what I am trying to support in the first place.

So I would really like to hear what Thierry has to say about using
"panel-dpi" for that before trying that approach.

I feel it would be equivalent to just add a panel with the name
"arm,rtsmv8" into panel-simple and stop trying to be generic,
is this what we want? I'm fine with it, I just want to progress
the patch series in some way.

Yours,
Linus Walleij

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

Hi Andrzej,

Chirping in, as it was originally my work that Linus is adopting.

On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
> On 24.08.2018 14:23, Linus Walleij wrote:
> > This adds bindings for a virtual display to be used with displays
> > inside entirely virtual environments which do not emulate things
> > like monitors but just need timing information to be supplied to
> > its display controller.
> >
> > This is inspired by earlier work by Liviu Dudau.
> 
> If this is pure virtual then it should be connected to other pure
> virtual components.

Any reason why you think this is the only way this should be connected?
My original implementation (and I haven't seen anything in this patch
that would invalidate it) assumed that the virtual bridge can be used by
any driver that uses the component framework. Hiding implementation
details is one of the benefits of using the component framework, so I
don't see what you gain by restricting connection to only other pure
virtual components.

> What will be this virtual bridge attached to? I expect some virtual
> encoder, virtual crtc? If yes then why don't you create whole virtual
> drm pipeline in one patchset?

This comment is probably more relevant to patch 2/2, but I agree that
it probably needs a virtual encoder. As for the CRTC, it should work
with any real DRM driver, AFAICT.

> Could you describe more what do you want to do.

He wants to enable the PL110 DRM driver on systems that lack a way of
detecting the actual encoder and connector being used (either because
there is none and they are emulated in software that doesn't mimic the
HW behaviour, or because the way you access the HW is done in a way that
doesn't model easily in the current DRM framework: by firmware, for
example).

Best regards,
Liviu

> And one more thing, you are defining virtual panel but you are using
> drm_bridge framework, why not drm_panel?
> 
> Regards
> Andrzej
> 
> >
> > Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> > Cc: Ryan Harkin <ryan.harkin@linaro.org>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> >  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > new file mode 100644
> > index 000000000000..ea4f5a91ab94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > @@ -0,0 +1,62 @@
> > +Virtual Display Bridge
> > +
> > +This represents a display that is contained within an emulated
> > +environment.
> > +
> > +This means that the display engine mainly expects some timing
> > +parameters to be written into it, and after that the emulator will
> > +respond by creating a virtual display with the requested
> > +resolution characteristics.
> > +
> > +As the operating system cannot "detect" such a display, rather the
> > +emulator will respond to what the controller outputs, a
> > +chicken-and-egg problem needs to be solved: the resolution and
> > +timing characteristics need to be defined and set up somewhere.
> > +
> > +The virtual display bridge solves this by defining a bridge with
> > +all timing characteristics encoded into the device tree node.
> > +
> > +Required properies:
> > +- compatible: shall be "virtual-display-bridge"
> > +
> > +Required subnodes:
> > +- display-timings: contains in turn a display timing node
> > +  see display-timing.txt
> > +- ports: contains the display ports, see media/video-interfaces.txt
> > +
> > +Example:
> > +
> > +bridge {
> > +	compatible = "virtual-display-bridge";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	display-timings {
> > +		/* Some standard VGA timing */
> > +		timing0 {
> > +			clock-frequency = <23750>;
> > +			hactive = <640>;
> > +			vactive = <480>;
> > +			hfront-porch = <48>;
> > +			hback-porch = <16>;
> > +			hsync-len = <96>;
> > +			vfront-porch = <33>;
> > +			vback-porch = <9>;
> > +			vsync-len = <3>;
> > +			vrefresh = <60>;
> > +		};
> > +	};
> > +
> > +	ports {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		port@0 {
> > +			reg = <0>;
> > +
> > +			display_bridge_in: endpoint {
> > +				remote-endpoint = <&foo>;
> > +			};
> > +		};
> > +	};
> > +};
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

Hi Andrzej,

Chirping in, as it was originally my work that Linus is adopting.

On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
> On 24.08.2018 14:23, Linus Walleij wrote:
> > This adds bindings for a virtual display to be used with displays
> > inside entirely virtual environments which do not emulate things
> > like monitors but just need timing information to be supplied to
> > its display controller.
> >
> > This is inspired by earlier work by Liviu Dudau.
> 
> If this is pure virtual then it should be connected to other pure
> virtual components.

Any reason why you think this is the only way this should be connected?
My original implementation (and I haven't seen anything in this patch
that would invalidate it) assumed that the virtual bridge can be used by
any driver that uses the component framework. Hiding implementation
details is one of the benefits of using the component framework, so I
don't see what you gain by restricting connection to only other pure
virtual components.

> What will be this virtual bridge attached to? I expect some virtual
> encoder, virtual crtc? If yes then why don't you create whole virtual
> drm pipeline in one patchset?

This comment is probably more relevant to patch 2/2, but I agree that
it probably needs a virtual encoder. As for the CRTC, it should work
with any real DRM driver, AFAICT.

> Could you describe more what do you want to do.

He wants to enable the PL110 DRM driver on systems that lack a way of
detecting the actual encoder and connector being used (either because
there is none and they are emulated in software that doesn't mimic the
HW behaviour, or because the way you access the HW is done in a way that
doesn't model easily in the current DRM framework: by firmware, for
example).

Best regards,
Liviu

> And one more thing, you are defining virtual panel but you are using
> drm_bridge framework, why not drm_panel?
> 
> Regards
> Andrzej
> 
> >
> > Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> > Cc: Ryan Harkin <ryan.harkin@linaro.org>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> >  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > new file mode 100644
> > index 000000000000..ea4f5a91ab94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> > @@ -0,0 +1,62 @@
> > +Virtual Display Bridge
> > +
> > +This represents a display that is contained within an emulated
> > +environment.
> > +
> > +This means that the display engine mainly expects some timing
> > +parameters to be written into it, and after that the emulator will
> > +respond by creating a virtual display with the requested
> > +resolution characteristics.
> > +
> > +As the operating system cannot "detect" such a display, rather the
> > +emulator will respond to what the controller outputs, a
> > +chicken-and-egg problem needs to be solved: the resolution and
> > +timing characteristics need to be defined and set up somewhere.
> > +
> > +The virtual display bridge solves this by defining a bridge with
> > +all timing characteristics encoded into the device tree node.
> > +
> > +Required properies:
> > +- compatible: shall be "virtual-display-bridge"
> > +
> > +Required subnodes:
> > +- display-timings: contains in turn a display timing node
> > +  see display-timing.txt
> > +- ports: contains the display ports, see media/video-interfaces.txt
> > +
> > +Example:
> > +
> > +bridge {
> > +	compatible = "virtual-display-bridge";
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	display-timings {
> > +		/* Some standard VGA timing */
> > +		timing0 {
> > +			clock-frequency = <23750>;
> > +			hactive = <640>;
> > +			vactive = <480>;
> > +			hfront-porch = <48>;
> > +			hback-porch = <16>;
> > +			hsync-len = <96>;
> > +			vfront-porch = <33>;
> > +			vback-porch = <9>;
> > +			vsync-len = <3>;
> > +			vrefresh = <60>;
> > +		};
> > +	};
> > +
> > +	ports {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		port at 0 {
> > +			reg = <0>;
> > +
> > +			display_bridge_in: endpoint {
> > +				remote-endpoint = <&foo>;
> > +			};
> > +		};
> > +	};
> > +};
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 28.08.2018 16:35, Liviu Dudau wrote:
> Hi Andrzej,
>
> Chirping in, as it was originally my work that Linus is adopting.
>
> On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
>> On 24.08.2018 14:23, Linus Walleij wrote:
>>> This adds bindings for a virtual display to be used with displays
>>> inside entirely virtual environments which do not emulate things
>>> like monitors but just need timing information to be supplied to
>>> its display controller.
>>>
>>> This is inspired by earlier work by Liviu Dudau.
>> If this is pure virtual then it should be connected to other pure
>> virtual components.
> Any reason why you think this is the only way this should be connected?

I think pure virtual sink device cannot be connected to real pins of
source device :)
Either source exposes some virtual interfaces either its output will go
to /dev/null, it would be good to know which case author want to address
with these patches.

> My original implementation (and I haven't seen anything in this patch
> that would invalidate it) assumed that the virtual bridge can be used by
> any driver that uses the component framework. Hiding implementation
> details is one of the benefits of using the component framework, so I
> don't see what you gain by restricting connection to only other pure
> virtual components.

I suppose these patches were created for some reason, so more
explanation will be helpful.

>
>> What will be this virtual bridge attached to? I expect some virtual
>> encoder, virtual crtc? If yes then why don't you create whole virtual
>> drm pipeline in one patchset?
> This comment is probably more relevant to patch 2/2, but I agree that
> it probably needs a virtual encoder. As for the CRTC, it should work
> with any real DRM driver, AFAICT.

I do not think so, I guess it could work with sources which do not
communicate with sinks, ie. they have only output pins - in such case
video stream will not be visible, is this something we want? Why?
In case source expects some signals on pins connected to sink, it could
be problematic.

>
>> Could you describe more what do you want to do.
> He wants to enable the PL110 DRM driver on systems that lack a way of
> detecting the actual encoder and connector being used (either because
> there is none and they are emulated in software that doesn't mimic the
> HW behaviour, or because the way you access the HW is done in a way that
> doesn't model easily in the current DRM framework: by firmware, for
> example).

And finally here is real reason to cope with. Since Linus also explained
it in separate mail I will continue the thread with answering to his mail.


Regards
Andrzej

>
> Best regards,
> Liviu
>
>> And one more thing, you are defining virtual panel but you are using
>> drm_bridge framework, why not drm_panel?
>>
>> Regards
>> Andrzej
>>
>>> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
>>> Cc: Ryan Harkin <ryan.harkin@linaro.org>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
>>>  1 file changed, 62 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>> new file mode 100644
>>> index 000000000000..ea4f5a91ab94
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>> @@ -0,0 +1,62 @@
>>> +Virtual Display Bridge
>>> +
>>> +This represents a display that is contained within an emulated
>>> +environment.
>>> +
>>> +This means that the display engine mainly expects some timing
>>> +parameters to be written into it, and after that the emulator will
>>> +respond by creating a virtual display with the requested
>>> +resolution characteristics.
>>> +
>>> +As the operating system cannot "detect" such a display, rather the
>>> +emulator will respond to what the controller outputs, a
>>> +chicken-and-egg problem needs to be solved: the resolution and
>>> +timing characteristics need to be defined and set up somewhere.
>>> +
>>> +The virtual display bridge solves this by defining a bridge with
>>> +all timing characteristics encoded into the device tree node.
>>> +
>>> +Required properies:
>>> +- compatible: shall be "virtual-display-bridge"
>>> +
>>> +Required subnodes:
>>> +- display-timings: contains in turn a display timing node
>>> +  see display-timing.txt
>>> +- ports: contains the display ports, see media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +bridge {
>>> +	compatible = "virtual-display-bridge";
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>> +
>>> +	display-timings {
>>> +		/* Some standard VGA timing */
>>> +		timing0 {
>>> +			clock-frequency = <23750>;
>>> +			hactive = <640>;
>>> +			vactive = <480>;
>>> +			hfront-porch = <48>;
>>> +			hback-porch = <16>;
>>> +			hsync-len = <96>;
>>> +			vfront-porch = <33>;
>>> +			vback-porch = <9>;
>>> +			vsync-len = <3>;
>>> +			vrefresh = <60>;
>>> +		};
>>> +	};
>>> +
>>> +	ports {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		port@0 {
>>> +			reg = <0>;
>>> +
>>> +			display_bridge_in: endpoint {
>>> +				remote-endpoint = <&foo>;
>>> +			};
>>> +		};
>>> +	};
>>> +};
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Andrzej Hajda]

On 28.08.2018 16:35, Liviu Dudau wrote:
> Hi Andrzej,
>
> Chirping in, as it was originally my work that Linus is adopting.
>
> On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
>> On 24.08.2018 14:23, Linus Walleij wrote:
>>> This adds bindings for a virtual display to be used with displays
>>> inside entirely virtual environments which do not emulate things
>>> like monitors but just need timing information to be supplied to
>>> its display controller.
>>>
>>> This is inspired by earlier work by Liviu Dudau.
>> If this is pure virtual then it should be connected to other pure
>> virtual components.
> Any reason why you think this is the only way this should be connected?

I think pure virtual sink device cannot be connected to real pins of
source device :)
Either source exposes some virtual interfaces either its output will go
to /dev/null, it would be good to know which case author want to address
with these patches.

> My original implementation (and I haven't seen anything in this patch
> that would invalidate it) assumed that the virtual bridge can be used by
> any driver that uses the component framework. Hiding implementation
> details is one of the benefits of using the component framework, so I
> don't see what you gain by restricting connection to only other pure
> virtual components.

I suppose these patches were created for some reason, so more
explanation will be helpful.

>
>> What will be this virtual bridge attached to? I expect some virtual
>> encoder, virtual crtc? If yes then why don't you create whole virtual
>> drm pipeline in one patchset?
> This comment is probably more relevant to patch 2/2, but I agree that
> it probably needs a virtual encoder. As for the CRTC, it should work
> with any real DRM driver, AFAICT.

I do not think so, I guess it could work with sources which do not
communicate with sinks, ie. they have only output pins - in such case
video stream will not be visible, is this something we want? Why?
In case source expects some signals on pins connected to sink, it could
be problematic.

>
>> Could you describe more what do you want to do.
> He wants to enable the PL110 DRM driver on systems that lack a way of
> detecting the actual encoder and connector being used (either because
> there is none and they are emulated in software that doesn't mimic the
> HW behaviour, or because the way you access the HW is done in a way that
> doesn't model easily in the current DRM framework: by firmware, for
> example).

And finally here is real reason to cope with. Since Linus also explained
it in separate mail I will continue the thread with answering to his mail.


Regards
Andrzej

>
> Best regards,
> Liviu
>
>> And one more thing, you are defining virtual panel but you are using
>> drm_bridge framework, why not drm_panel?
>>
>> Regards
>> Andrzej
>>
>>> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
>>> Cc: Ryan Harkin <ryan.harkin@linaro.org>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
>>>  1 file changed, 62 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>> new file mode 100644
>>> index 000000000000..ea4f5a91ab94
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>>> @@ -0,0 +1,62 @@
>>> +Virtual Display Bridge
>>> +
>>> +This represents a display that is contained within an emulated
>>> +environment.
>>> +
>>> +This means that the display engine mainly expects some timing
>>> +parameters to be written into it, and after that the emulator will
>>> +respond by creating a virtual display with the requested
>>> +resolution characteristics.
>>> +
>>> +As the operating system cannot "detect" such a display, rather the
>>> +emulator will respond to what the controller outputs, a
>>> +chicken-and-egg problem needs to be solved: the resolution and
>>> +timing characteristics need to be defined and set up somewhere.
>>> +
>>> +The virtual display bridge solves this by defining a bridge with
>>> +all timing characteristics encoded into the device tree node.
>>> +
>>> +Required properies:
>>> +- compatible: shall be "virtual-display-bridge"
>>> +
>>> +Required subnodes:
>>> +- display-timings: contains in turn a display timing node
>>> +  see display-timing.txt
>>> +- ports: contains the display ports, see media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> +bridge {
>>> +	compatible = "virtual-display-bridge";
>>> +	#address-cells = <1>;
>>> +	#size-cells = <0>;
>>> +
>>> +	display-timings {
>>> +		/* Some standard VGA timing */
>>> +		timing0 {
>>> +			clock-frequency = <23750>;
>>> +			hactive = <640>;
>>> +			vactive = <480>;
>>> +			hfront-porch = <48>;
>>> +			hback-porch = <16>;
>>> +			hsync-len = <96>;
>>> +			vfront-porch = <33>;
>>> +			vback-porch = <9>;
>>> +			vsync-len = <3>;
>>> +			vrefresh = <60>;
>>> +		};
>>> +	};
>>> +
>>> +	ports {
>>> +		#address-cells = <1>;
>>> +		#size-cells = <0>;
>>> +
>>> +		port at 0 {
>>> +			reg = <0>;
>>> +
>>> +			display_bridge_in: endpoint {
>>> +				remote-endpoint = <&foo>;
>>> +			};
>>> +		};
>>> +	};
>>> +};
>>

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 10:16:34AM +0200, Andrzej Hajda wrote:
> On 28.08.2018 16:35, Liviu Dudau wrote:
> > Hi Andrzej,
> >
> > Chirping in, as it was originally my work that Linus is adopting.
> >
> > On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
> >> On 24.08.2018 14:23, Linus Walleij wrote:
> >>> This adds bindings for a virtual display to be used with displays
> >>> inside entirely virtual environments which do not emulate things
> >>> like monitors but just need timing information to be supplied to
> >>> its display controller.
> >>>
> >>> This is inspired by earlier work by Liviu Dudau.
> >> If this is pure virtual then it should be connected to other pure
> >> virtual components.
> > Any reason why you think this is the only way this should be connected?
> 
> I think pure virtual sink device cannot be connected to real pins of
> source device :)

I guess I have a wider view on what a source device can be. :)

> Either source exposes some virtual interfaces either its output will go
> to /dev/null, it would be good to know which case author want to address
> with these patches.

Two scenarios where this is useful: in an emulator (like QEMU or Arm's
RTSM) the CRTC device is being emulated, but the rest of the display
chain is being shortcut by reading the framebuffer data assigned to the
CRTC and displaying it directly (either by using an X11 window, or by
streaming it out to a VNC client). Or you have some real hardware, where
the real pins are connected to a bridge, but the bridge is under the
control of the firmware and can only be configured by it, without any
API to interact with from the kernel side. In that case the best you can
do is to put in the device tree a description of what the firmware did
and use that.

> 
> > My original implementation (and I haven't seen anything in this patch
> > that would invalidate it) assumed that the virtual bridge can be used by
> > any driver that uses the component framework. Hiding implementation
> > details is one of the benefits of using the component framework, so I
> > don't see what you gain by restricting connection to only other pure
> > virtual components.
> 
> I suppose these patches were created for some reason, so more
> explanation will be helpful.
> 
> >
> >> What will be this virtual bridge attached to? I expect some virtual
> >> encoder, virtual crtc? If yes then why don't you create whole virtual
> >> drm pipeline in one patchset?
> > This comment is probably more relevant to patch 2/2, but I agree that
> > it probably needs a virtual encoder. As for the CRTC, it should work
> > with any real DRM driver, AFAICT.
> 
> I do not think so, I guess it could work with sources which do not
> communicate with sinks, ie. they have only output pins - in such case
> video stream will not be visible, is this something we want? Why?
> In case source expects some signals on pins connected to sink, it could
> be problematic.

It is not about how the hardware is connected, it is about discoverability
and the ability to control some of the parts in the chain. When that ability
is missing, you are forced to emulate the parts with a "virtual" bridge.

Best regards,
Liviu

> 
> >
> >> Could you describe more what do you want to do.
> > He wants to enable the PL110 DRM driver on systems that lack a way of
> > detecting the actual encoder and connector being used (either because
> > there is none and they are emulated in software that doesn't mimic the
> > HW behaviour, or because the way you access the HW is done in a way that
> > doesn't model easily in the current DRM framework: by firmware, for
> > example).
> 
> And finally here is real reason to cope with. Since Linus also explained
> it in separate mail I will continue the thread with answering to his mail.
> 
> 
> Regards
> Andrzej
> 
> >
> > Best regards,
> > Liviu
> >
> >> And one more thing, you are defining virtual panel but you are using
> >> drm_bridge framework, why not drm_panel?
> >>
> >> Regards
> >> Andrzej
> >>
> >>> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> >>> Cc: Ryan Harkin <ryan.harkin@linaro.org>
> >>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>> ---
> >>>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
> >>>  1 file changed, 62 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>> new file mode 100644
> >>> index 000000000000..ea4f5a91ab94
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>> @@ -0,0 +1,62 @@
> >>> +Virtual Display Bridge
> >>> +
> >>> +This represents a display that is contained within an emulated
> >>> +environment.
> >>> +
> >>> +This means that the display engine mainly expects some timing
> >>> +parameters to be written into it, and after that the emulator will
> >>> +respond by creating a virtual display with the requested
> >>> +resolution characteristics.
> >>> +
> >>> +As the operating system cannot "detect" such a display, rather the
> >>> +emulator will respond to what the controller outputs, a
> >>> +chicken-and-egg problem needs to be solved: the resolution and
> >>> +timing characteristics need to be defined and set up somewhere.
> >>> +
> >>> +The virtual display bridge solves this by defining a bridge with
> >>> +all timing characteristics encoded into the device tree node.
> >>> +
> >>> +Required properies:
> >>> +- compatible: shall be "virtual-display-bridge"
> >>> +
> >>> +Required subnodes:
> >>> +- display-timings: contains in turn a display timing node
> >>> +  see display-timing.txt
> >>> +- ports: contains the display ports, see media/video-interfaces.txt
> >>> +
> >>> +Example:
> >>> +
> >>> +bridge {
> >>> +	compatible = "virtual-display-bridge";
> >>> +	#address-cells = <1>;
> >>> +	#size-cells = <0>;
> >>> +
> >>> +	display-timings {
> >>> +		/* Some standard VGA timing */
> >>> +		timing0 {
> >>> +			clock-frequency = <23750>;
> >>> +			hactive = <640>;
> >>> +			vactive = <480>;
> >>> +			hfront-porch = <48>;
> >>> +			hback-porch = <16>;
> >>> +			hsync-len = <96>;
> >>> +			vfront-porch = <33>;
> >>> +			vback-porch = <9>;
> >>> +			vsync-len = <3>;
> >>> +			vrefresh = <60>;
> >>> +		};
> >>> +	};
> >>> +
> >>> +	ports {
> >>> +		#address-cells = <1>;
> >>> +		#size-cells = <0>;
> >>> +
> >>> +		port@0 {
> >>> +			reg = <0>;
> >>> +
> >>> +			display_bridge_in: endpoint {
> >>> +				remote-endpoint = <&foo>;
> >>> +			};
> >>> +		};
> >>> +	};
> >>> +};
> >>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add virtual display DT bindings

[Liviu Dudau]

On Wed, Aug 29, 2018 at 10:16:34AM +0200, Andrzej Hajda wrote:
> On 28.08.2018 16:35, Liviu Dudau wrote:
> > Hi Andrzej,
> >
> > Chirping in, as it was originally my work that Linus is adopting.
> >
> > On Mon, Aug 27, 2018 at 01:53:00PM +0200, Andrzej Hajda wrote:
> >> On 24.08.2018 14:23, Linus Walleij wrote:
> >>> This adds bindings for a virtual display to be used with displays
> >>> inside entirely virtual environments which do not emulate things
> >>> like monitors but just need timing information to be supplied to
> >>> its display controller.
> >>>
> >>> This is inspired by earlier work by Liviu Dudau.
> >> If this is pure virtual then it should be connected to other pure
> >> virtual components.
> > Any reason why you think this is the only way this should be connected?
> 
> I think pure virtual sink device cannot be connected to real pins of
> source device :)

I guess I have a wider view on what a source device can be. :)

> Either source exposes some virtual interfaces either its output will go
> to /dev/null, it would be good to know which case author want to address
> with these patches.

Two scenarios where this is useful: in an emulator (like QEMU or Arm's
RTSM) the CRTC device is being emulated, but the rest of the display
chain is being shortcut by reading the framebuffer data assigned to the
CRTC and displaying it directly (either by using an X11 window, or by
streaming it out to a VNC client). Or you have some real hardware, where
the real pins are connected to a bridge, but the bridge is under the
control of the firmware and can only be configured by it, without any
API to interact with from the kernel side. In that case the best you can
do is to put in the device tree a description of what the firmware did
and use that.

> 
> > My original implementation (and I haven't seen anything in this patch
> > that would invalidate it) assumed that the virtual bridge can be used by
> > any driver that uses the component framework. Hiding implementation
> > details is one of the benefits of using the component framework, so I
> > don't see what you gain by restricting connection to only other pure
> > virtual components.
> 
> I suppose these patches were created for some reason, so more
> explanation will be helpful.
> 
> >
> >> What will be this virtual bridge attached to? I expect some virtual
> >> encoder, virtual crtc? If yes then why don't you create whole virtual
> >> drm pipeline in one patchset?
> > This comment is probably more relevant to patch 2/2, but I agree that
> > it probably needs a virtual encoder. As for the CRTC, it should work
> > with any real DRM driver, AFAICT.
> 
> I do not think so, I guess it could work with sources which do not
> communicate with sinks, ie. they have only output pins - in such case
> video stream will not be visible, is this something we want? Why?
> In case source expects some signals on pins connected to sink, it could
> be problematic.

It is not about how the hardware is connected, it is about discoverability
and the ability to control some of the parts in the chain. When that ability
is missing, you are forced to emulate the parts with a "virtual" bridge.

Best regards,
Liviu

> 
> >
> >> Could you describe more what do you want to do.
> > He wants to enable the PL110 DRM driver on systems that lack a way of
> > detecting the actual encoder and connector being used (either because
> > there is none and they are emulated in software that doesn't mimic the
> > HW behaviour, or because the way you access the HW is done in a way that
> > doesn't model easily in the current DRM framework: by firmware, for
> > example).
> 
> And finally here is real reason to cope with. Since Linus also explained
> it in separate mail I will continue the thread with answering to his mail.
> 
> 
> Regards
> Andrzej
> 
> >
> > Best regards,
> > Liviu
> >
> >> And one more thing, you are defining virtual panel but you are using
> >> drm_bridge framework, why not drm_panel?
> >>
> >> Regards
> >> Andrzej
> >>
> >>> Cc: Liviu Dudau <Liviu.Dudau@arm.com>
> >>> Cc: Ryan Harkin <ryan.harkin@linaro.org>
> >>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>> ---
> >>>  .../display/bridge/virtual-display-bridge.txt | 62 +++++++++++++++++++
> >>>  1 file changed, 62 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>> new file mode 100644
> >>> index 000000000000..ea4f5a91ab94
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> >>> @@ -0,0 +1,62 @@
> >>> +Virtual Display Bridge
> >>> +
> >>> +This represents a display that is contained within an emulated
> >>> +environment.
> >>> +
> >>> +This means that the display engine mainly expects some timing
> >>> +parameters to be written into it, and after that the emulator will
> >>> +respond by creating a virtual display with the requested
> >>> +resolution characteristics.
> >>> +
> >>> +As the operating system cannot "detect" such a display, rather the
> >>> +emulator will respond to what the controller outputs, a
> >>> +chicken-and-egg problem needs to be solved: the resolution and
> >>> +timing characteristics need to be defined and set up somewhere.
> >>> +
> >>> +The virtual display bridge solves this by defining a bridge with
> >>> +all timing characteristics encoded into the device tree node.
> >>> +
> >>> +Required properies:
> >>> +- compatible: shall be "virtual-display-bridge"
> >>> +
> >>> +Required subnodes:
> >>> +- display-timings: contains in turn a display timing node
> >>> +  see display-timing.txt
> >>> +- ports: contains the display ports, see media/video-interfaces.txt
> >>> +
> >>> +Example:
> >>> +
> >>> +bridge {
> >>> +	compatible = "virtual-display-bridge";
> >>> +	#address-cells = <1>;
> >>> +	#size-cells = <0>;
> >>> +
> >>> +	display-timings {
> >>> +		/* Some standard VGA timing */
> >>> +		timing0 {
> >>> +			clock-frequency = <23750>;
> >>> +			hactive = <640>;
> >>> +			vactive = <480>;
> >>> +			hfront-porch = <48>;
> >>> +			hback-porch = <16>;
> >>> +			hsync-len = <96>;
> >>> +			vfront-porch = <33>;
> >>> +			vback-porch = <9>;
> >>> +			vsync-len = <3>;
> >>> +			vrefresh = <60>;
> >>> +		};
> >>> +	};
> >>> +
> >>> +	ports {
> >>> +		#address-cells = <1>;
> >>> +		#size-cells = <0>;
> >>> +
> >>> +		port at 0 {
> >>> +			reg = <0>;
> >>> +
> >>> +			display_bridge_in: endpoint {
> >>> +				remote-endpoint = <&foo>;
> >>> +			};
> >>> +		};
> >>> +	};
> >>> +};
> >>
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?