| Message ID | 20180302134804.3690-3-bparrot@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot <bparrot@ti.com> wrote: > Add 'plane' child node to generic DISPC node as an optional > property. Why? What problem are you solving? > > Signed-off-by: Benoit Parrot <bparrot@ti.com> > --- > .../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. > + 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? > + - 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. 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? Rob
Rob Herring <robh+dt@kernel.org> wrote on Fri [2018-Mar-02 13:19:13 -0600]: > On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot <bparrot@ti.com> 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@ti.com> > > --- > > .../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
On 09/03/18 20:27, Benoit Parrot wrote: >> Is logical plane a h/w concept? > > It does represent a hardware resource. Logical plane is not a hw concept, it just describes a group of one or two HW planes. Then again, in the context of 2k+ displays, two HW planes must always be used together, so that way it could be considered a single HW resource. >> 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. The question is, if not in DT, then where? I agree that this is not exactly describing the HW. But it can't be done dynamically either (or at least we have not figured out a way). And it must be user configurable. Module parameters are an option, but it would be somewhat difficult to give all this information there. And also, if your board has a 2k+ display, you must have these configurations given to the driver, it's not optional. And while it's perhaps stretching the definitions a bit, I guess one could argue that this describes the HW in a way: it describes how the HW resources must be used if you have a display of 2k+ width, and is not as such related to Linux or DRM. Tomi
On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > On 09/03/18 20:27, Benoit Parrot wrote: > >>> Is logical plane a h/w concept? >> >> It does represent a hardware resource. > > Logical plane is not a hw concept, it just describes a group of one or > two HW planes. Then again, in the context of 2k+ displays, two HW planes > must always be used together, so that way it could be considered a > single HW resource. > >>> 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. Isn't this the point of atomic mode setting? If you have 2 planes free, then you can support the mode, otherwise you fail. How would a plane be in use if you are doing modesetting unless it is on another display? > The question is, if not in DT, then where? I agree that this is not > exactly describing the HW. But it can't be done dynamically either (or > at least we have not figured out a way). And it must be user configurable. If you are plugging in a monitor, doesn't it have to be dynamic? > Module parameters are an option, but it would be somewhat difficult to > give all this information there. And also, if your board has a 2k+ > display, you must have these configurations given to the driver, it's > not optional. Can't you look at the panel size on boot or module load and determine if you need to combine planes or not. The main difference I see is that the driver would have to figure out which planes to use rather than DT telling it what planes to use. Is deciding which planes a hard problem? > > And while it's perhaps stretching the definitions a bit, I guess one > could argue that this describes the HW in a way: it describes how the HW > resources must be used if you have a display of 2k+ width, and is not as > such related to Linux or DRM. > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Rob, On 19/03/18 02:06, Rob Herring wrote: > On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: >> On 09/03/18 20:27, Benoit Parrot wrote: >> >>>> Is logical plane a h/w concept? >>> >>> It does represent a hardware resource. >> >> Logical plane is not a hw concept, it just describes a group of one or >> two HW planes. Then again, in the context of 2k+ displays, two HW planes >> must always be used together, so that way it could be considered a >> single HW resource. >> >>>> 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. > > Isn't this the point of atomic mode setting? If you have 2 planes > free, then you can support the mode, otherwise you fail. How would a > plane be in use if you are doing modesetting unless it is on another > display? > >> The question is, if not in DT, then where? I agree that this is not >> exactly describing the HW. But it can't be done dynamically either (or >> at least we have not figured out a way). And it must be user configurable. > > If you are plugging in a monitor, doesn't it have to be dynamic? > >> Module parameters are an option, but it would be somewhat difficult to >> give all this information there. And also, if your board has a 2k+ >> display, you must have these configurations given to the driver, it's >> not optional. > > Can't you look at the panel size on boot or module load and determine > if you need to combine planes or not. The main difference I see is > that the driver would have to figure out which planes to use rather > than DT telling it what planes to use. Is deciding which planes a hard > problem? Ok, I think the description was a bit unclear. So, the driver can do this just fine, it can reserve hw planes dynamically when needed. The problem is the userspace. When a DRM application starts, it sees a bunch of planes, and can see on which crtcs each plane can be used. The expectation is, of course, that these planes can be used normally. If the driver would dynamically reserve an additional, currently unused plane, the userspace would be totally baffled, as it fails to configure basic plane setups. For example, the userspace could see that there are two planes, usable on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, except when the LCD already has a plane. Setting up two planes on the LCD would work, but moving one or both planes to the HDMI would fail. Etc. We could, of course, convey this information to the userspace at runtime via the DRM properties, but then it would mean we'd need customized applications. So, as far as I can see, keeping normal DRM behavior with 2k+ displays on OMAP DSS requires a static virtual plane setup. The most simple setup would be to just split the number of available planes by 2, but then in many use cases that wastes one hw plane. Tomi
On Mon, Mar 19, 2018 at 2:15 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > Hi Rob, > > On 19/03/18 02:06, Rob Herring wrote: >> On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: >>> On 09/03/18 20:27, Benoit Parrot wrote: >>> >>>>> Is logical plane a h/w concept? >>>> >>>> It does represent a hardware resource. >>> >>> Logical plane is not a hw concept, it just describes a group of one or >>> two HW planes. Then again, in the context of 2k+ displays, two HW planes >>> must always be used together, so that way it could be considered a >>> single HW resource. >>> >>>>> 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. >> >> Isn't this the point of atomic mode setting? If you have 2 planes >> free, then you can support the mode, otherwise you fail. How would a >> plane be in use if you are doing modesetting unless it is on another >> display? >> >>> The question is, if not in DT, then where? I agree that this is not >>> exactly describing the HW. But it can't be done dynamically either (or >>> at least we have not figured out a way). And it must be user configurable. >> >> If you are plugging in a monitor, doesn't it have to be dynamic? >> >>> Module parameters are an option, but it would be somewhat difficult to >>> give all this information there. And also, if your board has a 2k+ >>> display, you must have these configurations given to the driver, it's >>> not optional. >> >> Can't you look at the panel size on boot or module load and determine >> if you need to combine planes or not. The main difference I see is >> that the driver would have to figure out which planes to use rather >> than DT telling it what planes to use. Is deciding which planes a hard >> problem? > > Ok, I think the description was a bit unclear. So, the driver can do > this just fine, it can reserve hw planes dynamically when needed. The > problem is the userspace. > > When a DRM application starts, it sees a bunch of planes, and can see on > which crtcs each plane can be used. The expectation is, of course, that > these planes can be used normally. If the driver would dynamically > reserve an additional, currently unused plane, the userspace would be > totally baffled, as it fails to configure basic plane setups. > > For example, the userspace could see that there are two planes, usable > on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail > if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, > except when the LCD already has a plane. Setting up two planes on the > LCD would work, but moving one or both planes to the HDMI would fail. Etc. I suspect this is a common problem. Not because the h/w requires different allocation of planes, but because the memory bandwidth can't handle having a 2nd plane if the resolution is above a certain size/depth. So while the plane doesn't disappear, the effect is the same. How does DRM handle this? > We could, of course, convey this information to the userspace at runtime > via the DRM properties, but then it would mean we'd need customized > applications. > > So, as far as I can see, keeping normal DRM behavior with 2k+ displays > on OMAP DSS requires a static virtual plane setup. The most simple setup > would be to just split the number of available planes by 2, but then in > many use cases that wastes one hw plane. For HDMI, you can't know in advance what resolution will be. So I think you always need to reserve 2 planes. Now, if you want to reduce the max resolution for some reason, I guess we could have properties for that. That would be more generic and work whether you need to change plane allocation or have a limit for other reasons. For attached panels, you know the resolution up front and can allocate planes before the userspace interface is up. Rob
Hi Rob, On 23/03/18 03:23, Rob Herring wrote: >> Ok, I think the description was a bit unclear. So, the driver can do >> this just fine, it can reserve hw planes dynamically when needed. The >> problem is the userspace. >> >> When a DRM application starts, it sees a bunch of planes, and can see on >> which crtcs each plane can be used. The expectation is, of course, that >> these planes can be used normally. If the driver would dynamically >> reserve an additional, currently unused plane, the userspace would be >> totally baffled, as it fails to configure basic plane setups. >> >> For example, the userspace could see that there are two planes, usable >> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail >> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, >> except when the LCD already has a plane. Setting up two planes on the >> LCD would work, but moving one or both planes to the HDMI would fail. Etc. > > I suspect this is a common problem. Not because the h/w requires > different allocation of planes, but because the memory bandwidth can't > handle having a 2nd plane if the resolution is above a certain > size/depth. So while the plane doesn't disappear, the effect is the > same. How does DRM handle this? I don't think DRM handles this. Each driver can probably filter out videomodes which it knows can't be used even with single plane (we do this on omapdrm), and also can give an error if the plane setup would result in too high bandwidth use. So yes, plane setups can always fail, "mysteriously" from userspace's perspective. But I don't think it's exactly comparable to this one. The difference is that in this case we can avoid all the userspace issues with a simple static plane partitioning done at probe time, but I can't see how the bandwidth issue could be solved in a similar way. >> We could, of course, convey this information to the userspace at runtime >> via the DRM properties, but then it would mean we'd need customized >> applications. >> >> So, as far as I can see, keeping normal DRM behavior with 2k+ displays >> on OMAP DSS requires a static virtual plane setup. The most simple setup >> would be to just split the number of available planes by 2, but then in >> many use cases that wastes one hw plane. > > For HDMI, you can't know in advance what resolution will be. So I > think you always need to reserve 2 planes. Now, if you want to reduce We can decide not to support 2k+ resolutions for HDMI, which, with this series, happens by not reserving dual-plane for the HDMI. > the max resolution for some reason, I guess we could have properties > for that. That would be more generic and work whether you need to > change plane allocation or have a limit for other reasons. > > For attached panels, you know the resolution up front and can allocate > planes before the userspace interface is up. But reserve how many of the planes? We have N planes and M displays. For some of the displays we know they're 2k+, some are known to be -2k and some are unknown. The driver can't independently make any sensible static reservation of the planes for the displays, because it doesn't know what the user wants to do. So either we reserve the extra planes at runtime on demand, making it difficult to manage for the userspace, or we rely on the user to give the driver a static partitioning of the planes according to the user's use case. Tomi
On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > Hi Rob, > > On 23/03/18 03:23, Rob Herring wrote: > >>> Ok, I think the description was a bit unclear. So, the driver can do >>> this just fine, it can reserve hw planes dynamically when needed. The >>> problem is the userspace. >>> >>> When a DRM application starts, it sees a bunch of planes, and can see on >>> which crtcs each plane can be used. The expectation is, of course, that >>> these planes can be used normally. If the driver would dynamically >>> reserve an additional, currently unused plane, the userspace would be >>> totally baffled, as it fails to configure basic plane setups. >>> >>> For example, the userspace could see that there are two planes, usable >>> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail >>> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work, >>> except when the LCD already has a plane. Setting up two planes on the >>> LCD would work, but moving one or both planes to the HDMI would fail. Etc. >> >> I suspect this is a common problem. Not because the h/w requires >> different allocation of planes, but because the memory bandwidth can't >> handle having a 2nd plane if the resolution is above a certain >> size/depth. So while the plane doesn't disappear, the effect is the >> same. How does DRM handle this? > > I don't think DRM handles this. Each driver can probably filter out > videomodes which it knows can't be used even with single plane (we do > this on omapdrm), and also can give an error if the plane setup would > result in too high bandwidth use. > > So yes, plane setups can always fail, "mysteriously" from userspace's > perspective. But I don't think it's exactly comparable to this one. The > difference is that in this case we can avoid all the userspace issues > with a simple static plane partitioning done at probe time, but I can't > see how the bandwidth issue could be solved in a similar way. > >>> We could, of course, convey this information to the userspace at runtime >>> via the DRM properties, but then it would mean we'd need customized >>> applications. >>> >>> So, as far as I can see, keeping normal DRM behavior with 2k+ displays >>> on OMAP DSS requires a static virtual plane setup. The most simple setup >>> would be to just split the number of available planes by 2, but then in >>> many use cases that wastes one hw plane. >> >> For HDMI, you can't know in advance what resolution will be. So I >> think you always need to reserve 2 planes. Now, if you want to reduce > > We can decide not to support 2k+ resolutions for HDMI, which, with this > series, happens by not reserving dual-plane for the HDMI. Right. So turn this around. Define in DT what is the maximum resolution supported for HDMI and configure the planes based on that. The difference is defining a max is generic enough that it can work for others and for a variety of reasons whether it is # of planes, memory bandwidth, crappy monitor, poor board signal quality, etc. >> the max resolution for some reason, I guess we could have properties >> for that. That would be more generic and work whether you need to >> change plane allocation or have a limit for other reasons. >> >> For attached panels, you know the resolution up front and can allocate >> planes before the userspace interface is up. > > But reserve how many of the planes? We have N planes and M displays. For > some of the displays we know they're 2k+, some are known to be -2k and > some are unknown. The driver can't independently make any sensible > static reservation of the planes for the displays, because it doesn't > know what the user wants to do. After you've handled HDMI as above and any permanently attached panels with fixed resolutions, what is left for a user to configure? Perhaps only one display can support an overlay at that point because you are out of planes? > So either we reserve the extra planes at runtime on demand, making it > difficult to manage for the userspace, or we rely on the user to give > the driver a static partitioning of the planes according to the user's > use case. And by user, who do you mean exactly? The use case is tied to the board design and product or tied to the whims of an end user (e.g. I want to do video playback with overlay to disp 2)? You should equate users making DT changes with telling users to update/change their BIOS. Rob
Hi Rob, On 09/04/18 21:17, Rob Herring wrote: >>> For HDMI, you can't know in advance what resolution will be. So I >>> think you always need to reserve 2 planes. Now, if you want to reduce >> >> We can decide not to support 2k+ resolutions for HDMI, which, with this >> series, happens by not reserving dual-plane for the HDMI. > > Right. So turn this around. Define in DT what is the maximum > resolution supported for HDMI and configure the planes based on that. But the kernel cannot know what the user wants to do, so it cannot configure the planes. If we have an HDMI output which supports 2k+ and a -2k LCD, and 4 hw planes, we can set up the planes at least in the following ways: - One virtual plane on HDMI, two normal planes on LCD. Here the normal planes can also be used on the HDMI, as long as the input width is -2k. - One virtual plane on HDMI, one virtual plane on LCD, but sometimes both planes on the same display (either HDMI or LCD). - No virtual planes (and fbdev support disabled). This needs the userspace to take care not to configure 2k+ planes. But considering that the modes supported are still quit close to 2k in width, I believe upscaling a 2k plane cover the whole display would provide quite ok image. Each of those requires a different virtual plane setup. >> But reserve how many of the planes? We have N planes and M displays. For >> some of the displays we know they're 2k+, some are known to be -2k and >> some are unknown. The driver can't independently make any sensible >> static reservation of the planes for the displays, because it doesn't >> know what the user wants to do. > > After you've handled HDMI as above and any permanently attached panels > with fixed resolutions, what is left for a user to configure? Perhaps > only one display can support an overlay at that point because you are > out of planes? I think I covered this in the example use cases above. >> So either we reserve the extra planes at runtime on demand, making it >> difficult to manage for the userspace, or we rely on the user to give >> the driver a static partitioning of the planes according to the user's >> use case. > > And by user, who do you mean exactly? The use case is tied to the > board design and product or tied to the whims of an end user (e.g. I > want to do video playback with overlay to disp 2)? You should equate > users making DT changes with telling users to update/change their > BIOS. By user I mean the owner of the device, but it in some cases it could be the vendor too. If we have a board with HDMI that can support 2k+, then the board vendor could provide DT files that do not specify virtual planes (so no 2k+), but give instructions how to define them for the users who want 2k+. So here the end user needs to deal with the static partitioning. If we have a board with a fixed resolution 2k+ LCD, then the vendor has to have a virtual plane defined in the DT, and the vendor has to pick a configuration that it thinks is most useful. And yes, it sucks to have to make changes in the DT or BIOS, but I still don't see a (good) alternative. I think one option is to have the detailed DT configuration optional: We'd have a flag in the DT to mark that a display supports 2k+ (or the max-resolution property as you suggested). Based on that, the driver guesses what kind of setup the user wants, which probably is just to set up planes in a way that each display has a fully functional "root" plane, and then split the remaining ones in some way. But the user could also have detailed DT descriptions for the planes when he needs a more special setup. Tomi
On Tue, Apr 17, 2018 at 05:37:25PM +0300, Tomi Valkeinen wrote: > Hi Rob, > > On 09/04/18 21:17, Rob Herring wrote: > > >>> For HDMI, you can't know in advance what resolution will be. So I > >>> think you always need to reserve 2 planes. Now, if you want to reduce > >> > >> We can decide not to support 2k+ resolutions for HDMI, which, with this > >> series, happens by not reserving dual-plane for the HDMI. > > > > Right. So turn this around. Define in DT what is the maximum > > resolution supported for HDMI and configure the planes based on that. > > But the kernel cannot know what the user wants to do, so it cannot > configure the planes. If we have an HDMI output which supports 2k+ and a > -2k LCD, and 4 hw planes, we can set up the planes at least in the > following ways: > > - One virtual plane on HDMI, two normal planes on LCD. Here the normal > planes can also be used on the HDMI, as long as the input width is -2k. > > - One virtual plane on HDMI, one virtual plane on LCD, but sometimes > both planes on the same display (either HDMI or LCD). > > - No virtual planes (and fbdev support disabled). This needs the > userspace to take care not to configure 2k+ planes. But considering that > the modes supported are still quit close to 2k in width, I believe > upscaling a 2k plane cover the whole display would provide quite ok image. > > Each of those requires a different virtual plane setup. Why do you want to hardcode this in DT? The recommended approach is to have a bunch of virtual planes, and runtime assign whatever hw resources you need to get there. If you run out of hw planes you just fail with -EINVAL in atomic_check. And reassigning hw planes is allowed to be really expensive, that's why we have the ALLOW_MODESET flag so userspace can choose whether it wants to allow expensive reassignment or not. For examples, see what msm folks are trying to do right now. -Daniel > >> But reserve how many of the planes? We have N planes and M displays. For > >> some of the displays we know they're 2k+, some are known to be -2k and > >> some are unknown. The driver can't independently make any sensible > >> static reservation of the planes for the displays, because it doesn't > >> know what the user wants to do. > > > > After you've handled HDMI as above and any permanently attached panels > > with fixed resolutions, what is left for a user to configure? Perhaps > > only one display can support an overlay at that point because you are > > out of planes? > > I think I covered this in the example use cases above. > > >> So either we reserve the extra planes at runtime on demand, making it > >> difficult to manage for the userspace, or we rely on the user to give > >> the driver a static partitioning of the planes according to the user's > >> use case. > > > > And by user, who do you mean exactly? The use case is tied to the > > board design and product or tied to the whims of an end user (e.g. I > > want to do video playback with overlay to disp 2)? You should equate > > users making DT changes with telling users to update/change their > > BIOS. > > By user I mean the owner of the device, but it in some cases it could be > the vendor too. > > If we have a board with HDMI that can support 2k+, then the board vendor > could provide DT files that do not specify virtual planes (so no 2k+), > but give instructions how to define them for the users who want 2k+. So > here the end user needs to deal with the static partitioning. > > If we have a board with a fixed resolution 2k+ LCD, then the vendor has > to have a virtual plane defined in the DT, and the vendor has to pick a > configuration that it thinks is most useful. > > And yes, it sucks to have to make changes in the DT or BIOS, but I still > don't see a (good) alternative. > > I think one option is to have the detailed DT configuration optional: > > We'd have a flag in the DT to mark that a display supports 2k+ (or the > max-resolution property as you suggested). Based on that, the driver > guesses what kind of setup the user wants, which probably is just to set > up planes in a way that each display has a fully functional "root" > plane, and then split the remaining ones in some way. > > But the user could also have detailed DT descriptions for the planes > when he needs a more special setup. > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 19/04/18 09:34, Daniel Vetter wrote: >> But the kernel cannot know what the user wants to do, so it cannot >> configure the planes. If we have an HDMI output which supports 2k+ and a >> -2k LCD, and 4 hw planes, we can set up the planes at least in the >> following ways: >> >> - One virtual plane on HDMI, two normal planes on LCD. Here the normal >> planes can also be used on the HDMI, as long as the input width is -2k. >> >> - One virtual plane on HDMI, one virtual plane on LCD, but sometimes >> both planes on the same display (either HDMI or LCD). >> >> - No virtual planes (and fbdev support disabled). This needs the >> userspace to take care not to configure 2k+ planes. But considering that >> the modes supported are still quit close to 2k in width, I believe >> upscaling a 2k plane cover the whole display would provide quite ok image. >> >> Each of those requires a different virtual plane setup. > > Why do you want to hardcode this in DT? The recommended approach is to > have a bunch of virtual planes, and runtime assign whatever hw resources > you need to get there. If you run out of hw planes you just fail with > -EINVAL in atomic_check. That is possible, but how many userspace apps will work correctly if the planes work or don't work in a random manner (from userspace's point of view)? I like the idea more that the DRM driver exposes a lesser number of planes which always work, instead of exposing larger number of planes which sometimes do not work. And with userspace apps, I don't mainly mean Weston and X, but instead the numerous custom applications the customers write themselves. Perhaps I'm worrying too much, but I can imagine a flood of support requests about why plane setup is not working when one does this or that simple setup. Also one complication with runtime assignment is that the hw planes are not identical: some support YUV modes, some don't, some support scaling, some don't. That's probably not a show stopper, but it does limit the options as e.g. we can't have all virtual planes advertising YUV support when we have a hw plane that doesn't support YUV. Tomi
On Thu, Apr 19, 2018 at 10:11:05AM +0300, Tomi Valkeinen wrote: > On 19/04/18 09:34, Daniel Vetter wrote: > > >> But the kernel cannot know what the user wants to do, so it cannot > >> configure the planes. If we have an HDMI output which supports 2k+ and a > >> -2k LCD, and 4 hw planes, we can set up the planes at least in the > >> following ways: > >> > >> - One virtual plane on HDMI, two normal planes on LCD. Here the normal > >> planes can also be used on the HDMI, as long as the input width is -2k. > >> > >> - One virtual plane on HDMI, one virtual plane on LCD, but sometimes > >> both planes on the same display (either HDMI or LCD). > >> > >> - No virtual planes (and fbdev support disabled). This needs the > >> userspace to take care not to configure 2k+ planes. But considering that > >> the modes supported are still quit close to 2k in width, I believe > >> upscaling a 2k plane cover the whole display would provide quite ok image. > >> > >> Each of those requires a different virtual plane setup. > > > > Why do you want to hardcode this in DT? The recommended approach is to > > have a bunch of virtual planes, and runtime assign whatever hw resources > > you need to get there. If you run out of hw planes you just fail with > > -EINVAL in atomic_check. > > That is possible, but how many userspace apps will work correctly if the > planes work or don't work in a random manner (from userspace's point of > view)? I like the idea more that the DRM driver exposes a lesser number > of planes which always work, instead of exposing larger number of planes > which sometimes do not work. > > And with userspace apps, I don't mainly mean Weston and X, but instead > the numerous custom applications the customers write themselves. Perhaps > I'm worrying too much, but I can imagine a flood of support requests > about why plane setup is not working when one does this or that simple > setup. Stuff randomly not working is officially how atomic works. That's what the TEST_ONLY mode is for. There's a lot more than virtualized planes that might or might not push any given plane setup over some random hw limit: memory bandwidth, aggregate scaling limits (because not enough fifo), thermal limits, aggregate pixel clock limits. There's all kinds of cases where with one setup you can light up 4 planes, then move them a bit and only 3 work. And yes sometimes that means you can't light up all the outputs if you have a too fancy plane config on the other CRTC. Only userspace which is written with intimate knowledge of the exact kernel driver and hw it runs on can avoid TEST_ONLY and some kind of fallback strategy to "render everything into the 1 single primary plane". Both drm_hwcomposer and weston atomic have such a fallback strategy (with various degrees of intermediate cleverness). > Also one complication with runtime assignment is that the hw planes are > not identical: some support YUV modes, some don't, some support scaling, > some don't. That's probably not a show stopper, but it does limit the > options as e.g. we can't have all virtual planes advertising YUV support > when we have a hw plane that doesn't support YUV. Yeah that makes it a notch more complicated to implement. -Daniel
On 20/04/18 10:00, Daniel Vetter wrote: (Adding Benoit back, he was dropped at some point in the thread) > Stuff randomly not working is officially how atomic works. That's what the > TEST_ONLY mode is for. There's a lot more than virtualized planes that > might or might not push any given plane setup over some random hw limit: > memory bandwidth, aggregate scaling limits (because not enough fifo), > thermal limits, aggregate pixel clock limits. There's all kinds of cases > where with one setup you can light up 4 planes, then move them a bit and > only 3 work. And yes sometimes that means you can't light up all the > outputs if you have a too fancy plane config on the other CRTC. > > Only userspace which is written with intimate knowledge of the exact > kernel driver and hw it runs on can avoid TEST_ONLY and some kind of > fallback strategy to "render everything into the 1 single primary plane". > Both drm_hwcomposer and weston atomic have such a fallback strategy (with > various degrees of intermediate cleverness). Ok, thanks. This makes sense to me, and actually makes our (driver developers) life easier... Is "Stuff randomly not working is officially how atomic works." mentioned in the DRM documentation? I think that sentence summarizes it quite well =). Does the driver still have some minimal set of functionality it always has to allow? E.g. is enabling all the available displays with the display's native resolution (or whatever passes the mode_valid), each with a single non-scaled full-screen primary plane, something every driver should ensure is always possible? Tomi
On Fri, Apr 20, 2018 at 10:21:35AM +0300, Tomi Valkeinen wrote: > On 20/04/18 10:00, Daniel Vetter wrote: > > (Adding Benoit back, he was dropped at some point in the thread) > > > Stuff randomly not working is officially how atomic works. That's what the > > TEST_ONLY mode is for. There's a lot more than virtualized planes that > > might or might not push any given plane setup over some random hw limit: > > memory bandwidth, aggregate scaling limits (because not enough fifo), > > thermal limits, aggregate pixel clock limits. There's all kinds of cases > > where with one setup you can light up 4 planes, then move them a bit and > > only 3 work. And yes sometimes that means you can't light up all the > > outputs if you have a too fancy plane config on the other CRTC. > > > > Only userspace which is written with intimate knowledge of the exact > > kernel driver and hw it runs on can avoid TEST_ONLY and some kind of > > fallback strategy to "render everything into the 1 single primary plane". > > Both drm_hwcomposer and weston atomic have such a fallback strategy (with > > various degrees of intermediate cleverness). > > Ok, thanks. This makes sense to me, and actually makes our (driver > developers) life easier... Is "Stuff randomly not working is officially > how atomic works." mentioned in the DRM documentation? I think that > sentence summarizes it quite well =). Hm, I think we fail to doc that properly, at least in-kernel. Improving atomic docs is somewhere on my huge todo list still :-/ The lwn article I've written does explain the motivation behind TEST_ONLY in detail though: https://lwn.net/Articles/653071/ > Does the driver still have some minimal set of functionality it always > has to allow? E.g. is enabling all the available displays with the > display's native resolution (or whatever passes the mode_valid), each > with a single non-scaled full-screen primary plane, something every > driver should ensure is always possible? Strive for, sure. "Always" is a bit much since you easily might run out of clocks (if they all run at different modes), or memmory bandwidth (if there's too many 8k screens) and stuff like that. It's really all best effort. The only guarantee we give for mode_valid is that you should be able to light this mode up if - no other CRTC enabled, - only using the primary plane, - and you tried all the pixel formats of that plane (in case xrbg8888 is too much you might need to try out rgb565, or *shock* C8). I think in practice just trying xrbg8888 should be good enough, since that's what plymouth and other simple generic userspace requires. You're running on some really funky hw if that doesn't work. Yes that guarantee is very minimal, but it's the best we can do really. Historical note aside: The above problem is why atomic's TEST_ONLY also works for modesets, and why atomic does updates across multiple CRTC: Intel's gen7 was the first popular platform that had 3 pipe support but in many situations only allowed to light up 2 outputs, not 3. Userspace died to no end on failed modesets :-/ -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..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 + 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 + - 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. Video Ports ----------- @@ -216,3 +244,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 plane #0 (i.e. GFX plane) + only available on crtc #0 +- plane#1 to be a virtual wide plane composed of HW plane #1 and #2 + (i.e. VID1 & VID2) available on crtc #0 & #1 +- plane#2 to be the HW plane #3 (i.e. VID3 plane) + only available on crtc #0 + +&dss { + dispc@58001000 { + #address-cells = <1>; + #size-cells = <0>; + + plane@0 { + reg = <0>; + hw-planes = <0>; + hw-crtcs = <0>; + }; + + plane@1 { + reg = <1>; + hw-planes = <1 2>; + hw-crtcs = <0 1>; + }; + + plane@2 { + reg = <2>; + hw-planes = <3>; + hw-crtcs = <0>; + }; + }; +};
Add 'plane' child node to generic DISPC node as an optional property. Signed-off-by: Benoit Parrot <bparrot@ti.com> --- .../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+)