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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
