Any ideas for the share planes?
This function is important for our series of vop full design. The series of vop is: IP version chipname 3.1 rk3288 3.2 rk3368 3.4 rk3366 3.5 rk3399 big 3.6 rk3399 lit 3.7 rk322x
example on rk3288: if not support share plane, each vop only support four planes, but if support this function, each vop can support ten planes.
On 2016年07月26日 17:51, Mark yao wrote:
On 2016年07月26日 16:26, Daniel Vetter wrote:
On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
What is share plane: Plane hardware only be used when the display scanout run into plane
active
scanout, that means we can reuse the plane hardware resources on plane non-active scanout.
-------------------------------------------------- | scanout | | ------------------ | | | parent plane | | | | active scanout | | | | | ----------------- | | ------------------ | share plane 1 | | | ----------------- |active scanout | | | | share plane 0 | | | | | |active scanout | ----------------- | | | | | | ----------------- | --------------------------------------------------One plane hardware can be reuse for multi-planes, we assume the first plane is parent plane, other planes share the resource with first one. parent plane |---share plane 0 |---share plane 1 ...
Because resource share, There are some limit on share plane: one group of share planes need use same zpos, can not overlap, etc.
We assume share plane is a universal plane with some limit flags. people who use the share plane need know the limit, should call the
ioctl
DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
A group of share planes would has same shard id, so userspace can group them, judge share plane's limit.
Signed-off-by: Mark Yaomark.yao@rock-chips.com
This seems extremely hw specific, why exactly do we need to add a new relationship on planes? What does this buy on_other_ drivers?
Yes, now it's plane hardware specific, maybe others have same design, because this design would save hardware resource to support multi-planes.
Imo this should be solved by virtualizing planes in the driver. Start out by assigning planes, and if you can reuse one for sharing then do that, otherwise allocate a new one. If there's not enough real planes, fail the atomic_check.
I think that is too complex, trying with atomic_check I think it's not a good idea, userspace try planes every commit would be a heavy work.
Userspace need know all planes relationship, group them, some display windows can put together, some can't, too many permutation and combination, I think can't just commit with try.
example: userspace: windows 1: pos(0, 0) size(1024, 100) windows 2: pos(0, 50) size(400, 500) windows 3: pos(0, 200) size(800, 300)
drm plane resources: plane 0 and plane 1 is a group of share planes plane 2 is common plane.
if userspace know the relationship, then they can assign windows 1 and window 3 to plane0 and plane 1. that would be success. but if they don't know, assign window 1/2 to plane 0/1, failed, assign window 2/3 to plane 0/1, failed. mostly would get failed.
This seems way to hw specific to be useful as a generic concept.
We want to change the drm_mode_getplane_res behavior, if userspace call DRM_CLIENT_CAP_SHARE_PLANES, that means userspace know hardware limit, then we return full planes support to userspace, if don't, just make a group of share planes as one plane. this work is on generic place.
-Daniel