[RFC PULL] Add Display Support for Qualcomm SDM845

[Sean Paul]

On Wed, Feb 14, 2018 at 07:22:53AM -0500, Rob Clark wrote:
> On Wed, Feb 14, 2018 at 3:30 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> > 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.

It could definitely build up a plan a la weston, it just doesn't atm.


> >
> >>  - 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?
> >
> 
> I think it is still the case, like mdp5, that you need two hw pipes..
> but actually it gets more crazy, since there are some cases where two
> planes could share a hw pipe.  

Right. Large fbs might require 2 pipes, and multiple overlapping or adjacent small fbs
can be serviced with 1 pipe.

> Not sure that weston or drm-hwc is
> going to have much hope in being able to deal with that, so I think
> virtualizing the planes and crtcs is the better route.

Agreed. I think kernel is in the best place to make these decisions.

Sean

> 
> BR,
> -R
> 
> >>  - 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

-- 
Sean Paul, Software Engineer, Google / Chromium OS