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 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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
