On Wed, Feb 14, 2018 at 2:08 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Wed, Feb 14, 2018 at 1:17 PM, jsanka <jsanka@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
