From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: DRM device memory writeback (Mali-DP) Date: Mon, 18 Jul 2016 17:01:14 +0200 Message-ID: <20160718150114.GC17101@phenom.ffwll.local> References: <20160714170340.GA32755@e106950-lin.cambridge.arm.com> <20160715073334.GO17101@phenom.ffwll.local> <20160715090918.GB32755@e106950-lin.cambridge.arm.com> <20160715105715.GG4329@intel.com> <87r3auajdi.fsf@eliezer.anholt.net> <20160718102933.GA603@e106950-lin.cambridge.arm.com> <7d4b6836-d896-f289-f940-bf641ae8e9fb@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) by gabe.freedesktop.org (Postfix) with ESMTPS id CC6CB6E153 for ; Mon, 18 Jul 2016 15:01:19 +0000 (UTC) Received: by mail-wm0-x229.google.com with SMTP id f126so107276220wma.1 for ; Mon, 18 Jul 2016 08:01:19 -0700 (PDT) Content-Disposition: inline In-Reply-To: <7d4b6836-d896-f289-f940-bf641ae8e9fb@xs4all.nl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Hans Verkuil Cc: daniel.vetter@ffwll.ch, liviu.dudau@arm.com, dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBKdWwgMTgsIDIwMTYgYXQgMTI6NDc6MzhQTSArMDIwMCwgSGFucyBWZXJrdWlsIHdy b3RlOgo+IE9uIDA3LzE4LzIwMTYgMTI6MjkgUE0sIEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4gPiBI aSwKPiA+IAo+ID4gT24gRnJpLCBKdWwgMTUsIDIwMTYgYXQgMTA6NDI6MDFBTSAtMDcwMCwgRXJp YyBBbmhvbHQgd3JvdGU6Cj4gPj4gVmlsbGUgU3lyasOkbMOkIDx2aWxsZS5zeXJqYWxhQGxpbnV4 LmludGVsLmNvbT4gd3JpdGVzOgo+ID4+Cj4gPj4+IE9uIEZyaSwgSnVsIDE1LCAyMDE2IGF0IDEw OjA5OjE5QU0gKzAxMDAsIEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4gPj4+PiBIaSBEYW5pZWwsCj4g Pj4+Pgo+ID4+Pj4gVGhhbmtzIGZvciB0YWtpbmcgYSBsb29rLgo+ID4+Pj4KPiA+Pj4+ICgrQ2Mg TGF1cmVudCkKPiA+Pj4+Cj4gPj4+PiBPbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAwOTozMzozNEFN ICswMjAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4+Pj4+IE9uIFRodSwgSnVsIDE0LCAyMDE2 IGF0IDA2OjAzOjQwUE0gKzAxMDAsIEJyaWFuIFN0YXJrZXkgd3JvdGU6Cj4gPj4+Pj4+IEhpLAo+ ID4+Pj4+Pgo+ID4+Pj4+PiBUaGUgTWFsaS1EUCBkaXNwbGF5IHByb2Nlc3NvcnMgaGF2ZSBhIG1l bW9yeS13cml0ZWJhY2sgZW5naW5lIHdoaWNoCj4gPj4+Pj4+IGNhbiB3cml0ZSB0aGUgcmVzdWx0 IG9mIHRoZSBjb21wb3NpdGlvbiAoQ1JUQyBvdXRwdXQpIHRvIGEgbWVtb3J5Cj4gPj4+Pj4+IGJ1 ZmZlciBpbiBhIHZhcmlldHkgb2YgZm9ybWF0cy4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gV2UncmUgbG9v a2luZyBmb3IgZmVlZGJhY2svc3VnZ2VzdGlvbnMgb24gaG93IHRvIGV4cG9zZSB0aGlzIGluIHRo ZQo+ID4+Pj4+PiBtYWxpLWRwIERSTSBrZXJuZWwgZHJpdmVyIC0gcG9zc2libHkgdmlhIFY0TDIu Cj4gPj4+Pj4+Cj4gPj4+Pj4+IFdlJ3ZlIGdvdCBhIGZldyB1c2UgY2FzZXMgd2hlcmUgd3JpdGVi YWNrIGlzIHVzZWZ1bDoKPiA+Pj4+Pj4gICAgLSB0ZXN0aW5nLCB0byBjaGVjayB0aGUgZGlzcGxh eWVkIGltYWdlCj4gPj4+Pj4KPiA+Pj4+PiBUaGlzIG1pZ2h0IG9yIG1pZ2h0IG5vdCBuZWVkIGEg c2VwYXJhdGUgaW50ZXJmYWNlLiBUaGVyZSBhcmUgZWZmb3J0cyB0bwo+ID4+Pj4+IG1ha2UgdGhl IGludGVsIGttcyB2YWxpZGF0aW9uIHRlc3RzIGluIGktZy10IGdlbmVyaWMgKHdlbGwgdW5kZXIg d2F5Cj4gPj4+Pj4gYWxyZWFkeSksIGFuZCBwYXJ0IG9mIHRoYXQgaXMgY3JlYXRpbmcgYSBnZW5l cmljIGluZnJhc3RydWN0dXJlIHRvIGNhcHR1cmUKPiA+Pj4+PiBkaXNwbGF5IENSQ3MgZm9yIGZ1 bmN0aW9uYWwgdGVzdHMgKHN0aWxsIGluIHByb2dyZXNzKS4KPiA+Pj4+Pgo+ID4+Pj4+IEJ1dCBp dCBtaWdodCBiZSBiZXR0ZXIgaWYgdXNlcnNwYWNlIGFic3RyYWN0cyBiZXR3ZWVuIGZ1bGwgcmVh ZGJhY2sgYW5kCj4gPj4+Pj4gZGlzcGxheSBDUkMsIGFzc3VtaW5nIHdlIGNhbiBtYWtlIGZ1bGwg d3JpdGViYWNrIGNyb3NzLXZlbmRvciBlbm91Z2ggZm9yCj4gPj4+Pj4gdGhhdCB1c2UtY2FzZS4K PiA+Pj4+Pgo+ID4+Pj4KPiA+Pj4+IEknZCBsZWFuIHRvd2FyZHMgdGhlIHVzZXJzcGFjZSBhYnN0 cmFjdGlvbi4KPiA+Pj4+IEVuY3VtYmVyaW5nIGEgc2ltcGxlIENSQyBpbnRlcmZhY2Ugd2l0aCBh bGwgdGhlIGNvbXBsZXhpdHkgb2YKPiA+Pj4+IGZ1bGwtd3JpdGViYWNrIChzaXplLCBzY2FsaW5n LCBwaXhlbCBmb3JtYXQsIG11bHRpLXBsYW5hciBldGMuKSBzb3VuZHMKPiA+Pj4+IGEgYml0IHVu bmVjZXNzYXJ5Lgo+ID4+Pj4KPiA+Pj4+IE9mIGNvdXJzZSwgaWYgdjRsMiBpc24ndCBnb2luZyB0 byBiZSB0aGUgY3Jvc3MtdmVuZG9yIGZ1bGwtd3JpdGViYWNrCj4gPj4+PiBpbXBsZW1lbnRhdGlv biwgdGhlbiB3ZSBuZWVkIHRvIGJlIGFpbWluZyB0byB1c2Ugd2hhdGV2ZXIgX2lzXyBpbgo+ID4+ Pj4gdGhlIG1hbGktZHAgZHJpdmVyLgo+ID4+Pj4KPiA+Pj4+Pj4gICAgLSBzY3JlZW4gcmVjb3Jk aW5nCj4gPj4+Pj4+ICAgIC0gd2lyZWxlc3MgZGlzcGxheSAoZS5nLiBNaXJhY2FzdCkKPiA+Pj4+ Pj4gICAgLSBkdWFsLWRpc3BsYXkgY2xvbmUgbW9kZQo+ID4+Pj4+PiAgICAtIG1lbW9yeS10by1t ZW1vcnkgY29tcG9zaXRpb24KPiA+Pj4+Pj4gTm90ZSB0aGF0IHRoZSBIVyBpcyBjYXBhYmxlIG9m IHdyaXRpbmcgb25lIG9mIHRoZSBpbnB1dCBwbGFuZXMgaW5zdGVhZAo+ID4+Pj4+PiBvZiB0aGUg Q1JUQyBvdXRwdXQsIGJ1dCB3ZSd2ZSBubyBnb29kIHVzZS1jYXNlIGZvciB3YW50aW5nIHRvIGV4 cG9zZQo+ID4+Pj4+PiB0aGF0Lgo+ID4+Pj4+Pgo+ID4+Pj4+PiBJbiBvdXIgQW5kcm9pZCBBREYg ZHJpdmVyWzFdIHdlIGV4cG9zZWQgdGhlIG1lbW9yeSB3cml0ZSBlbmdpbmUgYXMKPiA+Pj4+Pj4g cGFydCBvZiB0aGUgQURGIGRldmljZSB1c2luZyBBREYncyAiTUVNT1JZIiBpbnRlcmZhY2UgdHlw ZS4gRFJNL0tNUwo+ID4+Pj4+PiBkb2Vzbid0IGhhdmUgYW55IHNpbWlsYXIgc3VwcG9ydCBmb3Ig bWVtb3J5IG91dHB1dCBmcm9tIENSVENzLCBidXQgd2UKPiA+Pj4+Pj4gd2FudCB0byBleHBvc2Ug dGhlIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIG1haW5saW5lIE1hbGktRFAgRFJNIGRyaXZlci4KPiA+ Pj4+Pj4KPiA+Pj4+Pj4gQSBwcmV2aW91cyBkaXNjdXNzaW9uIG9uIHRoZSB0b3BpYyB3ZW50IHRv d2FyZHMgZXhwb3NpbmcgdGhlCj4gPj4+Pj4+IG1lbW9yeS13cml0ZSBlbmdpbmUgdmlhIFY0TDJb Ml0uCj4gPj4+Pj4+Cj4gPj4+Pj4+IEknbSB0aGlua2luZyB0byB1c2Vyc3BhY2UgdGhpcyB3b3Vs ZCBsb29rIGxpa2UgdHdvIGRpc3RpbmN0IGRldmljZXM6Cj4gPj4+Pj4+ICAgIC0gQSBEUk0gS01T IGRpc3BsYXkgY29udHJvbGxlci4KPiA+Pj4+Pj4gICAgLSBBIFY0TDIgdmlkZW8gc291cmNlLgo+ ID4+Pj4+PiBUaGV5J2QgYm90aCBleGlzdCBpbiB0aGUgc2FtZSBrZXJuZWwgZHJpdmVyLgo+ID4+ Pj4+PiBBIFY0TDIgY2xpZW50IGNhbiBxdWV1ZSB1cCAoQ0FQVFVSRSkgYnVmZmVycyBpbiB0aGUg bm9ybWFsIHdheSwgYW5kCj4gPj4+Pj4+IHRoZSBEUk0gZHJpdmVyIHdvdWxkIHNlZSBpZiB0aGVy ZSdzIGEgYnVmZmVyIHRvIGRlcXVldWUgZXZlcnkgdGltZSBhCj4gPj4+Pj4+IG5ldyBtb2Rlc2V0 IGlzIHJlY2VpdmVkIHZpYSB0aGUgRFJNIEFQSSAtIGlmIHNvLCBpdCBjYW4gY29uZmlndXJlIHRo ZQo+ID4+Pj4+PiBIVyB0byBkdW1wIGludG8gaXQgKG9uZS1zaG90IG9wZXJhdGlvbikuCj4gPj4+ Pj4+Cj4gPj4+Pj4+IEFuIGltcGxpY2F0aW9uIG9mIHRoaXMgaXMgdGhhdCBpZiB0aGUgc2NyZWVu IGlzIGFjdGl2ZWx5IGRpc3BsYXlpbmcgYQo+ID4+Pj4+PiBzdGF0aWMgc2NlbmUgYW5kIHRoZSBW NEwyIGNsaWVudCBxdWV1ZXMgdXAgYSBidWZmZXIsIGl0IHdvbid0IGdldAo+ID4+Pj4+PiBmaWxs ZWQgdW50aWwgdGhlIERSTSBzY2VuZSBjaGFuZ2VzLiBUaGlzIHNlZW1zIGJlc3QsIG90aGVyd2lz ZSB0aGUKPiA+Pj4+Pj4gVjRMMiBkcml2ZXIgaGFzIHRvIGNoYW5nZSB0aGUgSFcgY29uZmlndXJh dGlvbiBvdXQtb2YtYmFuZCBmcm9tIHRoZQo+ID4+Pj4+PiBEUk0gZGV2aWNlIHdoaWNoIHNvdW5k cyBob3JyaWJseSByYWN5Lgo+ID4+Pj4+Pgo+ID4+Pj4+PiBPbmUgZnVydGhlciBjb21wbGljYXRp b24gaXMgc2NhbGluZy4gT3VyIEhXIGhhcyBhIHNjYWxlciB3aGljaCBjYW4KPiA+Pj4+Pj4gdGFz a2VkIHdpdGggZWl0aGVyIHNjYWxpbmcgYW4gaW5wdXQgcGxhbmUgb3IgdGhlIGJ1ZmZlciBiZWlu ZyB3cml0dGVuCj4gPj4+Pj4+IHRvIG1lbW9yeSwgYnV0IG5vdCBib3RoIGF0IHRoZSBzYW1lIHRp bWUuIFRoaXMgbWVhbnMgd2UgbmVlZCB0bwo+ID4+Pj4+PiBhcmJpdHJhdGUgdGhlIHNjYWxlciBi ZXR3ZWVuIHRoZSBEUk0gZGV2aWNlIChzY2FsaW5nIGlucHV0IHBsYW5lcykgYW5kCj4gPj4+Pj4+ IHRoZSBWNEwyIGRldmljZSAoc2NhbGluZyBvdXRwdXQgYnVmZmVycykuCj4gPj4+Pj4+Cj4gPj4+ Pj4+IEkgdGhpbmsgdGhlIHNpbXBsZXN0IGFwcHJvYWNoIGhlcmUgaXMgdG8gYWxsb3cgVjRMMiB0 byAiY2xhaW0iIHRoZQo+ID4+Pj4+PiBzY2FsZXIgYnkgc2V0dGluZyB0aGUgaW1hZ2Ugc2l6ZSAo VklESU9DX1NfRk1UKSB0byBzb21ldGhpbmcgb3RoZXIKPiA+Pj4+Pj4gdGhhbiB0aGUgQ1JUQydz IGN1cnJlbnQgcmVzb2x1dGlvbi4gQWZ0ZXIgdGhhdCwgYW55IGF0dGVtcHQgdG8gdXNlIHRoZQo+ ID4+Pj4+PiBzY2FsZXIgb24gYW4gaW5wdXQgcGxhbmUgdmlhIERSTSBzaG91bGQgZmFpbCBhdG9t aWNfY2hlY2soKS4KPiA+Pj4+Pgo+ID4+Pj4+IFRoYXQncyBwZXJmZWN0bHkgZmluZSBhdG9taWNf Y2hlY2sgYmVoYXZpb3VyLiBPbmx5IHRyb3VibGUgaXMgdGhhdCB0aGUgdjRsCj4gPj4+Pj4gbG9j a2luZyBtdXN0IGludGVncmF0ZSBpbnRvIHRoZSBkcm0gbG9ja2luZywgYnV0IHRoYXQgc2hvdWxk IGJlIGRvYWJsZS4KPiA+Pj4+PiBXb3JzdCBjYXNlIHlvdSBtdXN0IHNoYWRvdyBhbGwgdjRsIGxv Y2tzIHdpdGggYSB3YWl0L3dvdW5kCj4gPj4+Pj4gZHJtX21vZGVzZXRfbG9jayB0byBhdm9pZCBk ZWFkbG9ja3MgKHNpbmNlIHlvdSBjb3VsZCB0cnkgdG8gZ3JhYiBsb2Nrcwo+ID4+Pj4gPmZyb20g ZWl0aGVyIGVuZCkuCj4gPj4+Pj4KPiA+Pj4+Cj4gPj4+PiBZZXMsIEkgaGF2ZW4ndCBsb29rZWQg YXQgdGhlIGRldGFpbHMgb2YgdGhlIGxvY2tpbmcgYnV0IEknbSBob3BpbmcKPiA+Pj4+IGl0J3Mg bWFuYWdlYWJsZS4KPiA+Pj4+Cj4gPj4+Pj4+IElmIHRoZSBWNEwyIGNsaWVudCBnb2VzIGF3YXkg b3Igc2V0cyB0aGUgaW1hZ2Ugc2l6ZSB0byB0aGUgQ1JUQydzCj4gPj4+Pj4+IG5hdGl2ZSByZXNv bHV0aW9uLCB0aGVuIHRoZSBEUk0gZGV2aWNlIGlzIGFsbG93ZWQgdG8gdXNlIHRoZSBzY2FsZXIu Cj4gPj4+Pj4+IEkgZG9uJ3Qga25vdyBpZi9ob3cgdGhlIERSTSBkZXZpY2Ugc2hvdWxkIGNvbW11 bmljYXRlIHRvIHVzZXJzcGFjZQo+ID4+Pj4+PiB0aGF0IHRoZSBzY2FsZXIgaXMgb3IgaXNuJ3Qg YXZhaWxhYmxlIGZvciB1c2UuCj4gPj4+Pj4+Cj4gPj4+Pj4+IEFueSB0aG91Z2h0cyBvbiB0aGlz IGFwcHJvYWNoPwo+ID4+Pj4+PiBJcyBpdCBhY2NlcHRhYmxlIHRvIGJvdGggVjRMMiBhbmQgRFJN IGZvbGtzPwo+ID4+Pj4+Cj4gPj4+Pj4gRm9yIHN0cmVhbWluZyBhIFY0TDIgY2FwdHVyZSBkZXZp Y2Ugc2VlbXMgbGlrZSB0aGUgcmlnaHQgaW50ZXJmYWNlLiBCdXQgaWYKPiA+Pj4+PiB5b3Ugd2Fu dCB0byB1c2Ugd3JpdGViYWNrIGluIHlvdXIgY29tcG9zaXRvciB5b3UgbXVzdCBrbm93IHdoaWNo IGF0b21pYwo+ID4+Pj4+IGttcyB1cGRhdGUgcmVzdWx0cyBpbiB3aGljaCBmcmFtZSwgc2luY2Ug aWYgeW91IGRvbid0IHlvdSBjYW4ndCB1c2UgdGhhdAo+ID4+Pj4+IGNvbXBvc2l0ZWQgYnVmZmVy IGZvciB0aGUgbmV4dCBmcmFtZSByZWxpYWJsZS4KPiA+Pj4+Pgo+ID4+Pj4+IEZvciB0aGF0IGNh c2UgSSB0aGluayBhIGRybS1vbmx5IHNvbHV0aW9uIHdvdWxkIGJlIGJldHRlciwgdG8gbWFrZSBz dXJlCj4gPj4+Pj4geW91IGNhbiBkbyBhbiBhdG9taWMgdXBkYXRlIGFuZCB3cml0ZWJhY2sgaW4g b25lIHN0ZXAuIHY0bCBzZWVtcyB0byBncm93Cj4gPj4+Pj4gYW4gYXRvbWljIGFwaSBvZiBpdHMg b3duLCBidXQgSSBkb24ndCB0aGluayB3ZSdsbCBoYXZlIG9uZSBzcGFubmluZwo+ID4+Pj4+IHN1 YnN5c3RlbXMgYW55dGltZSBzb29uLgo+ID4+Pj4+Cj4gPj4+Pgo+ID4+Pj4gSSd2ZSBiZWVuIHRo aW5raW5nIGFib3V0IHRoaXMgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBhIEhXQ29tcG9zZXIK PiA+Pj4+IGltcGxlbWVudGF0aW9uIGFuZCBJIHRoaW5rIHRoZSBoeWJyaWQgRFJNLVY0TDIgZGV2 aWNlIHdvdWxkIHdvcmsgT0suCj4gPj4+PiBIb3dldmVyIGl0IGRlcGVuZHMgb24gdGhlIGJlaGF2 aW91ciBJIG1lbnRpb25lZCBhYm92ZToKPiA+Pj4+Cj4gPj4+Pj4+IGlmIHRoZSBzY3JlZW4gaXMg YWN0aXZlbHkgZGlzcGxheWluZyBhCj4gPj4+Pj4+IHN0YXRpYyBzY2VuZSBhbmQgdGhlIFY0TDIg Y2xpZW50IHF1ZXVlcyB1cCBhIGJ1ZmZlciwgaXQgd29uJ3QgZ2V0Cj4gPj4+Pj4+IGZpbGxlZCB1 bnRpbCB0aGUgRFJNIHNjZW5lIGNoYW5nZXMuCj4gPj4+Pgo+ID4+Pj4gVjRMMiBidWZmZXIgcXVl dWVzIGFyZSBGSUZPLCBzbyBhcyBsb25nIGFzIHRoZSBjb21wb3NpdG9yIHF1ZXVlcyBvbmx5Cj4g Pj4+PiBvbmUgVjRMMiBidWZmZXIgcGVyIGF0b21pYyB1cGRhdGUsIHRoZXJlJ3Mgbm8gYW1iaWd1 aXR5Lgo+ID4+Pj4gSW4gdGhlIG1vc3Qgc2ltcGxpc3RpYyBjYXNlIHRoZSBjb21wb3NpdG9yIHdv dWxkIGFsdGVybmF0ZSBiZXR3ZWVuOgo+ID4+Pj4gICAtIFF1ZXVlIFY0TDIgYnVmZmVyCj4gPj4+ PiAgIC0gRFJNIGF0b21pYyB1cGRhdGUKPiA+Pj4+IC4uLiBhbmQgZGVxdWV1ZSBlaXRoZXIgaW4g dGhlIHNhbWUgdGhyZWFkIG9yIGEgZGlmZmVyZW50IG9uZS4gQXMgbG9uZwo+ID4+Pj4gYXMgdGhl IGNvbXBvc2l0b3Iga2VlcHMgdHJhY2sgb2YgaG93IG1hbnkgYnVmZmVycyBpdCBoYXMgcXVldWVk IGFuZAo+ID4+Pj4gaG93IG1hbnkgYXRvbWljIHVwZGF0ZXMgaXQncyBtYWRlLCBpdCBkb2Vzbid0 IHJlYWxseSBtYXR0ZXIuCj4gPj4+Pgo+ID4+Pj4gV2UnZCBwcm9iYWJseSBiZSBsb29raW5nIHRv IGFkZCBpbiBWNEwyIGFzeW5jaHJvbm91cyBkZXF1ZXVlIHVzaW5nCj4gPj4+PiBmZW5jZXMgZm9y IHN5bmNocm9uaXNhdGlvbiwgYnV0IHRoYXQncyBhIHNlcGFyYXRlIGlzc3VlLgo+ID4+Pj4KPiA+ Pj4+PiBGb3IgdGhlIGttcy1vbmx5IGludGVyZmFjZSB0aGUgaWRlYSB3YXMgdG8gYWRkIGEgcHJv cGVydHkgb24gdGhlIGNydGMKPiA+Pj4+PiB3aGVyZSB5b3UgY2FuIGF0dGFjaCBhIHdyaXRlYmFj ayBkcm1fZnJhbWVidWZmZXIuIEV4dGVuZGluZyB0aGF0IGlkZWEgdG8KPiA+Pj4+PiB0aGUgZHJt LT52NGwgY2FzZSB3ZSBjb3VsZCBjcmVhdGUgc3BlY2lhbCBkcm1fZnJhbWVidWZmZXIgb2JqZWN0 cwo+ID4+Pj4+IHJlcHJlc2VudGluZyBhIHY0bCBzaW5rLCBhbmQgYXR0YWNoIHRoZW0gdG8gdGhl IHNhbWUgcHJvcGVydHkuIFRoYXQgd291bGQKPiA+Pj4+PiBhbHNvIHNvbHZlIHRoZSBwcm9ibGVt IG9mIGdldHRpbmcgc29tZSBhZ3JlZW1lbnQgb24gYnVmZmVyIG1ldGFkYXRhCj4gPj4+Pj4gYmV0 d2VlbiB2NGwgYW5kIGRybSBzaWRlLgo+ID4+Pj4+Cj4gPj4+Pgo+ID4+Pj4gSSB0aGluayBhIGRy bV9mcmFtZWJ1ZmZlciBvbiBpdHMgb3duIHdvdWxkbid0IGJlIGVub3VnaCB0byBoYW5kbGUgb3Vy Cj4gPj4+PiBzY2FsaW5nIGNhc2UgLSBhdCB0aGF0IHBvaW50IGl0IHN0YXJ0cyB0byBsb29rIG1v cmUgbGlrZSBhIHBsYW5lLgo+ID4+Pj4gSG93ZXZlciwgaWYgInNwZWNpYWwiIENSVEMgc2lua3Mg YmVjYW1lIGEgdGhpbmcgaXQgY291bGQgYWxsb3cgdXMgdG8KPiA+Pj4+IGNoYWluIG91ciB3cml0 ZWJhY2sgb3V0cHV0IHRvIGFub3RoZXIgQ1JUQydzIGlucHV0ICh2aWEgbWVtb3J5KQo+ID4+Pj4g d2l0aG91dCBhIHRyaXAgdGhyb3VnaCB1c2Vyc3BhY2UsIHdoaWNoIHdvdWxkIGJlIG5pY2UuCj4g Pj4+Cj4gPj4+IE15IHRoaW5raW5nIGhhcyBiZWVuIHRoYXQgd2UgY291bGQgcmVwcmVzZW50IHRo ZSB3cml0ZWJhY2sgc2luawo+ID4+PiBhcyBhIGNvbm5lY3Rvci4gQ29tYmluZSB0aGF0IHdpdGgg bXkgb3RoZXIgaWRlYSBvZiBleHBvc2luZyBhCj4gPj4+IGZpeGVkIG1vZGUgcHJvcGVydHkgZm9y IGVhY2ggY29ubmVjdG9yICh0byBtYWtlIG91dHB1dCBzY2FsaW5nCj4gPj4+IHVzZXIgY29uZmln dXJhYmxlKSwgYW5kIHdlIHNob3VsZCBlbmQgdXAgd2l0aCBhIHdheSB0byBjb250cm9sCj4gPj4+ IHRoZSBzY2FsaW5nIG9mIHRoZSB3cml0ZWJhY2sgcGF0aC4KPiA+Pj4KPiA+Pj4gQWxzbyBpdCB3 b3VsZCBtZWFuIHRoZXJlJ3MgYWx3YXlzIGEgY29ubmVjdG9yIGF0dGFjaGVkIHRvIHRoZQo+ID4+ PiBjcnRjLCBldmVuIGZvciB0aGUgcHVyZSB3cml0ZWJhY2sgb25seSBjYXNlLCB3aGljaCBJIHRo aW5rIHNob3VsZAo+ID4+PiByZXN1bHQgaW4gbGVzcyBwcm9ibGVtcyBpbiBnZW5lcmFsIGFzIEkn bSBzdXJlIHRoZXJlIGFyZSBhIGxvdCBvZgo+ID4+PiBhc3N1bXB0aW9ucyBpbiB0aGUgY29kZSB0 aGF0IHRoZXJlIG11c3QgYmUgYXQgbGVhc3Qgb25lIGNvbm5lY3Rvcgo+ID4+PiBmb3IgYW4gYWN0 aXZlIGNydGMuCj4gPj4KPiA+PiBUaGlzIGlzIHdoYXQgSSd2ZSBiZWVuIHRoaW5raW5nIGZvciB2 YzQncyB3cml0ZWJhY2sgYXMgd2VsbC4gIEkKPiA+PiBkZWZpbml0ZWx5IHdhbnQgbXkgd3JpdGVi YWNrIHRvIGJlIHVzaW5nIHRoZSBzYW1lIGRyaXZlcnMvZ3B1L2RybS92YzQKPiA+PiBjb2RlIGZv ciBzZXR0aW5nIHVwIHRoZSBoYXJkd2FyZS4gIEFuZCwgc2luY2UgSSBleHBlY3Qgd3JpdGViYWNr IHRvIGJlCj4gPj4gbW9zdGx5IHVzZWQgYnkgY29tcG9zaXRvcnMgZm9yIHRoZSBjYXNlIHdoZXJl IGEgZnJhbWUgZXhjZWVkcyBiYW5kd2lkdGgKPiA+PiBjb25zdHJhaW50cywgSSB3YW50IHVzZXJz cGFjZSB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2FtZSBEUk0gQVBJcyBmb3IKPiA+PiBzZXR0aW5n IHVwIHRoZSBmcmFtZSB0byBiZSB3cml0dGVuIGJhY2sgYXMgaXQgd2FzIHRyeWluZyB0byB1c2Ug Zm9yCj4gPj4gc2V0dGluZyB1cCB0aGUgZnJhbWUgYmVmb3JlLgo+ID4gCj4gPiBPSywgc28gbGV0 J3MgdGFsayBhYm91dCB1c2luZyBjb25uZWN0b3JzIGluc3RlYWQgdGhlbiA6LSkKPiA+IAo+ID4g V2UgY2FuIGF0dGFjaCBhIGdlbmVyaWMgZml4ZWRfbW9kZSBwcm9wZXJ0eSB3aGljaCBjYW4gcmVw cmVzZW50IHBhbmVsCj4gPiBmaXR0ZXJzIG9yIE1hbGktRFAncyB3cml0ZWJhY2sgc2NhbGluZywg dGhhdCBzb3VuZHMgZ29vZC4KPiA+IAo+ID4gVGhlIERSTSBkcml2ZXIgY2FuIGNyZWF0ZSBhIG5l dyAidmlydHVhbCIgZW5jb2Rlci9jb25uZWN0b3IgcGFpciwgSQo+ID4gZ3Vlc3Mgd2l0aCBhIG5l dyBjb25uZWN0b3IgdHlwZSBzcGVjaWZpY2FsbHkgZm9yIG1lbW9yeS13cml0ZWJhY2s/Cj4gPiBP biB0aGlzIGNvbm5lY3RvciB3ZSBhbGxvdyB0aGUgZmJfaWQgcHJvcGVydHkgdG8gYXR0YWNoIGEg ZnJhbWVidWZmZXIKPiA+IGZvciB3cml0aW5nIGludG8uCj4gPiBXZSdkIHByb2JhYmx5IHdhbnQg YW4gYWRkaXRpb25hbCBwcm9wZXJ0eSB0byBlbmFibGUgd3JpdGViYWNrLCBwZXJoYXBzCj4gPiBh biBlbnVtOiAiZGlzYWJsZWQiLCAic3RyZWFtaW5nIiwgIm9uZXNob3QiLgo+ID4gCj4gPiBJIHRo aW5rIGl0IG1ha2VzIHNlbnNlIHRvIHB1dCB0aGUgb3V0cHV0IGJ1ZmZlciBmb3JtYXQsIHNpemUg ZXRjLgo+ID4gdmFsaWRhdGlvbiBpbiB0aGUgdmlydHVhbCBlbmNvZGVyJ3MgYXRvbWljX2NoZWNr LiBJdCBoYXMgYWNjZXNzIHRvCj4gPiBib3RoIENSVEMgYW5kIGNvbm5lY3RvciBzdGF0ZSwgYW5k IHRoZSBlbmNvZGVyIGlzIHN1cHBvc2VkIHRvCj4gPiByZXByZXNlbnQgdGhlIGZvcm1hdC9zdHJl YW0gY29udmVyc2lvbiBlbGVtZW50IGFueXdheS4KPiA+IAo+ID4gV2hhdCBJJ20gbm90IHNvIGNs ZWFyIG9uIGlzIGhvdyB0byBtYW5hZ2UgdGhlIEFQSSB3aXRoIHVzZXJzcGFjZS4KPiAKPiBJIGFt IG5vdCB0ZXJyaWJseSBlbnRodXNpYXN0aWMgKHRvIHNheSB0aGUgbGVhc3QpIGlmIGEgbmV3IGRy bSBBUEkgaXMKPiBjcmVhdGVkIGZvciB2aWRlbyBjYXB0dXJlLiBUaGF0J3Mgd2hhdCBWNEwyIGlz IGZvciBhbmQgaXQgY29tZXMgd2l0aAo+IGtlcm5lbCBmcmFtZXdvcmtzLCBkb2N1bWVudGF0aW9u IGFuZCB1dGlsaXRpZXMuIENyZWF0aW5nIGEgbmV3IEFQSSB3aWxsCj4gbm90IG1ha2UgdXNlcnNw YWNlIGRldmVsb2VwcnMgaGFwcHkuCj4gCj4gSSBrbm93IGl0IGlzIGEgcGFpbiB0byB3b3JrIHdp dGggZGlmZmVyZW50IHN1YnN5c3RlbXMsIGJ1dCByZWludmVudGluZwo+IHRoZSB3aGVlbCBpcyBh IG11Y2ggYmlnZ2VyIHBhaW4uIEZvciB5b3UgYW5kIGZvciB0aGUgcG9vciBzb2RzIHdobyBoYXZl Cj4gdG8gdXNlIHlldCBhbm90aGVyIEFQSSB0byBkbyB0aGUgc2FtZSB0aGluZy4KPiAKPiBPZiBj b3Vyc2UgdGhpcyBoYXMgdG8gYmUgaG9va2VkIHVwIHRvIGRybSBhdCB0aGUgbG93IGxldmVsLCBh bmQgYW55dGhpbmcKPiB0aGF0IGNhbiBiZSBkb25lIHRvIGhlbHAgb3V0IHdpdGggdGhhdCBmcm9t IHRoZSBWNEwyIHNpZGUgb2YgdGhpbmdzIGlzCj4gZmluZSwgYnV0IGNyZWF0aW5nIGR1cGxpY2F0 ZSBwdWJsaWMgQVBJcyBpc24ndCB0aGUgd2F5IElNSE8uCgpJIGFncmVlIGZvciB0aGUgc3RyZWFt aW5nIHZpZGVvIHVzZS1jYXNlLiBCdXQgZm9yIGNvbXBvc2l0b3JzIEkgZG8gYWdyZWUKd2l0aCBF cmljIHRoYXQgYSBzaW1wbGUgZnJhbWUgY2FwdHVyZSBpbnRlcmZhY2UgaW50ZWdyYXRlZCB3aXRo IHRoZSBkcm0KYXRvbWljIGlvY3RsIGlzIHdoYXQgd2Ugd2FudC4gQXQgbGVhc3QgbXkgdW5kZXJz dGFuZGluZyBvZiB2NGwgaXMgdGhhdAppdCdzIG5vdCB0aGF0IHdlbGwgc3VpdGVkIHRvIGdyYWJi aW5nIHNwZWNpZmljIChzaW5nbGUpIGZyYW1lcy4KLURhbmllbAotLSAKRGFuaWVsIFZldHRlcgpT b2Z0d2FyZSBFbmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KaHR0cDovL2Jsb2cuZmZ3bGwuY2gK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:37756 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751784AbcGRPBV (ORCPT ); Mon, 18 Jul 2016 11:01:21 -0400 Received: by mail-wm0-f52.google.com with SMTP id i5so120998205wmg.0 for ; Mon, 18 Jul 2016 08:01:20 -0700 (PDT) Date: Mon, 18 Jul 2016 17:01:14 +0200 From: Daniel Vetter To: Hans Verkuil Cc: Brian Starkey , Eric Anholt , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , dri-devel@lists.freedesktop.org, liviu.dudau@arm.com, laurent.pinchart@ideasonboard.com, linux-media@vger.kernel.org, david.brown@arm.com, daniel.vetter@ffwll.ch Subject: Re: DRM device memory writeback (Mali-DP) Message-ID: <20160718150114.GC17101@phenom.ffwll.local> References: <20160714170340.GA32755@e106950-lin.cambridge.arm.com> <20160715073334.GO17101@phenom.ffwll.local> <20160715090918.GB32755@e106950-lin.cambridge.arm.com> <20160715105715.GG4329@intel.com> <87r3auajdi.fsf@eliezer.anholt.net> <20160718102933.GA603@e106950-lin.cambridge.arm.com> <7d4b6836-d896-f289-f940-bf641ae8e9fb@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d4b6836-d896-f289-f940-bf641ae8e9fb@xs4all.nl> Sender: linux-media-owner@vger.kernel.org List-ID: On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote: > On 07/18/2016 12:29 PM, Brian Starkey wrote: > > Hi, > > > > On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote: > >> Ville Syrjälä writes: > >> > >>> On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote: > >>>> Hi Daniel, > >>>> > >>>> Thanks for taking a look. > >>>> > >>>> (+Cc Laurent) > >>>> > >>>> On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote: > >>>>> On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote: > >>>>>> Hi, > >>>>>> > >>>>>> The Mali-DP display processors have a memory-writeback engine which > >>>>>> can write the result of the composition (CRTC output) to a memory > >>>>>> buffer in a variety of formats. > >>>>>> > >>>>>> We're looking for feedback/suggestions on how to expose this in the > >>>>>> mali-dp DRM kernel driver - possibly via V4L2. > >>>>>> > >>>>>> We've got a few use cases where writeback is useful: > >>>>>> - testing, to check the displayed image > >>>>> > >>>>> This might or might not need a separate interface. There are efforts to > >>>>> make the intel kms validation tests in i-g-t generic (well under way > >>>>> already), and part of that is creating a generic infrastructure to capture > >>>>> display CRCs for functional tests (still in progress). > >>>>> > >>>>> But it might be better if userspace abstracts between full readback and > >>>>> display CRC, assuming we can make full writeback cross-vendor enough for > >>>>> that use-case. > >>>>> > >>>> > >>>> I'd lean towards the userspace abstraction. > >>>> Encumbering a simple CRC interface with all the complexity of > >>>> full-writeback (size, scaling, pixel format, multi-planar etc.) sounds > >>>> a bit unnecessary. > >>>> > >>>> Of course, if v4l2 isn't going to be the cross-vendor full-writeback > >>>> implementation, then we need to be aiming to use whatever _is_ in > >>>> the mali-dp driver. > >>>> > >>>>>> - screen recording > >>>>>> - wireless display (e.g. Miracast) > >>>>>> - dual-display clone mode > >>>>>> - memory-to-memory composition > >>>>>> Note that the HW is capable of writing one of the input planes instead > >>>>>> of the CRTC output, but we've no good use-case for wanting to expose > >>>>>> that. > >>>>>> > >>>>>> In our Android ADF driver[1] we exposed the memory write engine as > >>>>>> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS > >>>>>> doesn't have any similar support for memory output from CRTCs, but we > >>>>>> want to expose the functionality in the mainline Mali-DP DRM driver. > >>>>>> > >>>>>> A previous discussion on the topic went towards exposing the > >>>>>> memory-write engine via V4L2[2]. > >>>>>> > >>>>>> I'm thinking to userspace this would look like two distinct devices: > >>>>>> - A DRM KMS display controller. > >>>>>> - A V4L2 video source. > >>>>>> They'd both exist in the same kernel driver. > >>>>>> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and > >>>>>> the DRM driver would see if there's a buffer to dequeue every time a > >>>>>> new modeset is received via the DRM API - if so, it can configure the > >>>>>> HW to dump into it (one-shot operation). > >>>>>> > >>>>>> An implication of this is that if the screen is actively displaying a > >>>>>> static scene and the V4L2 client queues up a buffer, it won't get > >>>>>> filled until the DRM scene changes. This seems best, otherwise the > >>>>>> V4L2 driver has to change the HW configuration out-of-band from the > >>>>>> DRM device which sounds horribly racy. > >>>>>> > >>>>>> One further complication is scaling. Our HW has a scaler which can > >>>>>> tasked with either scaling an input plane or the buffer being written > >>>>>> to memory, but not both at the same time. This means we need to > >>>>>> arbitrate the scaler between the DRM device (scaling input planes) and > >>>>>> the V4L2 device (scaling output buffers). > >>>>>> > >>>>>> I think the simplest approach here is to allow V4L2 to "claim" the > >>>>>> scaler by setting the image size (VIDIOC_S_FMT) to something other > >>>>>> than the CRTC's current resolution. After that, any attempt to use the > >>>>>> scaler on an input plane via DRM should fail atomic_check(). > >>>>> > >>>>> That's perfectly fine atomic_check behaviour. Only trouble is that the v4l > >>>>> locking must integrate into the drm locking, but that should be doable. > >>>>> Worst case you must shadow all v4l locks with a wait/wound > >>>>> drm_modeset_lock to avoid deadlocks (since you could try to grab locks > >>>> >from either end). > >>>>> > >>>> > >>>> Yes, I haven't looked at the details of the locking but I'm hoping > >>>> it's manageable. > >>>> > >>>>>> If the V4L2 client goes away or sets the image size to the CRTC's > >>>>>> native resolution, then the DRM device is allowed to use the scaler. > >>>>>> I don't know if/how the DRM device should communicate to userspace > >>>>>> that the scaler is or isn't available for use. > >>>>>> > >>>>>> Any thoughts on this approach? > >>>>>> Is it acceptable to both V4L2 and DRM folks? > >>>>> > >>>>> For streaming a V4L2 capture device seems like the right interface. But if > >>>>> you want to use writeback in your compositor you must know which atomic > >>>>> kms update results in which frame, since if you don't you can't use that > >>>>> composited buffer for the next frame reliable. > >>>>> > >>>>> For that case I think a drm-only solution would be better, to make sure > >>>>> you can do an atomic update and writeback in one step. v4l seems to grow > >>>>> an atomic api of its own, but I don't think we'll have one spanning > >>>>> subsystems anytime soon. > >>>>> > >>>> > >>>> I've been thinking about this from the point of view of a HWComposer > >>>> implementation and I think the hybrid DRM-V4L2 device would work OK. > >>>> However it depends on the behaviour I mentioned above: > >>>> > >>>>>> if the screen is actively displaying a > >>>>>> static scene and the V4L2 client queues up a buffer, it won't get > >>>>>> filled until the DRM scene changes. > >>>> > >>>> V4L2 buffer queues are FIFO, so as long as the compositor queues only > >>>> one V4L2 buffer per atomic update, there's no ambiguity. > >>>> In the most simplistic case the compositor would alternate between: > >>>> - Queue V4L2 buffer > >>>> - DRM atomic update > >>>> ... and dequeue either in the same thread or a different one. As long > >>>> as the compositor keeps track of how many buffers it has queued and > >>>> how many atomic updates it's made, it doesn't really matter. > >>>> > >>>> We'd probably be looking to add in V4L2 asynchronous dequeue using > >>>> fences for synchronisation, but that's a separate issue. > >>>> > >>>>> For the kms-only interface the idea was to add a property on the crtc > >>>>> where you can attach a writeback drm_framebuffer. Extending that idea to > >>>>> the drm->v4l case we could create special drm_framebuffer objects > >>>>> representing a v4l sink, and attach them to the same property. That would > >>>>> also solve the problem of getting some agreement on buffer metadata > >>>>> between v4l and drm side. > >>>>> > >>>> > >>>> I think a drm_framebuffer on its own wouldn't be enough to handle our > >>>> scaling case - at that point it starts to look more like a plane. > >>>> However, if "special" CRTC sinks became a thing it could allow us to > >>>> chain our writeback output to another CRTC's input (via memory) > >>>> without a trip through userspace, which would be nice. > >>> > >>> My thinking has been that we could represent the writeback sink > >>> as a connector. Combine that with my other idea of exposing a > >>> fixed mode property for each connector (to make output scaling > >>> user configurable), and we should end up with a way to control > >>> the scaling of the writeback path. > >>> > >>> Also it would mean there's always a connector attached to the > >>> crtc, even for the pure writeback only case, which I think should > >>> result in less problems in general as I'm sure there are a lot of > >>> assumptions in the code that there must be at least one connector > >>> for an active crtc. > >> > >> This is what I've been thinking for vc4's writeback as well. I > >> definitely want my writeback to be using the same drivers/gpu/drm/vc4 > >> code for setting up the hardware. And, since I expect writeback to be > >> mostly used by compositors for the case where a frame exceeds bandwidth > >> constraints, I want userspace to be able to use the same DRM APIs for > >> setting up the frame to be written back as it was trying to use for > >> setting up the frame before. > > > > OK, so let's talk about using connectors instead then :-) > > > > We can attach a generic fixed_mode property which can represent panel > > fitters or Mali-DP's writeback scaling, that sounds good. > > > > The DRM driver can create a new "virtual" encoder/connector pair, I > > guess with a new connector type specifically for memory-writeback? > > On this connector we allow the fb_id property to attach a framebuffer > > for writing into. > > We'd probably want an additional property to enable writeback, perhaps > > an enum: "disabled", "streaming", "oneshot". > > > > I think it makes sense to put the output buffer format, size etc. > > validation in the virtual encoder's atomic_check. It has access to > > both CRTC and connector state, and the encoder is supposed to > > represent the format/stream conversion element anyway. > > > > What I'm not so clear on is how to manage the API with userspace. > > I am not terribly enthusiastic (to say the least) if a new drm API is > created for video capture. That's what V4L2 is for and it comes with > kernel frameworks, documentation and utilities. Creating a new API will > not make userspace develoeprs happy. > > I know it is a pain to work with different subsystems, but reinventing > the wheel is a much bigger pain. For you and for the poor sods who have > to use yet another API to do the same thing. > > Of course this has to be hooked up to drm at the low level, and anything > that can be done to help out with that from the V4L2 side of things is > fine, but creating duplicate public APIs isn't the way IMHO. I agree for the streaming video use-case. But for compositors I do agree with Eric that a simple frame capture interface integrated with the drm atomic ioctl is what we want. At least my understanding of v4l is that it's not that well suited to grabbing specific (single) frames. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch