crtc ganging in KMS, "large" displays, etc

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.

Re: crtc ganging in KMS, "large" displays, etc

[Daniel Vetter]

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.

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

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.

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.

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?

> 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

Re: crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter <daniel@ffwll.ch> 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.

> 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

Re: crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 8:40 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter <daniel@ffwll.ch> 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

Re: crtc ganging in KMS, "large" displays, etc

[Daniel Vetter]

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter <daniel@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 ;-)

BR,
-R


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: crtc ganging in KMS, "large" displays, etc

[Ville Syrjälä]

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

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

Re: crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä
<ville.syrjala@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@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

Re: crtc ganging in KMS, "large" displays, etc

[Ville Syrjälä]

On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote:
> On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä
> <ville.syrjala@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@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.

What does primary/slave mean here? That seems like a rather hardware
specific notion.

> The SLAVE_CRTC property essentially gives you that 2nd pointer you need.

Would seem easier to add the pointer. Or even better: just expose the
display as two connectors and then you don't have to change anything.
It's just like having multiple displays positioned next to each other
today.

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

Someone might argue that 4k support is a compelling reason ;)

-- 
Ville Syrjälä
Intel OTC

Re: crtc ganging in KMS, "large" displays, etc

[Rob Clark]

On Tue, Apr 1, 2014 at 10:42 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote:
>> On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä
>> <ville.syrjala@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@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.
>
> What does primary/slave mean here? That seems like a rather hardware
> specific notion.

it could be.. you might need to configure the mixers differently (like
setting a MERGE bit/bitfield in one of them).

But it seems easier for a driver to ignore that differentiation if it
doesn't have to care about it, than the other way around

>> The SLAVE_CRTC property essentially gives you that 2nd pointer you need.
>
> Would seem easier to add the pointer. Or even better: just expose the
> display as two connectors and then you don't have to change anything.
> It's just like having multiple displays positioned next to each other
> today.

this is specifically for the case where you have two crtcs, one
encoder.  I don't want to make the driver jump through hoops with a
dummy encoder/connector for this..

>> 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.
>
> Someone might argue that 4k support is a compelling reason ;)

well, yeah, we could put an semi-artificial restriction like that to
force people to move to the new ioctl.  But I'd rather not.

BR,
-R

> --
> Ville Syrjälä
> Intel OTC