On Fri, Mar 23, 2018 at 2:53 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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 -- 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
