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@xxxxxxxxxxxxx> wrote: > > Hi Rob, > > > > On 13 February 2018 at 20:00, Rob Clark <robdclark@xxxxxxxxx> wrote: > >> On Tue, Feb 13, 2018 at 2:18 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
