On Tue, Apr 1, 2014 at 8:40 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote: >>> I thought I'd kick off a thread to better discuss how to deal with >>> "large" displays which need multiple crtcs/planes merged to deal >>> without output larger than a certain width. >>> >>> What I have in mind basically amounts to driver-custom-properties and >>> shouldn't really need much/anything in the way of drm core or helper >>> support[1]. There may of course be some room to make helpers/core >>> more aware of crtc ganging if it turns out to be something that many >>> drivers are doing in the same way. But to start with my bigger >>> concern is getting the userspace interface right. >>> >>> This is semi-related to a thread started earlier by Aaron Plattner on >>> xorg-devel: >>> >>> http://lists.freedesktop.org/archives/xorg-devel/2014-January/039984.html >>> >>> As I see it, there are really two different scenarios: >>> >>> 1) single encoder/connector: double up on planes (pipes) and crtcs >>> (mixers), but still a single connector. >>> >>> 2) double up entire pipe.. this scenario is more like what Aaron >>> mentioned. This could mean using multiple DVI or HDMI connectors, or >>> multiple DSI channels. In the DSI case, I'm not entirely sure yet the >>> implications for a dsi panel driver, but I think it needs to be a bit >>> aware. >> >> I think this here is (mostly) a userspace problem of figuring out how the >> different outputs are laid out in reality. Only difference is that the hw >> might (not sure how far those standars really are) provide some definit >> hints. So imo not a kernel problem really. > > right, that is why I included the link back to the xorg-devel > discussion. The second scenario seems pretty similar to that. > > (although re-reading what I wrote, I realized I didn't connect those > two dots at all) > >>> ------------------- >>> >>> For the first scenario, the approach I am leaning towards is a >>> 'SLAVE_CRTC'[2] property on the crtc. The idea being that userspace >>> could pick an otherwise unused CRTC, and assign it as a slave in order >>> to enable higher resolutions. The primary crtc could use the slave's >>> mixer and primary plane. The existing encoder->possible_crtcs would >>> be used by userspace to figure out which crtc(s) it could pick to use >>> as a slave. >>> >>> The property approach seems like it should fit in nicely with the >>> plans for atomic. The driver can decide whether a given mode is >>> possible during the atomic 'test' step based on the proposed >>> SLAVE_CRTC value. We do possibly get funny edge cases where a CRTC >>> isn't yet available but will be after next vblank, but this is >>> basically the same scenario with have already with moving planes >>> between crtcs (and where an EBUSY or similar return value from atomic >>> would make sense). >>> >>> For non-primary planes, it may be sufficient to expose max >>> width/height dimensions and let userspace figure out when it needs to >>> use multiple planes for a single layer. >> >> I second the idea of exposing plane limits. I've cc'ed a thread on >> dri-devel where Damien&I discussed this a bit. We probably need a pile of >> per plane/per pixel format properties like max/min size, stride and a >> pile of flags for special cases. > > right, this is pretty much what I had in mind, a bunch of read-only properties > >> For the crtc ganging I wonder whether we even should expose this. For >> generic userspace it's just yet another random hardware restriction. E.g. >> in i915 we don't expose the various (and constantly changing between >> platforms) restrictions on plls. All we do is tell userspace that it >> didn't work out. > > True.. I guess if it was only one driver that would have to deal with > this, that would make sense. Otherwise, I'd be pretty happy to make > the kernel a bit simpler and let userspace choose. > > I guess you already do some under-the-hood remapping of pipes/crtcs in > i915, so maybe this sort of thing is a bit easier for you. I was > really hoping not to have to go there. one extra thing to note: SLAVE_CRTC makes things someone usable for userspace that still uses the legacy setcrtc API.. trying to do it all under the hood seems only reasonable for atomic. What I'm leaning towards is introducing SLAVE_CRTC property, but in the atomic case, let the driver attempt to set that property itself if needed during the atomic->test() step. BR, -R >> Imo the point of atomic modesets with the test mode is that we can expose >> this information at least indirectly to userspace. But trying to come up >> with some explicit scheme for every insane corner case is imo pointless - >> generic userspace won't ever bothering with them, and if you need special >> code you might as well bake in the assumptions in userspace. Kinda like >> current userspace has baked-in assumptions about how a fb backing storage >> object should look like. > > True, although I expect width limits to not be entirely uncommon. I > think I know of at least two or three hw platforms with some sort of > "merge" feature for wide displays. > > ---- > > but, now that we are on the topic of atomic.. seems like there are > two cases for what happens with planes vs ganged crtcs. Either the > plane can be shared across the two half-crtcs or not. So maybe I end > up having to remap planes under the hood already (in which case, I > suppose doing the same for crtcs isn't such a big stretch). > > But it means userspace never really knows how many crtcs or planes are > actually available. Which is why I wanted a way to return per-plane > status from atomic test ;-) > >> So overall I think we need to have the following pieces: >> - Plane limits so that fbcon and userspace which can't do tiling can >> restrict itself appropriately. >> - When userspace asks for a big mode which needs ganging of some stuff the >> kernel driver handles all the resource allocation. If your hw allows it >> it's obviously best if you can freely reassign resources between crtcs, >> otherwise it'll be really hard for userspace to get anything done >> without atomic modesets. >> - Generic userspace slices&dices the logical framebuffer into tiles which >> fit into the planes. >> >> Or do I miss something big here? > > No, not really. I was just trying to get away with pushing some > complexity (for case #1) up to userspace instead of doing it in the > kernel. > > BR, > -R > >>> For the second scenario, I am less sure. We could of course also have >>> some sort of 'SLAVE_CONNECTOR' property (since encoders themselves >>> don't currently have/need properties). But this probably depends on >>> the outcome of the xorg/xrandr userspace discussion. >>> >>> Anyways, I'd of course be interested to hear from others who will have >>> to tackle the same problem in their own drivers, whether the >>> 'SLAVE_CRTC' approach works for them or not, etc. It looks like the >>> first scenario is something I'll get to deal with pretty soon now (ie. >>> approximately as soon as I buy myself a 4k DP monitor ;-)) >> >> Like I've said I think the 2nd scenario isn't a kernel issue (maybe we >> need to expose layout information through read-only properties if it's not >> available in a standard way). For the first scenario I still have the >> impression that I'm missing something. >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
