| Message ID | 20180326162128.8740-4-bparrot@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Benoit, Thank you for the patch. On Monday, 26 March 2018 19:21:25 EEST Benoit Parrot wrote: > Currently all available display pipelines (i.e. plane) and output port > resources are exposed to user-space. In some cases it is needed to be > able to restrict which resources are actually visible from user-space. > Also in cases where a display wider than 2048 pixels is to be supported > more than one video pipeline is needed. In this case the 2nd hardware > pipeline needed is not visible to user space applications. > > These video pipeline definitions must be statically defined so that > the number of visible pipelines does not change from the user-space > perspective. > > In order to allow this we are adding an optional 'plane' sub-node to > the generic DISPC node. I'm sorry but this is really configuration data, it doesn't describe the hardware. I don't think these properties belong to DT. > Signed-off-by: Benoit Parrot <bparrot@ti.com> > --- > .../devicetree/bindings/display/ti/ti,omap-dss.txt | 65 +++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt index > 249e588d7865..2dd411cb5a83 100644 > --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > @@ -28,6 +28,36 @@ Optional properties: > - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth > limit in bytes per second > > +Optional Subnode: > +- plane: Child node(s) which defines which video planes are available to > + the system. If at least one plane child node is defined then > + only planes defined by these nodes will be available to the system. > + Plane nodes must be sequential starting with reg = <0> as DT parsing > + will stop on the first missing numbered node. > + This means if plane #1 is defined but plane #0 is not then it will > + be as if none of the plane nodes were defined. > + > + Each plane node contains the following properties: > + Required properties: > + - reg: Used to identify the plane > + - video-pipelines: One or two HW pipeline number(s). > + When 2 numbers are present this indicates a virtual wide > + plane composed of two physical planes intended to be used > + when the display is larger then the capacity of a > + single plane i.e. wider than 2048 pixels. > + The first number in the pair will dictate the capabilities > + of the plane. This means that for proper > + operation the virtual plane should be composed of HW > + planes of the same capabilities. > + If GFX pipeline is used in a virtual plane it should be > + specified first, otherwise unexpected behavior would > + be encountered. > + Optional property: > + - video-outputs: One or more HW output number(s). > + Describe the list of video output on which this plane > + is available. If this node is not present then the > + plane will be available on all available video output. > + > Video Ports > ----------- > > @@ -216,3 +246,38 @@ OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI > Connector }; > }; > }; > + > +A short example on how to define a virtual plane configuration > +to enable wide display support. > +Here we define: > +- plane#0 to be the HW pipeline #0 (i.e. GFX pipeline) > + only available on video output #0 > +- plane#1 to be a virtual wide plane composed of HW pipeline #1 and #2 > + (i.e. VID1 & VID2) available on video output #0 & #1 > +- plane#2 to be the HW pipeline #3 (i.e. VID3 pipeline) > + only available on video output #0 > + > +&dss { > + dispc@58001000 { > + #address-cells = <1>; > + #size-cells = <0>; > + > + plane@0 { > + reg = <0>; > + video-pipelines = <0>; > + video-outputs = <0>; > + }; > + > + plane@1 { > + reg = <1>; > + video-pipelines = <1 2>; > + video-outputs = <0 1>; > + }; > + > + plane@2 { > + reg = <2>; > + video-pipelines = <3>; > + video-outputs = <0>; > + }; > + }; > +};
On 04/04/18 17:36, Laurent Pinchart wrote: > Hi Benoit, > > Thank you for the patch. > > On Monday, 26 March 2018 19:21:25 EEST Benoit Parrot wrote: >> Currently all available display pipelines (i.e. plane) and output port >> resources are exposed to user-space. In some cases it is needed to be >> able to restrict which resources are actually visible from user-space. >> Also in cases where a display wider than 2048 pixels is to be supported >> more than one video pipeline is needed. In this case the 2nd hardware >> pipeline needed is not visible to user space applications. >> >> These video pipeline definitions must be statically defined so that >> the number of visible pipelines does not change from the user-space >> perspective. >> >> In order to allow this we are adding an optional 'plane' sub-node to >> the generic DISPC node. > > I'm sorry but this is really configuration data, it doesn't describe the > hardware. I don't think these properties belong to DT. I agree, but the question then is: where should it be? There was a discussion in the v1 thread about this, and as far as I see, there are no other usable alternatives. Tomi
On Wed, Apr 04, 2018 at 05:56:46PM +0300, Tomi Valkeinen wrote: > On 04/04/18 17:36, Laurent Pinchart wrote: > > Hi Benoit, > > > > Thank you for the patch. > > > > On Monday, 26 March 2018 19:21:25 EEST Benoit Parrot wrote: > >> Currently all available display pipelines (i.e. plane) and output port > >> resources are exposed to user-space. In some cases it is needed to be > >> able to restrict which resources are actually visible from user-space. > >> Also in cases where a display wider than 2048 pixels is to be supported > >> more than one video pipeline is needed. In this case the 2nd hardware > >> pipeline needed is not visible to user space applications. > >> > >> These video pipeline definitions must be statically defined so that > >> the number of visible pipelines does not change from the user-space > >> perspective. > >> > >> In order to allow this we are adding an optional 'plane' sub-node to > >> the generic DISPC node. > > > > I'm sorry but this is really configuration data, it doesn't describe the > > hardware. I don't think these properties belong to DT. > > I agree, but the question then is: where should it be? There was a > discussion in the v1 thread about this, and as far as I see, there are > no other usable alternatives. Runtime configuration and atomic_check not an option? See my reply in v1. -Daniel
diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt index 249e588d7865..2dd411cb5a83 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt @@ -28,6 +28,36 @@ Optional properties: - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit in bytes per second +Optional Subnode: +- plane: Child node(s) which defines which video planes are available to + the system. If at least one plane child node is defined then + only planes defined by these nodes will be available to the system. + Plane nodes must be sequential starting with reg = <0> as DT parsing + will stop on the first missing numbered node. + This means if plane #1 is defined but plane #0 is not then it will + be as if none of the plane nodes were defined. + + Each plane node contains the following properties: + Required properties: + - reg: Used to identify the plane + - video-pipelines: One or two HW pipeline number(s). + When 2 numbers are present this indicates a virtual wide + plane composed of two physical planes intended to be used + when the display is larger then the capacity of a + single plane i.e. wider than 2048 pixels. + The first number in the pair will dictate the capabilities + of the plane. This means that for proper + operation the virtual plane should be composed of HW + planes of the same capabilities. + If GFX pipeline is used in a virtual plane it should be + specified first, otherwise unexpected behavior would + be encountered. + Optional property: + - video-outputs: One or more HW output number(s). + Describe the list of video output on which this plane + is available. If this node is not present then the + plane will be available on all available video output. + Video Ports ----------- @@ -216,3 +246,38 @@ OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector }; }; }; + +A short example on how to define a virtual plane configuration +to enable wide display support. +Here we define: +- plane#0 to be the HW pipeline #0 (i.e. GFX pipeline) + only available on video output #0 +- plane#1 to be a virtual wide plane composed of HW pipeline #1 and #2 + (i.e. VID1 & VID2) available on video output #0 & #1 +- plane#2 to be the HW pipeline #3 (i.e. VID3 pipeline) + only available on video output #0 + +&dss { + dispc@58001000 { + #address-cells = <1>; + #size-cells = <0>; + + plane@0 { + reg = <0>; + video-pipelines = <0>; + video-outputs = <0>; + }; + + plane@1 { + reg = <1>; + video-pipelines = <1 2>; + video-outputs = <0 1>; + }; + + plane@2 { + reg = <2>; + video-pipelines = <3>; + video-outputs = <0>; + }; + }; +};
Currently all available display pipelines (i.e. plane) and output port resources are exposed to user-space. In some cases it is needed to be able to restrict which resources are actually visible from user-space. Also in cases where a display wider than 2048 pixels is to be supported more than one video pipeline is needed. In this case the 2nd hardware pipeline needed is not visible to user space applications. These video pipeline definitions must be statically defined so that the number of visible pipelines does not change from the user-space perspective. In order to allow this we are adding an optional 'plane' sub-node to the generic DISPC node. Signed-off-by: Benoit Parrot <bparrot@ti.com> --- .../devicetree/bindings/display/ti/ti,omap-dss.txt | 65 ++++++++++++++++++++++ 1 file changed, 65 insertions(+)