backend-drm and scanning really large resolutions

[Rob Clark]

On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at gmail.com> wrote:
>
> Hi all,
>
> I'm confronting a situation where the hardware with which I work is capable of driving connectors at 4K or 8K, but doing so requires bonding the scanning of multiple planes together.
>
> The scenario is that you'd have a big primary framebuffer whose size is too large for an individual hardware scanning pipeline on the display controller to traverse within its maximum allowed clock rate.
>
> The hardware supplier's approach is to assign multiple planes, which in the KMS driver map to hardware scanning pipelines, to each be responsible for scanning a smaller section of the framebuffer. The planes are all assigned to the same CRTC, and in concert with each other they cover the whole area of the framebuffer and CRTC.
>
> This sounds a little bit wild to me. I hadn't been aware it's even legal to have more than one plane treated a the source of scanout for a single framebuffer. Maybe that distinction isn't really relevant nowadays with universal plane support.
>

fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate
one or two hwpipe's from the devices global atomic state, depending on
scanout width.. the hwpipe (sspp) is the physical resource behind a
plane, so essentially the kms planes are virtualized.  At some point
if you have too many wide layers, the atomic test step will fail due
to insufficient hwpipe's.  But this sort of scenario is the reason for
the test step.

BR,
-R

> I'm wondering if anybody here knows whether this a legit approach for a compositor's DRM backend to take?
>