crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
> On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote:
>> On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
>> >> 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.
>> >
>> > To clarify: I don't think it makes sense to fully abstract this away in
>> > the kernel, especially if userspace needs to be aware of the boundary
>> > between the crtcs so that it can correctly tile up the logical frambuffer.
>> > But I'm not sure whether trying to make that possible with a generic
>> > userspace driver is sensible, or whether having a bit of magic glue code
>> > in the ddx/wayland/hwc part for e.g. msm is the better option, at least in
>> > the short term.
>> >
>> > Since if the set of useable planes actually changes we need to push that
>> > decision up the stack even further like wayland/hwc currently allow, and
>> > maybe there's some things we need to fix at that layer first. Once we've
>> > learned that lesson we can push things down again and add a neat little
>> > generic kernel interface. At least thus far we've always done a bit of
>> > prototyping with driver-specific code to learn a few lessons, e.g. the
>> > various pieces of non-standard plane/overlay in i915.
>>
>> right, things like 'STATUS' property for returning per-object status
>> would start as driver custom.  (And even 'SLAVE_CRTC'..)  Userspace
>> could look for certain property names in the same way that it looks
>> for certain gl extension strings.  But should be semi-standardized, so
>> other drivers which need the same thing should use same property
>> names/values/behaviors as much as possible.. which was the point for
>> starting the thread ;-)
>
> What's the problem with just using two crtcs? With the atomic API you
> just shovel the state for both down into the driver in one ioctl. This
> is pretty much what we'll need to do to drive those 4k MST DP displays
> as well. The driver will then have to do its best to genlock the crtcs
> if the hardware doesn't do it fully. IIRC that's how we're going to have
> to do the MST stuff, ie. use the same clock source for both obviously,
> and try to start all the pipes as fast as possible so that the vblanks
> line up. And that's going to require more changes to our modesetting
> codepaths.

well, two problems:
1) it won't actually work (at least not without some overhaul of kms
core and helpers)..  encoder only has a single crtc ptr.  And anyway,
it is useful for the driver to differentiate between which pipe/mixer
is primary and which is slave.  The SLAVE_CRTC property essentially
gives you that 2nd pointer you need.
2) still would be nice to be able to drive 4k displays from x11.. and
for the most part there isn't much compelling reason for most ddx's to
migrate to atomic ioctl.

BR,
-R

> So, I don't see a need for any SLAVE_CRTC properties or dynamic remapping
> of resources. The latter would get nasty when the resources (eg. planes)
> aren't uniform anyway. Just let userspace figure it out.
>
> --
> Ville Syrjälä
> Intel OTC