backend-drm and scanning really large resolutions

[Xiaowen Wu]

Hi Rob,

If the vendor driver doesn't have the hwpipe sub-object and kms plane is 
one-to-one mapped to hwpipe (sspp),
do you think if below approach is acceptable if we still want to 
virtualize the kms plane to support 4K/8K scanout?

1. At kms atomic check before calling drm_atomic_helper_check, depending 
on scanout width of plane A in state, add idle planes B (C,D,...)
into the same atomic state, backup and then modify 
src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...) 
to meet scanout
width limits, and set crtc/fb of the affected planes B (C,D,...) same as 
plane A.

2. At plane's state duplicate function, check if plane's 
src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the 
change to
plane A's backup value to allow plane A's scanout to update again. These 
value will again be updated in step 1) so nothing really changes
if plane A continues updating.

3. If plane A's scanout is updated or detached from crtc, detach 
affected planes B (C,D,...) in the same atomic state in step 1) and then 
run step 1) again.

4. If user want to commit plane B (C,D,...), the commit/test will fail 
if planes are already used as sister plane of plane A. This failure is 
same
as insufficient hwpipe from plane B (C,D,...).

With above change, any downstream driver can support virtualized plane. 
Also as the above approach is generic and not h/w specific, we can make
it a helper function and it's up to vendor to choose if they want to use 
or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in
their downstream driver.

Conceptional above changes didn't borrow hwpipe resources from other 
plane but borrow planes themselves directly, however from user point of 
view
they should not feel any difference.

What do you think?

BR,
Xiaowen Wu


On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote:
> 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?
>>