From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark yao Subject: Re: [PATCH 1/3] drm: introduce share plane Date: Thu, 28 Jul 2016 11:01:04 +0800 Message-ID: <57997570.5070806@rock-chips.com> References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> <579732B2.80600@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <579732B2.80600@rock-chips.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: David Airlie , Heiko Stuebner , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org List-Id: linux-rockchip.vger.kernel.org QW55IGlkZWFzIGZvciB0aGUgc2hhcmUgcGxhbmVzPwoKVGhpcyBmdW5jdGlvbiBpcyBpbXBvcnRh bnQgZm9yIG91ciBzZXJpZXMgb2Ygdm9wIGZ1bGwgZGVzaWduLgogICAgIFRoZSBzZXJpZXMgb2Yg dm9wIGlzOgogICAgIElQIHZlcnNpb24gICAgY2hpcG5hbWUKICAgICAzLjEgICAgICAgICAgIHJr MzI4OAogICAgIDMuMiAgICAgICAgICAgcmszMzY4CiAgICAgMy40ICAgICAgICAgICByazMzNjYK ICAgICAzLjUgICAgICAgICAgIHJrMzM5OSBiaWcKICAgICAzLjYgICAgICAgICAgIHJrMzM5OSBs aXQKICAgICAzLjcgICAgICAgICAgIHJrMzIyeAoKZXhhbXBsZSBvbiByazMyODg6ICBpZiBub3Qg c3VwcG9ydCBzaGFyZSBwbGFuZSwgZWFjaCB2b3Agb25seSBzdXBwb3J0IApmb3VyIHBsYW5lcywg YnV0IGlmIHN1cHBvcnQgdGhpcyBmdW5jdGlvbiwgZWFjaCB2b3AgY2FuIHN1cHBvcnQgdGVuIHBs YW5lcy4KCk9uIDIwMTblubQwN+aciDI25pelIDE3OjUxLCBNYXJrIHlhbyB3cm90ZToKPiBPbiAy MDE25bm0MDfmnIgyNuaXpSAxNjoyNiwgRGFuaWVsIFZldHRlciB3cm90ZToKPj4gT24gVHVlLCBK dWwgMjYsIDIwMTYgYXQgMDM6NDY6MzJQTSArMDgwMCwgTWFyayBZYW8gd3JvdGU6Cj4+PiA+V2hh dCBpcyBzaGFyZSBwbGFuZToKPj4+ID5QbGFuZSBoYXJkd2FyZSBvbmx5IGJlIHVzZWQgd2hlbiB0 aGUgZGlzcGxheSBzY2Fub3V0IHJ1biBpbnRvIHBsYW5lIAo+Pj4gYWN0aXZlCj4+PiA+c2Nhbm91 dCwgdGhhdCBtZWFucyB3ZSBjYW4gcmV1c2UgdGhlIHBsYW5lIGhhcmR3YXJlIHJlc291cmNlcyBv biBwbGFuZQo+Pj4gPm5vbi1hY3RpdmUgc2Nhbm91dC4KPj4+ID4KPj4+ID4gICAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gPiAgICAgfCAg c2Nhbm91dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPj4+ID4gICAg IHwgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAgICB8Cj4+PiA+ ICAgICB8ICAgICAgICAgfCBwYXJlbnQgcGxhbmUgICB8ICAgICAgICAgICAgICAgICAgICAgfAo+ Pj4gPiAgICAgfCAgICAgICAgIHwgYWN0aXZlIHNjYW5vdXQgfCAgICAgICAgICAgICAgICAgICAg IHwKPj4+ID4gICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAtLS0tLS0tLS0tLS0t LS0tLSB8Cj4+PiA+ICAgICB8ICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tICAgfCBzaGFyZSBw bGFuZSAxIHwgfAo+Pj4gPiAgICAgfCAgLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgIHxhY3Rp dmUgc2Nhbm91dCB8IHwKPj4+ID4gICAgIHwgIHwgc2hhcmUgcGxhbmUgMCB8ICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfCB8Cj4+PiA+ICAgICB8ICB8YWN0aXZlIHNjYW5vdXQgfCAgICAgICAg ICAgLS0tLS0tLS0tLS0tLS0tLS0gfAo+Pj4gPiAgICAgfCAgfCAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKPj4+ID4gICAgIHwgIC0tLS0tLS0tLS0tLS0tLS0t ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cj4+PiA+ICAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gPk9uZSBwbGFuZSBoYXJkd2Fy ZSBjYW4gYmUgcmV1c2UgZm9yIG11bHRpLXBsYW5lcywgd2UgYXNzdW1lIHRoZSBmaXJzdAo+Pj4g PnBsYW5lIGlzIHBhcmVudCBwbGFuZSwgb3RoZXIgcGxhbmVzIHNoYXJlIHRoZSByZXNvdXJjZSB3 aXRoIGZpcnN0IG9uZS4KPj4+ID4gICAgIHBhcmVudCBwbGFuZQo+Pj4gPiAgICAgICAgIHwtLS1z aGFyZSBwbGFuZSAwCj4+PiA+ICAgICAgICAgfC0tLXNoYXJlIHBsYW5lIDEKPj4+ID4gICAgICAg ICAuLi4KPj4+ID4KPj4+ID5CZWNhdXNlIHJlc291cmNlIHNoYXJlLCBUaGVyZSBhcmUgc29tZSBs aW1pdCBvbiBzaGFyZSBwbGFuZTogb25lIGdyb3VwCj4+PiA+b2Ygc2hhcmUgcGxhbmVzIG5lZWQg dXNlIHNhbWUgenBvcywgY2FuIG5vdCBvdmVybGFwLCBldGMuCj4+PiA+Cj4+PiA+V2UgYXNzdW1l IHNoYXJlIHBsYW5lIGlzIGEgdW5pdmVyc2FsIHBsYW5lIHdpdGggc29tZSBsaW1pdCBmbGFncy4K Pj4+ID5wZW9wbGUgd2hvIHVzZSB0aGUgc2hhcmUgcGxhbmUgbmVlZCBrbm93IHRoZSBsaW1pdCwg c2hvdWxkIGNhbGwgdGhlIAo+Pj4gaW9jdGwKPj4+ID5EUk1fQ0xJRU5UX0NBUF9TSEFSRV9QTEFO RVMsIGFuZCBqdWRnZSB0aGUgcGxhbmVzIGxpbWl0IGJlZm9yZSB1c2UgaXQuCj4+PiA+Cj4+PiA+ QSBncm91cCBvZiBzaGFyZSBwbGFuZXMgd291bGQgaGFzIHNhbWUgc2hhcmQgaWQsIHNvIHVzZXJz cGFjZSBjYW4KPj4+ID5ncm91cCB0aGVtLCBqdWRnZSBzaGFyZSBwbGFuZSdzIGxpbWl0Lgo+Pj4g Pgo+Pj4gPlNpZ25lZC1vZmYtYnk6IE1hcmsgWWFvPG1hcmsueWFvQHJvY2stY2hpcHMuY29tPgo+ PiBUaGlzIHNlZW1zIGV4dHJlbWVseSBodyBzcGVjaWZpYywgd2h5IGV4YWN0bHkgZG8gd2UgbmVl ZCB0byBhZGQgYSBuZXcKPj4gcmVsYXRpb25zaGlwIG9uIHBsYW5lcz8gV2hhdCBkb2VzIHRoaXMg YnV5IG9uX290aGVyXyAgZHJpdmVycz8KPiBZZXMsIG5vdyBpdCdzIHBsYW5lIGhhcmR3YXJlIHNw ZWNpZmljLCBtYXliZSBvdGhlcnMgaGF2ZSBzYW1lIGRlc2lnbiwgCj4gYmVjYXVzZSB0aGlzIGRl c2lnbgo+IHdvdWxkIHNhdmUgaGFyZHdhcmUgcmVzb3VyY2UgdG8gc3VwcG9ydCBtdWx0aS1wbGFu ZXMuCj4KPj4gSW1vIHRoaXMgc2hvdWxkIGJlIHNvbHZlZCBieSB2aXJ0dWFsaXppbmcgcGxhbmVz IGluIHRoZSBkcml2ZXIuIFN0YXJ0IAo+PiBvdXQKPj4gYnkgYXNzaWduaW5nIHBsYW5lcywgYW5k IGlmIHlvdSBjYW4gcmV1c2Ugb25lIGZvciBzaGFyaW5nIHRoZW4gZG8gdGhhdCwKPj4gb3RoZXJ3 aXNlIGFsbG9jYXRlIGEgbmV3IG9uZS4gSWYgdGhlcmUncyBub3QgZW5vdWdoIHJlYWwgcGxhbmVz LCBmYWlsIAo+PiB0aGUKPj4gYXRvbWljX2NoZWNrLgo+IEkgdGhpbmsgdGhhdCBpcyB0b28gY29t cGxleCwgdHJ5aW5nIHdpdGggYXRvbWljX2NoZWNrIEkgdGhpbmsgaXQncyBub3QgCj4gYSBnb29k IGlkZWEsIHVzZXJzcGFjZSB0cnkgcGxhbmVzIGV2ZXJ5IGNvbW1pdCB3b3VsZCBiZSBhIGhlYXZ5 IHdvcmsuCj4KPiBVc2Vyc3BhY2UgbmVlZCAga25vdyBhbGwgcGxhbmVzIHJlbGF0aW9uc2hpcCwg Z3JvdXAgdGhlbSwgc29tZSBkaXNwbGF5IAo+IHdpbmRvd3MgY2FuIHB1dCB0b2dldGhlciwgc29t ZSBjYW4ndCwKPiB0b28gbWFueSBwZXJtdXRhdGlvbiBhbmQgY29tYmluYXRpb24sIEkgdGhpbmsg Y2FuJ3QganVzdCBjb21taXQgd2l0aCB0cnkuCj4KPiBleGFtcGxlOgo+IHVzZXJzcGFjZToKPiB3 aW5kb3dzIDE6IHBvcygwLCAwKSAgc2l6ZSgxMDI0LCAxMDApCj4gd2luZG93cyAyOiBwb3MoMCwg NTApIHNpemUoNDAwLCA1MDApCj4gd2luZG93cyAzOiBwb3MoMCwgMjAwKSBzaXplKDgwMCwgMzAw KQo+Cj4gZHJtIHBsYW5lIHJlc291cmNlczoKPiBwbGFuZSAwIGFuZCBwbGFuZSAxIGlzIGEgZ3Jv dXAgb2Ygc2hhcmUgcGxhbmVzCj4gcGxhbmUgMiBpcyBjb21tb24gcGxhbmUuCj4KPiBpZiB1c2Vy c3BhY2Uga25vdyB0aGUgcmVsYXRpb25zaGlwLCB0aGVuIHRoZXkgY2FuIGFzc2lnbiB3aW5kb3dz IDEgYW5kIAo+IHdpbmRvdyAzIHRvIHBsYW5lMCBhbmQgcGxhbmUgMS4gdGhhdCB3b3VsZCBiZSBz dWNjZXNzLgo+IGJ1dCBpZiB0aGV5IGRvbid0IGtub3csIGFzc2lnbiB3aW5kb3cgMS8yIHRvIHBs YW5lIDAvMSwgZmFpbGVkLCBhc3NpZ24gCj4gd2luZG93IDIvMyB0byBwbGFuZSAwLzEsIGZhaWxl ZC4gbW9zdGx5IHdvdWxkIGdldCBmYWlsZWQuCj4KPj4KPj4gVGhpcyBzZWVtcyB3YXkgdG8gaHcg c3BlY2lmaWMgdG8gYmUgdXNlZnVsIGFzIGEgZ2VuZXJpYyBjb25jZXB0Lgo+Cj4gV2Ugd2FudCB0 byBjaGFuZ2UgdGhlIGRybV9tb2RlX2dldHBsYW5lX3JlcyBiZWhhdmlvciwgaWYgdXNlcnNwYWNl IAo+IGNhbGwgRFJNX0NMSUVOVF9DQVBfU0hBUkVfUExBTkVTLCB0aGF0IG1lYW5zIHVzZXJzcGFj ZSBrbm93IGhhcmR3YXJlIAo+IGxpbWl0LAo+IHRoZW4gd2UgcmV0dXJuIGZ1bGwgcGxhbmVzIHN1 cHBvcnQgdG8gdXNlcnNwYWNlLCBpZiBkb24ndCwganVzdCBtYWtlIGEgCj4gZ3JvdXAgb2Ygc2hh cmUgcGxhbmVzIGFzIG9uZSBwbGFuZS4KPiB0aGlzIHdvcmsgaXMgb24gZ2VuZXJpYyBwbGFjZS4K Pgo+PiAtRGFuaWVsCj4+Cj4+Cj4KCgotLSAK77ytYXJrIFlhbwoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Thu, 28 Jul 2016 11:01:04 +0800 Subject: [PATCH 1/3] drm: introduce share plane In-Reply-To: <579732B2.80600@rock-chips.com> References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> <579732B2.80600@rock-chips.com> Message-ID: <57997570.5070806@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163742AbcG1DCH (ORCPT ); Wed, 27 Jul 2016 23:02:07 -0400 Received: from regular1.263xmail.com ([211.150.99.131]:39752 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1163226AbcG1DBV (ORCPT ); Wed, 27 Jul 2016 23:01:21 -0400 X-263anti-spam: KSV:0;BIG:0;ABS:1;DNS:0;ATT:0;SPF:S; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 1 X-SKE-CHECKED: 1 X-ADDR-CHECKED: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: linux-kernel@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <940e969f3d8c070a69791dbce31e314b> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 1/3] drm: introduce share plane To: David Airlie , Heiko Stuebner , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> <579732B2.80600@rock-chips.com> From: Mark yao Message-ID: <57997570.5070806@rock-chips.com> Date: Thu, 28 Jul 2016 11:01:04 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <579732B2.80600@rock-chips.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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