crtc ganging in KMS, "large" displays, etc

[Rob Clark]

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.

-------------------

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.

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

BR,
-R

[1] assuming it is acceptable for initial modeset for fbcon picking a
lower resolution which can be supported without a slave encoder.
Most/all phones/tablets disable fbcon, so this doesn't seem like it
should be a problem..
[2] if anyone envisions scenarios where we need to gang more than 2
crtcs, we could invert the property, and have 'PRIMARY_CRTC' property
that gets set on each of the slaves.