From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756112AbcGZJwI (ORCPT ); Tue, 26 Jul 2016 05:52:08 -0400 Received: from regular1.263xmail.com ([211.150.99.135]:41748 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752814AbcGZJwE (ORCPT ); Tue, 26 Jul 2016 05:52:04 -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: <19645601a59cc072d988722a7cd2317a> 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> From: Mark yao Message-ID: <579732B2.80600@rock-chips.com> Date: Tue, 26 Jul 2016 17:51:46 +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: <20160726082635.GA31475@phenom.ffwll.local> 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 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 From: Mark yao Subject: Re: [PATCH 1/3] drm: introduce share plane Date: Tue, 26 Jul 2016 17:51:46 +0800 Message-ID: <579732B2.80600@rock-chips.com> References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160726082635.GA31475@phenom.ffwll.local> 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 T24gMjAxNuW5tDA35pyIMjbml6UgMTY6MjYsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gT24gVHVl LCBKdWwgMjYsIDIwMTYgYXQgMDM6NDY6MzJQTSArMDgwMCwgTWFyayBZYW8gd3JvdGU6Cj4+ID5X aGF0IGlzIHNoYXJlIHBsYW5lOgo+PiA+UGxhbmUgaGFyZHdhcmUgb25seSBiZSB1c2VkIHdoZW4g dGhlIGRpc3BsYXkgc2Nhbm91dCBydW4gaW50byBwbGFuZSBhY3RpdmUKPj4gPnNjYW5vdXQsIHRo YXQgbWVhbnMgd2UgY2FuIHJldXNlIHRoZSBwbGFuZSBoYXJkd2FyZSByZXNvdXJjZXMgb24gcGxh bmUKPj4gPm5vbi1hY3RpdmUgc2Nhbm91dC4KPj4gPgo+PiA+ICAgICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4gPiAgICAgfCAgc2Nhbm91dCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPj4gPiAgICAgfCAgICAgICAg IC0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgIHwKPj4gPiAgICAgfCAgICAg ICAgIHwgcGFyZW50IHBsYW5lICAgfCAgICAgICAgICAgICAgICAgICAgIHwKPj4gPiAgICAgfCAg ICAgICAgIHwgYWN0aXZlIHNjYW5vdXQgfCAgICAgICAgICAgICAgICAgICAgIHwKPj4gPiAgICAg fCAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgIC0tLS0tLS0tLS0tLS0tLS0tIHwKPj4gPiAg ICAgfCAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLSAgIHwgc2hhcmUgcGxhbmUgMSB8IHwKPj4g PiAgICAgfCAgLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgIHxhY3RpdmUgc2Nhbm91dCB8IHwK Pj4gPiAgICAgfCAgfCBzaGFyZSBwbGFuZSAwIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 IHwKPj4gPiAgICAgfCAgfGFjdGl2ZSBzY2Fub3V0IHwgICAgICAgICAgIC0tLS0tLS0tLS0tLS0t LS0tIHwKPj4gPiAgICAgfCAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKPj4gPiAgICAgfCAgLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKPj4gPiAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPj4gPk9uZSBwbGFuZSBoYXJkd2FyZSBjYW4gYmUgcmV1c2UgZm9yIG11 bHRpLXBsYW5lcywgd2UgYXNzdW1lIHRoZSBmaXJzdAo+PiA+cGxhbmUgaXMgcGFyZW50IHBsYW5l LCBvdGhlciBwbGFuZXMgc2hhcmUgdGhlIHJlc291cmNlIHdpdGggZmlyc3Qgb25lLgo+PiA+ICAg ICBwYXJlbnQgcGxhbmUKPj4gPiAgICAgICAgIHwtLS1zaGFyZSBwbGFuZSAwCj4+ID4gICAgICAg ICB8LS0tc2hhcmUgcGxhbmUgMQo+PiA+ICAgICAgICAgLi4uCj4+ID4KPj4gPkJlY2F1c2UgcmVz b3VyY2Ugc2hhcmUsIFRoZXJlIGFyZSBzb21lIGxpbWl0IG9uIHNoYXJlIHBsYW5lOiBvbmUgZ3Jv dXAKPj4gPm9mIHNoYXJlIHBsYW5lcyBuZWVkIHVzZSBzYW1lIHpwb3MsIGNhbiBub3Qgb3Zlcmxh cCwgZXRjLgo+PiA+Cj4+ID5XZSBhc3N1bWUgc2hhcmUgcGxhbmUgaXMgYSB1bml2ZXJzYWwgcGxh bmUgd2l0aCBzb21lIGxpbWl0IGZsYWdzLgo+PiA+cGVvcGxlIHdobyB1c2UgdGhlIHNoYXJlIHBs YW5lIG5lZWQga25vdyB0aGUgbGltaXQsIHNob3VsZCBjYWxsIHRoZSBpb2N0bAo+PiA+RFJNX0NM SUVOVF9DQVBfU0hBUkVfUExBTkVTLCBhbmQganVkZ2UgdGhlIHBsYW5lcyBsaW1pdCBiZWZvcmUg dXNlIGl0Lgo+PiA+Cj4+ID5BIGdyb3VwIG9mIHNoYXJlIHBsYW5lcyB3b3VsZCBoYXMgc2FtZSBz aGFyZCBpZCwgc28gdXNlcnNwYWNlIGNhbgo+PiA+Z3JvdXAgdGhlbSwganVkZ2Ugc2hhcmUgcGxh bmUncyBsaW1pdC4KPj4gPgo+PiA+U2lnbmVkLW9mZi1ieTogTWFyayBZYW88bWFyay55YW9Acm9j ay1jaGlwcy5jb20+Cj4gVGhpcyBzZWVtcyBleHRyZW1lbHkgaHcgc3BlY2lmaWMsIHdoeSBleGFj dGx5IGRvIHdlIG5lZWQgdG8gYWRkIGEgbmV3Cj4gcmVsYXRpb25zaGlwIG9uIHBsYW5lcz8gV2hh dCBkb2VzIHRoaXMgYnV5IG9uX290aGVyXyAgZHJpdmVycz8KWWVzLCBub3cgaXQncyBwbGFuZSBo YXJkd2FyZSBzcGVjaWZpYywgbWF5YmUgb3RoZXJzIGhhdmUgc2FtZSBkZXNpZ24sIApiZWNhdXNl IHRoaXMgZGVzaWduCndvdWxkIHNhdmUgaGFyZHdhcmUgcmVzb3VyY2UgdG8gc3VwcG9ydCBtdWx0 aS1wbGFuZXMuCgo+IEltbyB0aGlzIHNob3VsZCBiZSBzb2x2ZWQgYnkgdmlydHVhbGl6aW5nIHBs YW5lcyBpbiB0aGUgZHJpdmVyLiBTdGFydCBvdXQKPiBieSBhc3NpZ25pbmcgcGxhbmVzLCBhbmQg aWYgeW91IGNhbiByZXVzZSBvbmUgZm9yIHNoYXJpbmcgdGhlbiBkbyB0aGF0LAo+IG90aGVyd2lz ZSBhbGxvY2F0ZSBhIG5ldyBvbmUuIElmIHRoZXJlJ3Mgbm90IGVub3VnaCByZWFsIHBsYW5lcywg ZmFpbCB0aGUKPiBhdG9taWNfY2hlY2suCkkgdGhpbmsgdGhhdCBpcyB0b28gY29tcGxleCwgdHJ5 aW5nIHdpdGggYXRvbWljX2NoZWNrIEkgdGhpbmsgaXQncyBub3QgYSAKZ29vZCBpZGVhLCB1c2Vy c3BhY2UgdHJ5IHBsYW5lcyBldmVyeSBjb21taXQgd291bGQgYmUgYSBoZWF2eSB3b3JrLgoKVXNl cnNwYWNlIG5lZWQgIGtub3cgYWxsIHBsYW5lcyByZWxhdGlvbnNoaXAsIGdyb3VwIHRoZW0sIHNv bWUgZGlzcGxheSAKd2luZG93cyBjYW4gcHV0IHRvZ2V0aGVyLCBzb21lIGNhbid0LAp0b28gbWFu eSBwZXJtdXRhdGlvbiBhbmQgY29tYmluYXRpb24sIEkgdGhpbmsgY2FuJ3QganVzdCBjb21taXQg d2l0aCB0cnkuCgpleGFtcGxlOgp1c2Vyc3BhY2U6CndpbmRvd3MgMTogcG9zKDAsIDApICBzaXpl KDEwMjQsIDEwMCkKd2luZG93cyAyOiBwb3MoMCwgNTApIHNpemUoNDAwLCA1MDApCndpbmRvd3Mg MzogcG9zKDAsIDIwMCkgc2l6ZSg4MDAsIDMwMCkKCmRybSBwbGFuZSByZXNvdXJjZXM6CnBsYW5l IDAgYW5kIHBsYW5lIDEgaXMgYSBncm91cCBvZiBzaGFyZSBwbGFuZXMKcGxhbmUgMiBpcyBjb21t b24gcGxhbmUuCgppZiB1c2Vyc3BhY2Uga25vdyB0aGUgcmVsYXRpb25zaGlwLCB0aGVuIHRoZXkg Y2FuIGFzc2lnbiB3aW5kb3dzIDEgYW5kIAp3aW5kb3cgMyB0byBwbGFuZTAgYW5kIHBsYW5lIDEu IHRoYXQgd291bGQgYmUgc3VjY2Vzcy4KYnV0IGlmIHRoZXkgZG9uJ3Qga25vdywgYXNzaWduIHdp bmRvdyAxLzIgdG8gcGxhbmUgMC8xLCBmYWlsZWQsIGFzc2lnbiAKd2luZG93IDIvMyB0byBwbGFu ZSAwLzEsIGZhaWxlZC4gbW9zdGx5IHdvdWxkIGdldCBmYWlsZWQuCgo+Cj4gVGhpcyBzZWVtcyB3 YXkgdG8gaHcgc3BlY2lmaWMgdG8gYmUgdXNlZnVsIGFzIGEgZ2VuZXJpYyBjb25jZXB0LgoKV2Ug d2FudCB0byBjaGFuZ2UgdGhlIGRybV9tb2RlX2dldHBsYW5lX3JlcyBiZWhhdmlvciwgaWYgdXNl cnNwYWNlIGNhbGwgCkRSTV9DTElFTlRfQ0FQX1NIQVJFX1BMQU5FUywgdGhhdCBtZWFucyB1c2Vy c3BhY2Uga25vdyBoYXJkd2FyZSBsaW1pdCwKdGhlbiB3ZSByZXR1cm4gZnVsbCBwbGFuZXMgc3Vw cG9ydCB0byB1c2Vyc3BhY2UsIGlmIGRvbid0LCBqdXN0IG1ha2UgYSAKZ3JvdXAgb2Ygc2hhcmUg cGxhbmVzIGFzIG9uZSBwbGFuZS4KdGhpcyB3b3JrIGlzIG9uIGdlbmVyaWMgcGxhY2UuCgo+IC1E YW5pZWwKPgo+CgotLSAK77ytYXJrIFlhbwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3Rz LmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Tue, 26 Jul 2016 17:51:46 +0800 Subject: [PATCH 1/3] drm: introduce share plane In-Reply-To: <20160726082635.GA31475@phenom.ffwll.local> References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> Message-ID: <579732B2.80600@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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