Rob Herring <robh+dt@xxxxxxxxxx> wrote on Fri [2018-Mar-02 13:19:13 -0600]: > On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot <bparrot@xxxxxx> wrote: > > Add 'plane' child node to generic DISPC node as an optional > > property. > > Why? What problem are you solving? Ah yes, I guess on its own it does not mean much... How about: 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 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 sub-node to the generic DISPC node. > > > > > Signed-off-by: Benoit Parrot <bparrot@xxxxxx> > > --- > > .../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 ++++++++++++++++++++++ > > 1 file changed, 63 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..cb101525b805 100644 > > --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > @@ -27,6 +27,34 @@ DISPC > > Optional properties: > > - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit > > in bytes per second > > +- plane: Child node(s) which defines which logical plane are available to > > This is the "Optional properties" section and plane is not a property. Right, I'll correct that to an optional sub-node which has required and optional properties. > > > + 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 number the logical plane > > Is logical plane a h/w concept? It does represent a hardware resource. > > > + - hw-planes: One or two HW plane number(s). > > + When 2 numbers are present this indicates a virtual 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 virtual plane. This means that for proper > > + operation the virtual plane should be composed of HW > > + planes of the same capabilities. > > + If GFX plane is used in a virtual plane it should be > > + specified first, otherwise unexpected behavior would > > + be encountered. > > + Optional property: > > + - hw-crtcs: One or more HW crtc number(s). > > + Describe the list of CRTCs on which this plane is > > + available. If this node is not present then the > > + plane will be available on all available CRTCs. > > Let's not copy archaic terms from DRM into bindings. Ok, I can rename them to use the TRM terminology instead. I chose DRM term because they are well known. So we'll have video-pipeline instead of hw-planes video-output instead of hw-crtcs Any comments on the sub-node name itself? Or can we keep 'plane'? > > Really, I'm skeptical that any of this belongs in DT. For example, > can't you figure out you need 2 physical planes whenever your > panel/timing width is greater than 2048? As stated in the description I added above, we cannot have resources exposed to user-space which can "disappear" dynamically. Doing so would break user-space applications which rely on these resources. Benoit > > Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
