[RFC PULL] Add Display Support for Qualcomm SDM845

[Rob Clark]

On Wed, Feb 14, 2018 at 2:08 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Feb 14, 2018 at 1:17 PM, jsanka <jsanka at codeaurora.org> wrote:
>> On 2/13/2018 12:00 PM, Rob Clark wrote:
>>>
>>>   - 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 ;-))
>>
>> We are working on plane virtualization focused primarily to support 4K /
>> wider displays which cannot
>> be catered by one hwpipe. The plan is to gang up two *fixed* hwpipes of
>> similar capabilities (in terms of formats,
>> sub hw blocks like scalar, post processing ) and expose them as a single
>> plane so that user space
>> compositor ( drm-hwc or weston) need not worry about max pixel width
>> supported by the planes. But mapping
>> planes <-> hwpipe dynamically may need more than just virtualization. Kernel
>> need to keep track of hwpipes
>> especially when dealing with multiple displays. And it get complicated when
>> planes start moving around CRTC's
>> for different sized buffers.
>
> Hmm, a fixed mapping of hw pipe to plane might be an ok stepping
> stone.  I'm not sure it is a terribly good final solution, esp. when
> it comes to external displays, since you may never need 4k+ scanout,
> depending on what the user plugs in, so you end up wasting a lot of hw
> pipes.
>
> Keeping track of the hwpipes as part of the driver global atomic state
> isn't actually *that* hard.  Have a look at what mdp5 does.  We still
> need to move mdp5 to drm_private_obj instead of subclassing
> drm_atomic_state (see Archit's RFC, "drm/msm/mdp5: Add global state as
> a private atomic object"), but other than that detail, I think
> something along those lines is a better approach.
>

One additional point that I thought about, while implementing
writeback on mdp5.. I think with a cmd-mode panel (and dp psr?) we
could re-use idle hwpipes (ie. while not pushing an update out to the
panel) with a different crtc (LM) and writeback connector to flatten
all the layers to a single buffer while the screen is static, without
having to remove the drm planes from the crtc.  I think that would be
a lot less confusing than figuring out somehow that removing a plane
from a crtc shouldn't be flushed out to the panel.

BR,
-R