On Mon, Mar 19, 2018 at 2:15 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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@xxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
