| Message ID | 20180824122308.3092-1-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] drm/bridge: Add virtual display DT bindings | expand |
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>; > + }; > + }; > + }; > +};
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
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>; > > + }; > > + }; > > + }; > > +}; > >
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>; >>> + }; >>> + }; >>> + }; >>> +}; >>
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>; > >>> + }; > >>> + }; > >>> + }; > >>> +}; > >> >
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 > >
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 > > > > >
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 >>> >>>
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 > >>> > >>> >
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 >>>>> >>>>>
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
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
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>; + }; + }; + }; +};
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