[PATCH 1/3] drm: introduce share plane
On 2016å¹´07æ28æ¥ 16:03, Daniel Vetter wrote: > On Thu, Jul 28, 2016 at 11:01:04AM +0800, Mark yao wrote: >> Any ideas for the share planes? >> >> This function is important for our series of vop full design. >> The series of vop is: >> IP versionchipname >> 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. > Like I said, register 10 planes in the kernel driver, figure out a good > way to actually allocate them to hw resources. We have a similar issue on > skl/bxt in the i915 driver where there's only a limited amount of > scalers, and we need to dynamically allocate them to drm_plane. Here you > have fancy amount of scanout engines which you need to dynamically > allocate. > >> 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 Yao 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. > You can still do this with the design I describe. The only difference is > that you allow generic userspace to make optimal use of your planes, too. > 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
[PATCH 1/3] drm: introduce share plane
Any ideas for the share planes? This function is important for our series of vop full design. The series of vop is: IP versionchipname 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 Yao >> 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 >> >> > -- ï¼ark Yao
[PATCH 1/3] drm: introduce share plane
On Thu, Jul 28, 2016 at 11:01:04AM +0800, Mark yao wrote: > Any ideas for the share planes? > > This function is important for our series of vop full design. > The series of vop is: > IP versionchipname > 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. Like I said, register 10 planes in the kernel driver, figure out a good way to actually allocate them to hw resources. We have a similar issue on skl/bxt in the i915 driver where there's only a limited amount of scalers, and we need to dynamically allocate them to drm_plane. Here you have fancy amount of scanout engines which you need to dynamically allocate. > 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 Yao > > > 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. You can still do this with the design I describe. The only difference is that you allow generic userspace to make optimal use of your planes, too. > > > 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
[PATCH 1/3] drm: introduce share plane
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 Yao > 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 > > -- ï¼ark Yao
[PATCH 1/3] drm: introduce share plane
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 Yao
---
drivers/gpu/drm/drm_crtc.c | 110
drivers/gpu/drm/drm_ioctl.c | 5 ++
include/drm/drmP.h | 5 ++
include/drm/drm_crtc.h | 14 ++
include/uapi/drm/drm.h | 7 +++
5 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9d3f80e..3a8257e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1426,6 +1426,96 @@ int drm_plane_init(struct drm_device *dev, struct
drm_plane *plane,
EXPORT_SYMBOL(drm_plane_init);
/**
+ * drm_share_plane_init - Initialize a share plane
+ * @dev: DRM device
+ * @plane: plane object to init
+ * @parent: this plane share some resources with parent plane.
+ * @possible_crtcs: bitmask of possible CRTCs
+ * @funcs: callbacks for the new plane
+ * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @format_count: number of elements in @formats
+ * @type: type of plane (overlay, primary, cursor)
+ *
+ * With this API, the plane can share hardware resources with other planes.
+ *
+ * --
+ * | scanout |
+ * | -- |
+ * | | parent plane | |
+ * | | active scanout | |
+ * | || - |
+ * | -- | share plane 1 | |
+ * | - |active scanout | |
+ * | | share plane 0 | | | |
+ * | |active scanout | - |
+ * | | | |
+ * | - |
+ * --
+ *
+ *parent plane
+ *|---share plane 0
+ *|---share plane 1
+ *...
+ *
+ * The plane hardware is used when the display scanout run into plane active
+ * scanout, that means we can reuse the plane hardware resources on plane
+ * non-active scanout.
+ *
+ * Because resource share, There are some limit on share plane: one group
+ * of share planes need use same zpos, can't not overlap, etc.
+ *
+ * Here 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.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+
+int drm_share_plane_init(struct drm_device *dev, struct drm_plane *plane,
+struct drm_plane *parent,
+unsigned long possible_crtcs,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int format_count,
+enum drm_plane_type type)
+{
+ struct drm_mode_config *config = >mode_config;
+ int ret;
+ int share_id;
+
+ /*
+* TODO: only verified on ATOMIC drm driver.
+*/
+ if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+ return -EINVAL;
+
+ ret = drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
+ formats, format_count, type, NULL);
+ if (ret)
+ return ret;
+
+ if (parent) {
+
[PATCH 1/3] drm: introduce share plane
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 Yao This seems extremely hw specific, why exactly do we need to add a new relationship on planes? What does this buy on _other_ drivers? 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. This seems way to hw specific to be useful as a generic concept. -Daniel > --- > drivers/gpu/drm/drm_crtc.c | 110 > > drivers/gpu/drm/drm_ioctl.c | 5 ++ > include/drm/drmP.h | 5 ++ > include/drm/drm_crtc.h | 14 ++ > include/uapi/drm/drm.h | 7 +++ > 5 files changed, 141 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 9d3f80e..3a8257e 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -1426,6 +1426,96 @@ int drm_plane_init(struct drm_device *dev, struct > drm_plane *plane, > EXPORT_SYMBOL(drm_plane_init); > > /** > + * drm_share_plane_init - Initialize a share plane > + * @dev: DRM device > + * @plane: plane object to init > + * @parent: this plane share some resources with parent plane. > + * @possible_crtcs: bitmask of possible CRTCs > + * @funcs: callbacks for the new plane > + * @formats: array of supported formats (%DRM_FORMAT_*) > + * @format_count: number of elements in @formats > + * @type: type of plane (overlay, primary, cursor) > + * > + * With this API, the plane can share hardware resources with other planes. > + * > + * -- > + * | scanout | > + * | -- | > + * | | parent plane | | > + * | | active scanout | | > + * | || - | > + * | -- | share plane 1 | | > + * | - |active scanout | | > + * | | share plane 0 | | | | > + * | |active scanout | - | > + * | | | | > + * | - | > + * -- > + * > + *parent plane > + *|---share plane 0 > + *|---share plane 1 > + *... > + * > + * The plane hardware is used when the display scanout run into plane active > + * scanout, that means we can reuse the plane hardware resources on plane > + * non-active scanout. > + * > + * Because resource share, There are some limit on share plane: one group > + * of share planes need use same zpos, can't not overlap, etc. > + * > + * Here 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. > + * > + * Returns: > + * Zero on success, error code on failure. > + */ > + > +int drm_share_plane_init(struct drm_device *dev, struct drm_plane *plane, > + struct drm_plane *parent, > + unsigned
