[Freedreno] [RFC PULL] Add Display Support for Qualcomm SDM845

[Daniel Stone]

Hi Rob,

On 13 February 2018 at 20:00, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul <seanpaul at chromium.org> wrote:
>> Qualcomm has been working for the past few weeks on forward porting their
>> downstream drm driver from 4.14 to mainline. Please consider this PR as a
>> request for review, rather than an attempt at mainlining the code as it
>> currently stands. The goal is get this driver in shape over the next coming
>> months.
>
> just so others aren't confused, s/sde/dpu/g in the list below (we did
> our DAL->DC rename before sending first RFC :-P)

Heh, and it is quite a bit of code to dig through. I haven't yet got a
chance to fully check it out.

>> - include/uapi/drm/msm_drm_pp.h needs opensource userspace (or removal)

We don't really have a good story for pixel-processing API anywhere tbh.

> To add to that, a few things I've noticed (but I've mostly only gotten
> as far as the front-end of the pipeline, ie. dpu_plane):
>
>  - It looks like, as was the case with mdp4/mdp5 (and really most other hw)
>    there are still unequal capabilities for planes (ie. some can do YUV,
>    scaling, etc).
>
>    But drm-hwc (or weston) isn't going to know about that, so I think we'll
>    need to add support for dynamically assigning dpu_plane::pipe, similar
>    to what mdp5 does w/ plane<->hwpipe.  (Which I actually added specifically
>    for drm-hwc ;-))

Formats/modifiers we do at least get per-plane. We won't know about
scaling, but at least Weston will go through trying each plane in
sequence until it finds one which accepts the configuration. Could HWC
do something like that with atomic, or does it rely on coming up with
a plan first rather than the brute-force testing approach? I haven't
seen its planner at all recently I'm afraid.

>  - I *think* we also need the same trick for combining mixers under one CRTC
>    for 4k modes too?

This one I guess you can't get around though. Can they still run from
the one plane, or do you secretly consume two planes?

>  - in dpu_plane, and perhaps elsewhere, userspace pointers for things like CSC
>    and scaling coefficients need to be annotated w/ __user.  (Except the should
>    probably be blob properties instead.. and we probably need to strip out the
>    custom properties and re-introduce them separately with some userspace +
>    review.)

It'd be good to know if the CSC could use the CRTC GAMMA_LUT -> CTM ->
DEGAMMA_LUT properties, if they were moved over to planes. (And if
not, why not; if there's any functionality missing from those, what it
is, etc.)

Cheers,
Daniel