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 -- 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
