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 17:28:24 +0800 Message-ID: <5799D038.5000906@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> <57997570.5070806@rock-chips.com> <20160728080302.GG31475@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: <20160728080302.GG31475@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 T24gMjAxNuW5tDA35pyIMjjml6UgMTY6MDMsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gT24gVGh1 LCBKdWwgMjgsIDIwMTYgYXQgMTE6MDE6MDRBTSArMDgwMCwgTWFyayB5YW8gd3JvdGU6Cj4+IEFu eSBpZGVhcyBmb3IgdGhlIHNoYXJlIHBsYW5lcz8KPj4KPj4gVGhpcyBmdW5jdGlvbiBpcyBpbXBv cnRhbnQgZm9yIG91ciBzZXJpZXMgb2Ygdm9wIGZ1bGwgZGVzaWduLgo+PiAgICAgIFRoZSBzZXJp ZXMgb2Ygdm9wIGlzOgo+PiAgICAgIElQIHZlcnNpb24gICAgY2hpcG5hbWUKPj4gICAgICAzLjEg ICAgICAgICAgIHJrMzI4OAo+PiAgICAgIDMuMiAgICAgICAgICAgcmszMzY4Cj4+ICAgICAgMy40 ICAgICAgICAgICByazMzNjYKPj4gICAgICAzLjUgICAgICAgICAgIHJrMzM5OSBiaWcKPj4gICAg ICAzLjYgICAgICAgICAgIHJrMzM5OSBsaXQKPj4gICAgICAzLjcgICAgICAgICAgIHJrMzIyeAo+ Pgo+PiBleGFtcGxlIG9uIHJrMzI4ODogIGlmIG5vdCBzdXBwb3J0IHNoYXJlIHBsYW5lLCBlYWNo IHZvcCBvbmx5IHN1cHBvcnQgZm91cgo+PiBwbGFuZXMsIGJ1dCBpZiBzdXBwb3J0IHRoaXMgZnVu Y3Rpb24sIGVhY2ggdm9wIGNhbiBzdXBwb3J0IHRlbiBwbGFuZXMuCj4gTGlrZSBJIHNhaWQsIHJl Z2lzdGVyIDEwIHBsYW5lcyBpbiB0aGUga2VybmVsIGRyaXZlciwgZmlndXJlIG91dCBhIGdvb2QK PiB3YXkgdG8gYWN0dWFsbHkgYWxsb2NhdGUgdGhlbSB0byBodyByZXNvdXJjZXMuIFdlIGhhdmUg YSBzaW1pbGFyIGlzc3VlIG9uCj4gc2tsL2J4dCBpbiB0aGUgaTkxNSBkcml2ZXIgd2hlcmUgdGhl cmUncyBvbmx5IGEgbGltaXRlZCBhbW91bnQgb2YKPiBzY2FsZXJzLCBhbmQgd2UgbmVlZCB0byBk eW5hbWljYWxseSBhbGxvY2F0ZSB0aGVtIHRvIGRybV9wbGFuZS4gSGVyZSB5b3UKPiBoYXZlIGZh bmN5IGFtb3VudCBvZiBzY2Fub3V0IGVuZ2luZXMgd2hpY2ggeW91IG5lZWQgdG8gZHluYW1pY2Fs bHkKPiBhbGxvY2F0ZS4KPgo+PiBPbiAyMDE25bm0MDfmnIgyNuaXpSAxNzo1MSwgTWFyayB5YW8g d3JvdGU6Cj4+PiBPbiAyMDE25bm0MDfmnIgyNuaXpSAxNjoyNiwgRGFuaWVsIFZldHRlciB3cm90 ZToKPj4+PiBPbiBUdWUsIEp1bCAyNiwgMjAxNiBhdCAwMzo0NjozMlBNICswODAwLCBNYXJrIFlh byB3cm90ZToKPj4+Pj4+IFdoYXQgaXMgc2hhcmUgcGxhbmU6Cj4+Pj4+PiBQbGFuZSBoYXJkd2Fy ZSBvbmx5IGJlIHVzZWQgd2hlbiB0aGUgZGlzcGxheSBzY2Fub3V0IHJ1biBpbnRvCj4+Pj4+IHBs YW5lIGFjdGl2ZQo+Pj4+Pj4gc2Nhbm91dCwgdGhhdCBtZWFucyB3ZSBjYW4gcmV1c2UgdGhlIHBs YW5lIGhhcmR3YXJlIHJlc291cmNlcyBvbiBwbGFuZQo+Pj4+Pj4gbm9uLWFjdGl2ZSBzY2Fub3V0 Lgo+Pj4+Pj4KPj4+Pj4+ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4+Pj4+PiAgICAgIHwgIHNjYW5vdXQgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIHwgICAgICAgICAtLS0tLS0tLS0tLS0t LS0tLS0gICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIHwgICAgICAgICB8IHBhcmVu dCBwbGFuZSAgIHwgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIHwgICAgICAgICB8 IGFjdGl2ZSBzY2Fub3V0IHwgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIHwgICAg ICAgICB8ICAgICAgICAgICAgICAgIHwgICAtLS0tLS0tLS0tLS0tLS0tLSB8Cj4+Pj4+PiAgICAg IHwgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0gICB8IHNoYXJlIHBsYW5lIDEgfCB8Cj4+Pj4+ PiAgICAgIHwgIC0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICB8YWN0aXZlIHNjYW5vdXQgfCB8 Cj4+Pj4+PiAgICAgIHwgIHwgc2hhcmUgcGxhbmUgMCB8ICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCB8Cj4+Pj4+PiAgICAgIHwgIHxhY3RpdmUgc2Nhbm91dCB8ICAgICAgICAgICAtLS0tLS0t LS0tLS0tLS0tLSB8Cj4+Pj4+PiAgICAgIHwgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIHwgIC0tLS0tLS0tLS0tLS0tLS0tICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8Cj4+Pj4+PiAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+Pj4+PiBPbmUgcGxhbmUgaGFyZHdhcmUg Y2FuIGJlIHJldXNlIGZvciBtdWx0aS1wbGFuZXMsIHdlIGFzc3VtZSB0aGUgZmlyc3QKPj4+Pj4+ IHBsYW5lIGlzIHBhcmVudCBwbGFuZSwgb3RoZXIgcGxhbmVzIHNoYXJlIHRoZSByZXNvdXJjZSB3 aXRoIGZpcnN0IG9uZS4KPj4+Pj4+ICAgICAgcGFyZW50IHBsYW5lCj4+Pj4+PiAgICAgICAgICB8 LS0tc2hhcmUgcGxhbmUgMAo+Pj4+Pj4gICAgICAgICAgfC0tLXNoYXJlIHBsYW5lIDEKPj4+Pj4+ ICAgICAgICAgIC4uLgo+Pj4+Pj4KPj4+Pj4+IEJlY2F1c2UgcmVzb3VyY2Ugc2hhcmUsIFRoZXJl IGFyZSBzb21lIGxpbWl0IG9uIHNoYXJlIHBsYW5lOiBvbmUgZ3JvdXAKPj4+Pj4+IG9mIHNoYXJl IHBsYW5lcyBuZWVkIHVzZSBzYW1lIHpwb3MsIGNhbiBub3Qgb3ZlcmxhcCwgZXRjLgo+Pj4+Pj4K Pj4+Pj4+IFdlIGFzc3VtZSBzaGFyZSBwbGFuZSBpcyBhIHVuaXZlcnNhbCBwbGFuZSB3aXRoIHNv bWUgbGltaXQgZmxhZ3MuCj4+Pj4+PiBwZW9wbGUgd2hvIHVzZSB0aGUgc2hhcmUgcGxhbmUgbmVl ZCBrbm93IHRoZSBsaW1pdCwgc2hvdWxkIGNhbGwKPj4+Pj4gdGhlIGlvY3RsCj4+Pj4+PiBEUk1f Q0xJRU5UX0NBUF9TSEFSRV9QTEFORVMsIGFuZCBqdWRnZSB0aGUgcGxhbmVzIGxpbWl0IGJlZm9y ZSB1c2UgaXQuCj4+Pj4+Pgo+Pj4+Pj4gQSBncm91cCBvZiBzaGFyZSBwbGFuZXMgd291bGQgaGFz IHNhbWUgc2hhcmQgaWQsIHNvIHVzZXJzcGFjZSBjYW4KPj4+Pj4+IGdyb3VwIHRoZW0sIGp1ZGdl IHNoYXJlIHBsYW5lJ3MgbGltaXQuCj4+Pj4+Pgo+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogTWFyayBZ YW88bWFyay55YW9Acm9jay1jaGlwcy5jb20+Cj4+Pj4gVGhpcyBzZWVtcyBleHRyZW1lbHkgaHcg c3BlY2lmaWMsIHdoeSBleGFjdGx5IGRvIHdlIG5lZWQgdG8gYWRkIGEgbmV3Cj4+Pj4gcmVsYXRp b25zaGlwIG9uIHBsYW5lcz8gV2hhdCBkb2VzIHRoaXMgYnV5IG9uX290aGVyXyAgZHJpdmVycz8K Pj4+IFllcywgbm93IGl0J3MgcGxhbmUgaGFyZHdhcmUgc3BlY2lmaWMsIG1heWJlIG90aGVycyBo YXZlIHNhbWUgZGVzaWduLAo+Pj4gYmVjYXVzZSB0aGlzIGRlc2lnbgo+Pj4gd291bGQgc2F2ZSBo YXJkd2FyZSByZXNvdXJjZSB0byBzdXBwb3J0IG11bHRpLXBsYW5lcy4KPj4+Cj4+Pj4gSW1vIHRo aXMgc2hvdWxkIGJlIHNvbHZlZCBieSB2aXJ0dWFsaXppbmcgcGxhbmVzIGluIHRoZSBkcml2ZXIu Cj4+Pj4gU3RhcnQgb3V0Cj4+Pj4gYnkgYXNzaWduaW5nIHBsYW5lcywgYW5kIGlmIHlvdSBjYW4g cmV1c2Ugb25lIGZvciBzaGFyaW5nIHRoZW4gZG8gdGhhdCwKPj4+PiBvdGhlcndpc2UgYWxsb2Nh dGUgYSBuZXcgb25lLiBJZiB0aGVyZSdzIG5vdCBlbm91Z2ggcmVhbCBwbGFuZXMsCj4+Pj4gZmFp bCB0aGUKPj4+PiBhdG9taWNfY2hlY2suCj4+PiBJIHRoaW5rIHRoYXQgaXMgdG9vIGNvbXBsZXgs IHRyeWluZyB3aXRoIGF0b21pY19jaGVjayBJIHRoaW5rIGl0J3Mgbm90IGEKPj4+IGdvb2QgaWRl YSwgdXNlcnNwYWNlIHRyeSBwbGFuZXMgZXZlcnkgY29tbWl0IHdvdWxkIGJlIGEgaGVhdnkgd29y ay4KPj4+Cj4+PiBVc2Vyc3BhY2UgbmVlZCAga25vdyBhbGwgcGxhbmVzIHJlbGF0aW9uc2hpcCwg Z3JvdXAgdGhlbSwgc29tZSBkaXNwbGF5Cj4+PiB3aW5kb3dzIGNhbiBwdXQgdG9nZXRoZXIsIHNv bWUgY2FuJ3QsCj4+PiB0b28gbWFueSBwZXJtdXRhdGlvbiBhbmQgY29tYmluYXRpb24sIEkgdGhp bmsgY2FuJ3QganVzdCBjb21taXQgd2l0aCB0cnkuCj4+Pgo+Pj4gZXhhbXBsZToKPj4+IHVzZXJz cGFjZToKPj4+IHdpbmRvd3MgMTogcG9zKDAsIDApICBzaXplKDEwMjQsIDEwMCkKPj4+IHdpbmRv d3MgMjogcG9zKDAsIDUwKSBzaXplKDQwMCwgNTAwKQo+Pj4gd2luZG93cyAzOiBwb3MoMCwgMjAw KSBzaXplKDgwMCwgMzAwKQo+Pj4KPj4+IGRybSBwbGFuZSByZXNvdXJjZXM6Cj4+PiBwbGFuZSAw IGFuZCBwbGFuZSAxIGlzIGEgZ3JvdXAgb2Ygc2hhcmUgcGxhbmVzCj4+PiBwbGFuZSAyIGlzIGNv bW1vbiBwbGFuZS4KPj4+Cj4+PiBpZiB1c2Vyc3BhY2Uga25vdyB0aGUgcmVsYXRpb25zaGlwLCB0 aGVuIHRoZXkgY2FuIGFzc2lnbiB3aW5kb3dzIDEgYW5kCj4+PiB3aW5kb3cgMyB0byBwbGFuZTAg YW5kIHBsYW5lIDEuIHRoYXQgd291bGQgYmUgc3VjY2Vzcy4KPj4+IGJ1dCBpZiB0aGV5IGRvbid0 IGtub3csIGFzc2lnbiB3aW5kb3cgMS8yIHRvIHBsYW5lIDAvMSwgZmFpbGVkLCBhc3NpZ24KPj4+ IHdpbmRvdyAyLzMgdG8gcGxhbmUgMC8xLCBmYWlsZWQuIG1vc3RseSB3b3VsZCBnZXQgZmFpbGVk Lgo+IFlvdSBjYW4gc3RpbGwgZG8gdGhpcyB3aXRoIHRoZSBkZXNpZ24gSSBkZXNjcmliZS4gVGhl IG9ubHkgZGlmZmVyZW5jZSBpcwo+IHRoYXQgeW91IGFsbG93IGdlbmVyaWMgdXNlcnNwYWNlIHRv IG1ha2Ugb3B0aW1hbCB1c2Ugb2YgeW91ciBwbGFuZXMsIHRvby4KPgo+Pj4+IFRoaXMgc2VlbXMg d2F5IHRvIGh3IHNwZWNpZmljIHRvIGJlIHVzZWZ1bCBhcyBhIGdlbmVyaWMgY29uY2VwdC4KPj4+ IFdlIHdhbnQgdG8gY2hhbmdlIHRoZSBkcm1fbW9kZV9nZXRwbGFuZV9yZXMgYmVoYXZpb3IsIGlm IHVzZXJzcGFjZSBjYWxsCj4+PiBEUk1fQ0xJRU5UX0NBUF9TSEFSRV9QTEFORVMsIHRoYXQgbWVh bnMgdXNlcnNwYWNlIGtub3cgaGFyZHdhcmUgbGltaXQsCj4+PiB0aGVuIHdlIHJldHVybiBmdWxs IHBsYW5lcyBzdXBwb3J0IHRvIHVzZXJzcGFjZSwgaWYgZG9uJ3QsIGp1c3QgbWFrZSBhCj4+PiBn cm91cCBvZiBzaGFyZSBwbGFuZXMgYXMgb25lIHBsYW5lLgo+Pj4gdGhpcyB3b3JrIGlzIG9uIGdl bmVyaWMgcGxhY2UuCj4gU28gLi4uIGRvIHlvdSBoYXZlIHBhdGNoZXMgZm9yIGFsbCB0aGUgZ2Vu ZXJpYyBrbXMgdXNlcnNwYWNlIHRoYXQncyBvdXQKPiB0aGVyZT8gQXJlIHRob3NlIHJldmlld2Vk IGFuZCByZWFkeSBmb3IgbWVyZ2luZz8KTm8sIHdlIGhhdmUgbm8gb3RoZXIgcGF0Y2hlcyBzZW5k IHRvIGdlbmVyaWMga21zIHVzZXJzcGFjZSB1cHN0cmVhbS4KCldlIHVzZSBpdCBvbiBvdXIgaW50 ZXJuYWwgdXNlcnNwYWNlIGFwcGxpY2F0aW9uIG5vdy4KCm9uIG91ciB1c2Vyc3BhY2UgYXBwbGlj YXRpb246CjEsIGRpcmVjdGx5IGNhbGwgZHJtU2V0Q2xpZW50Q2FwKGZkKCksIERSTV9DTElFTlRf Q0FQX1NIQVJFX1BMQU5FUywgMSk7CjIsIGdldCBwbGFuZXMgd2l0aCBkcm1Nb2RlR2V0UmVzb3Vy Y2VzKGZkKCkpOwozLCBnZXQgcGxhbmUgc2hhcmUgaWQgd2l0aCBkcm1Nb2RlT2JqZWN0R2V0UHJv cGVydGllcywKNCwgZ3JvdXAgdGhlIHBsYW5lcyB3aXRoIHNoYXJlIGlkLCBpZiB0d28gcGxhbmUg dXNlIHNhbWUgInNoYXJlIGlkIiwgCnRoYXQgbWVhbnMgdGhlc2UgcGxhbmUgaXMgb24gdGhlIHNh bWUgZ3JvdXAKNSwganVkZ2UgdGhlIHBsYW5lJ3MgbGltaXQgd2hlbiBkb2luZyBwbGFuZSBjb21t aXQuCgpvbiB1c2Vyc3BhY2Ugb25seSBhZGQgYSBuZXcgaW9jdGwgbWFjcm8gRFJNX0NMSUVOVF9D QVBfU0hBUkVfUExBTkVTLgoKPiBBZGRpbmcgbmV3IHVzZXJzcGFjZSBhYmkgaXMgbXVjaCwgbXVj aCwgbXVjaCBoYXJkZXIgdGhhbiBzb3ZsaW5nIHRoaXMgaW4KPiB0aGUgdm9wIGRyaXZlci4gSSdt IHdvcmtpbmcgb24gc29tZSBkb2N1bWVudGF0aW9uIHRvIG1ha2UgdGhpcyBhbGwgY2xlYXIKPiAo c2luY2UgbWFueSBhcm0gZm9sa3Mgc2VlbSB1bmF3YXJlIG9mIHRoZSB1YXBpIHJ1bGVzIHdlIGhh dmUgaW4gdGhlIGRybQo+IHN1YnN5c3RlbSkuIEJ1dCByZWFsbHksIHlvdSdyZSB0cnlpbmcgdGhl IG11Y2ggaGFyZGVyIHJvdXRlIHdpdGggdGhpcwo+IHBhdGNoLgpIbW1tLCBTbyBzYWQsIHlvdSBh cmUgcmlnaHQsIGNoYW5nZSB0aGUgZ2VuZXJpYyBhcGkgaXMgYSBoYXJkZXIgd29yay4KCk9rLCBJ IHdpbGwgdHJ5IHlvdXIgYWR2aWNlLgoKVGhhbmtzLgoKPiAtRGFuaWVsCgotLSAK77ytYXJrIFlh bwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1k ZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Thu, 28 Jul 2016 17:28:24 +0800 Subject: [PATCH 1/3] drm: introduce share plane In-Reply-To: <20160728080302.GG31475@phenom.ffwll.local> References: <1469519194-23133-1-git-send-email-mark.yao@rock-chips.com> <20160726082635.GA31475@phenom.ffwll.local> <579732B2.80600@rock-chips.com> <57997570.5070806@rock-chips.com> <20160728080302.GG31475@phenom.ffwll.local> Message-ID: <5799D038.5000906@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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. > 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 place. > So ... do you have patches for all the generic kms userspace that's out > there? Are those reviewed and ready for merging? No, we have no other patches send to generic kms userspace upstream. We use it on our internal userspace application now. on our userspace application: 1, directly call drmSetClientCap(fd(), DRM_CLIENT_CAP_SHARE_PLANES, 1); 2, get planes with drmModeGetResources(fd()); 3, get plane share id with drmModeObjectGetProperties, 4, group the planes with share id, if two plane use same "share id", that means these plane is on the same group 5, judge the plane's limit when doing plane commit. on userspace only add a new ioctl macro DRM_CLIENT_CAP_SHARE_PLANES. > Adding new userspace abi is much, much, much harder than sovling this in > the vop driver. I'm working on some documentation to make this all clear > (since many arm folks seem unaware of the uapi rules we have in the drm > subsystem). But really, you're trying the much harder route with this > patch. Hmmm, So sad, you are right, change the generic api is a harder work. Ok, I will try your advice. Thanks. > -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 S1754954AbcG1J3F (ORCPT ); Thu, 28 Jul 2016 05:29:05 -0400 Received: from regular1.263xmail.com ([211.150.99.130]:48120 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754376AbcG1J2e (ORCPT ); Thu, 28 Jul 2016 05:28:34 -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: <442efb5c2bff17aa030680f8cf0b000c> 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> <57997570.5070806@rock-chips.com> <20160728080302.GG31475@phenom.ffwll.local> From: Mark yao Message-ID: <5799D038.5000906@rock-chips.com> Date: Thu, 28 Jul 2016 17:28:24 +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: <20160728080302.GG31475@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月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 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. > 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 place. > So ... do you have patches for all the generic kms userspace that's out > there? Are those reviewed and ready for merging? No, we have no other patches send to generic kms userspace upstream. We use it on our internal userspace application now. on our userspace application: 1, directly call drmSetClientCap(fd(), DRM_CLIENT_CAP_SHARE_PLANES, 1); 2, get planes with drmModeGetResources(fd()); 3, get plane share id with drmModeObjectGetProperties, 4, group the planes with share id, if two plane use same "share id", that means these plane is on the same group 5, judge the plane's limit when doing plane commit. on userspace only add a new ioctl macro DRM_CLIENT_CAP_SHARE_PLANES. > Adding new userspace abi is much, much, much harder than sovling this in > the vop driver. I'm working on some documentation to make this all clear > (since many arm folks seem unaware of the uapi rules we have in the drm > subsystem). But really, you're trying the much harder route with this > patch. Hmmm, So sad, you are right, change the generic api is a harder work. Ok, I will try your advice. Thanks. > -Daniel -- Ｍark Yao