From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: DRM device memory writeback (Mali-DP) Date: Fri, 15 Jul 2016 13:57:15 +0300 Message-ID: <20160715105715.GG4329@intel.com> References: <20160714170340.GA32755@e106950-lin.cambridge.arm.com> <20160715073334.GO17101@phenom.ffwll.local> <20160715090918.GB32755@e106950-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTP id 0BDC06E064 for ; Fri, 15 Jul 2016 10:57:19 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20160715090918.GB32755@e106950-lin.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Brian Starkey Cc: dri-devel@lists.freedesktop.org, liviu.dudau@arm.com, laurent.pinchart@ideasonboard.com, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBKdWwgMTUsIDIwMTYgYXQgMTA6MDk6MTlBTSArMDEwMCwgQnJpYW4gU3RhcmtleSB3 cm90ZToKPiBIaSBEYW5pZWwsCj4gCj4gVGhhbmtzIGZvciB0YWtpbmcgYSBsb29rLgo+IAo+ICgr Q2MgTGF1cmVudCkKPiAKPiBPbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAwOTozMzozNEFNICswMjAw LCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCAwNjowMzo0 MFBNICswMTAwLCBCcmlhbiBTdGFya2V5IHdyb3RlOgo+ID4+IEhpLAo+ID4+Cj4gPj4gVGhlIE1h bGktRFAgZGlzcGxheSBwcm9jZXNzb3JzIGhhdmUgYSBtZW1vcnktd3JpdGViYWNrIGVuZ2luZSB3 aGljaAo+ID4+IGNhbiB3cml0ZSB0aGUgcmVzdWx0IG9mIHRoZSBjb21wb3NpdGlvbiAoQ1JUQyBv dXRwdXQpIHRvIGEgbWVtb3J5Cj4gPj4gYnVmZmVyIGluIGEgdmFyaWV0eSBvZiBmb3JtYXRzLgo+ ID4+Cj4gPj4gV2UncmUgbG9va2luZyBmb3IgZmVlZGJhY2svc3VnZ2VzdGlvbnMgb24gaG93IHRv IGV4cG9zZSB0aGlzIGluIHRoZQo+ID4+IG1hbGktZHAgRFJNIGtlcm5lbCBkcml2ZXIgLSBwb3Nz aWJseSB2aWEgVjRMMi4KPiA+Pgo+ID4+IFdlJ3ZlIGdvdCBhIGZldyB1c2UgY2FzZXMgd2hlcmUg d3JpdGViYWNrIGlzIHVzZWZ1bDoKPiA+PiAgICAtIHRlc3RpbmcsIHRvIGNoZWNrIHRoZSBkaXNw bGF5ZWQgaW1hZ2UKPiA+Cj4gPlRoaXMgbWlnaHQgb3IgbWlnaHQgbm90IG5lZWQgYSBzZXBhcmF0 ZSBpbnRlcmZhY2UuIFRoZXJlIGFyZSBlZmZvcnRzIHRvCj4gPm1ha2UgdGhlIGludGVsIGttcyB2 YWxpZGF0aW9uIHRlc3RzIGluIGktZy10IGdlbmVyaWMgKHdlbGwgdW5kZXIgd2F5Cj4gPmFscmVh ZHkpLCBhbmQgcGFydCBvZiB0aGF0IGlzIGNyZWF0aW5nIGEgZ2VuZXJpYyBpbmZyYXN0cnVjdHVy ZSB0byBjYXB0dXJlCj4gPmRpc3BsYXkgQ1JDcyBmb3IgZnVuY3Rpb25hbCB0ZXN0cyAoc3RpbGwg aW4gcHJvZ3Jlc3MpLgo+ID4KPiA+QnV0IGl0IG1pZ2h0IGJlIGJldHRlciBpZiB1c2Vyc3BhY2Ug YWJzdHJhY3RzIGJldHdlZW4gZnVsbCByZWFkYmFjayBhbmQKPiA+ZGlzcGxheSBDUkMsIGFzc3Vt aW5nIHdlIGNhbiBtYWtlIGZ1bGwgd3JpdGViYWNrIGNyb3NzLXZlbmRvciBlbm91Z2ggZm9yCj4g PnRoYXQgdXNlLWNhc2UuCj4gPgo+IAo+IEknZCBsZWFuIHRvd2FyZHMgdGhlIHVzZXJzcGFjZSBh YnN0cmFjdGlvbi4KPiBFbmN1bWJlcmluZyBhIHNpbXBsZSBDUkMgaW50ZXJmYWNlIHdpdGggYWxs IHRoZSBjb21wbGV4aXR5IG9mCj4gZnVsbC13cml0ZWJhY2sgKHNpemUsIHNjYWxpbmcsIHBpeGVs IGZvcm1hdCwgbXVsdGktcGxhbmFyIGV0Yy4pIHNvdW5kcwo+IGEgYml0IHVubmVjZXNzYXJ5Lgo+ IAo+IE9mIGNvdXJzZSwgaWYgdjRsMiBpc24ndCBnb2luZyB0byBiZSB0aGUgY3Jvc3MtdmVuZG9y IGZ1bGwtd3JpdGViYWNrCj4gaW1wbGVtZW50YXRpb24sIHRoZW4gd2UgbmVlZCB0byBiZSBhaW1p bmcgdG8gdXNlIHdoYXRldmVyIF9pc18gaW4KPiB0aGUgbWFsaS1kcCBkcml2ZXIuCj4gCj4gPj4g ICAgLSBzY3JlZW4gcmVjb3JkaW5nCj4gPj4gICAgLSB3aXJlbGVzcyBkaXNwbGF5IChlLmcuIE1p cmFjYXN0KQo+ID4+ICAgIC0gZHVhbC1kaXNwbGF5IGNsb25lIG1vZGUKPiA+PiAgICAtIG1lbW9y eS10by1tZW1vcnkgY29tcG9zaXRpb24KPiA+PiBOb3RlIHRoYXQgdGhlIEhXIGlzIGNhcGFibGUg b2Ygd3JpdGluZyBvbmUgb2YgdGhlIGlucHV0IHBsYW5lcyBpbnN0ZWFkCj4gPj4gb2YgdGhlIENS VEMgb3V0cHV0LCBidXQgd2UndmUgbm8gZ29vZCB1c2UtY2FzZSBmb3Igd2FudGluZyB0byBleHBv c2UKPiA+PiB0aGF0Lgo+ID4+Cj4gPj4gSW4gb3VyIEFuZHJvaWQgQURGIGRyaXZlclsxXSB3ZSBl eHBvc2VkIHRoZSBtZW1vcnkgd3JpdGUgZW5naW5lIGFzCj4gPj4gcGFydCBvZiB0aGUgQURGIGRl dmljZSB1c2luZyBBREYncyAiTUVNT1JZIiBpbnRlcmZhY2UgdHlwZS4gRFJNL0tNUwo+ID4+IGRv ZXNuJ3QgaGF2ZSBhbnkgc2ltaWxhciBzdXBwb3J0IGZvciBtZW1vcnkgb3V0cHV0IGZyb20gQ1JU Q3MsIGJ1dCB3ZQo+ID4+IHdhbnQgdG8gZXhwb3NlIHRoZSBmdW5jdGlvbmFsaXR5IGluIHRoZSBt YWlubGluZSBNYWxpLURQIERSTSBkcml2ZXIuCj4gPj4KPiA+PiBBIHByZXZpb3VzIGRpc2N1c3Np b24gb24gdGhlIHRvcGljIHdlbnQgdG93YXJkcyBleHBvc2luZyB0aGUKPiA+PiBtZW1vcnktd3Jp dGUgZW5naW5lIHZpYSBWNEwyWzJdLgo+ID4+Cj4gPj4gSSdtIHRoaW5raW5nIHRvIHVzZXJzcGFj ZSB0aGlzIHdvdWxkIGxvb2sgbGlrZSB0d28gZGlzdGluY3QgZGV2aWNlczoKPiA+PiAgICAtIEEg RFJNIEtNUyBkaXNwbGF5IGNvbnRyb2xsZXIuCj4gPj4gICAgLSBBIFY0TDIgdmlkZW8gc291cmNl Lgo+ID4+IFRoZXknZCBib3RoIGV4aXN0IGluIHRoZSBzYW1lIGtlcm5lbCBkcml2ZXIuCj4gPj4g QSBWNEwyIGNsaWVudCBjYW4gcXVldWUgdXAgKENBUFRVUkUpIGJ1ZmZlcnMgaW4gdGhlIG5vcm1h bCB3YXksIGFuZAo+ID4+IHRoZSBEUk0gZHJpdmVyIHdvdWxkIHNlZSBpZiB0aGVyZSdzIGEgYnVm ZmVyIHRvIGRlcXVldWUgZXZlcnkgdGltZSBhCj4gPj4gbmV3IG1vZGVzZXQgaXMgcmVjZWl2ZWQg dmlhIHRoZSBEUk0gQVBJIC0gaWYgc28sIGl0IGNhbiBjb25maWd1cmUgdGhlCj4gPj4gSFcgdG8g ZHVtcCBpbnRvIGl0IChvbmUtc2hvdCBvcGVyYXRpb24pLgo+ID4+Cj4gPj4gQW4gaW1wbGljYXRp b24gb2YgdGhpcyBpcyB0aGF0IGlmIHRoZSBzY3JlZW4gaXMgYWN0aXZlbHkgZGlzcGxheWluZyBh Cj4gPj4gc3RhdGljIHNjZW5lIGFuZCB0aGUgVjRMMiBjbGllbnQgcXVldWVzIHVwIGEgYnVmZmVy LCBpdCB3b24ndCBnZXQKPiA+PiBmaWxsZWQgdW50aWwgdGhlIERSTSBzY2VuZSBjaGFuZ2VzLiBU aGlzIHNlZW1zIGJlc3QsIG90aGVyd2lzZSB0aGUKPiA+PiBWNEwyIGRyaXZlciBoYXMgdG8gY2hh bmdlIHRoZSBIVyBjb25maWd1cmF0aW9uIG91dC1vZi1iYW5kIGZyb20gdGhlCj4gPj4gRFJNIGRl dmljZSB3aGljaCBzb3VuZHMgaG9ycmlibHkgcmFjeS4KPiA+Pgo+ID4+IE9uZSBmdXJ0aGVyIGNv bXBsaWNhdGlvbiBpcyBzY2FsaW5nLiBPdXIgSFcgaGFzIGEgc2NhbGVyIHdoaWNoIGNhbgo+ID4+ IHRhc2tlZCB3aXRoIGVpdGhlciBzY2FsaW5nIGFuIGlucHV0IHBsYW5lIG9yIHRoZSBidWZmZXIg YmVpbmcgd3JpdHRlbgo+ID4+IHRvIG1lbW9yeSwgYnV0IG5vdCBib3RoIGF0IHRoZSBzYW1lIHRp bWUuIFRoaXMgbWVhbnMgd2UgbmVlZCB0bwo+ID4+IGFyYml0cmF0ZSB0aGUgc2NhbGVyIGJldHdl ZW4gdGhlIERSTSBkZXZpY2UgKHNjYWxpbmcgaW5wdXQgcGxhbmVzKSBhbmQKPiA+PiB0aGUgVjRM MiBkZXZpY2UgKHNjYWxpbmcgb3V0cHV0IGJ1ZmZlcnMpLgo+ID4+Cj4gPj4gSSB0aGluayB0aGUg c2ltcGxlc3QgYXBwcm9hY2ggaGVyZSBpcyB0byBhbGxvdyBWNEwyIHRvICJjbGFpbSIgdGhlCj4g Pj4gc2NhbGVyIGJ5IHNldHRpbmcgdGhlIGltYWdlIHNpemUgKFZJRElPQ19TX0ZNVCkgdG8gc29t ZXRoaW5nIG90aGVyCj4gPj4gdGhhbiB0aGUgQ1JUQydzIGN1cnJlbnQgcmVzb2x1dGlvbi4gQWZ0 ZXIgdGhhdCwgYW55IGF0dGVtcHQgdG8gdXNlIHRoZQo+ID4+IHNjYWxlciBvbiBhbiBpbnB1dCBw bGFuZSB2aWEgRFJNIHNob3VsZCBmYWlsIGF0b21pY19jaGVjaygpLgo+ID4KPiA+VGhhdCdzIHBl cmZlY3RseSBmaW5lIGF0b21pY19jaGVjayBiZWhhdmlvdXIuIE9ubHkgdHJvdWJsZSBpcyB0aGF0 IHRoZSB2NGwKPiA+bG9ja2luZyBtdXN0IGludGVncmF0ZSBpbnRvIHRoZSBkcm0gbG9ja2luZywg YnV0IHRoYXQgc2hvdWxkIGJlIGRvYWJsZS4KPiA+V29yc3QgY2FzZSB5b3UgbXVzdCBzaGFkb3cg YWxsIHY0bCBsb2NrcyB3aXRoIGEgd2FpdC93b3VuZAo+ID5kcm1fbW9kZXNldF9sb2NrIHRvIGF2 b2lkIGRlYWRsb2NrcyAoc2luY2UgeW91IGNvdWxkIHRyeSB0byBncmFiIGxvY2tzCj4gPmZyb20g ZWl0aGVyIGVuZCkuCj4gPgo+IAo+IFllcywgSSBoYXZlbid0IGxvb2tlZCBhdCB0aGUgZGV0YWls cyBvZiB0aGUgbG9ja2luZyBidXQgSSdtIGhvcGluZwo+IGl0J3MgbWFuYWdlYWJsZS4KPiAKPiA+ PiBJZiB0aGUgVjRMMiBjbGllbnQgZ29lcyBhd2F5IG9yIHNldHMgdGhlIGltYWdlIHNpemUgdG8g dGhlIENSVEMncwo+ID4+IG5hdGl2ZSByZXNvbHV0aW9uLCB0aGVuIHRoZSBEUk0gZGV2aWNlIGlz IGFsbG93ZWQgdG8gdXNlIHRoZSBzY2FsZXIuCj4gPj4gSSBkb24ndCBrbm93IGlmL2hvdyB0aGUg RFJNIGRldmljZSBzaG91bGQgY29tbXVuaWNhdGUgdG8gdXNlcnNwYWNlCj4gPj4gdGhhdCB0aGUg c2NhbGVyIGlzIG9yIGlzbid0IGF2YWlsYWJsZSBmb3IgdXNlLgo+ID4+Cj4gPj4gQW55IHRob3Vn aHRzIG9uIHRoaXMgYXBwcm9hY2g/Cj4gPj4gSXMgaXQgYWNjZXB0YWJsZSB0byBib3RoIFY0TDIg YW5kIERSTSBmb2xrcz8KPiA+Cj4gPkZvciBzdHJlYW1pbmcgYSBWNEwyIGNhcHR1cmUgZGV2aWNl IHNlZW1zIGxpa2UgdGhlIHJpZ2h0IGludGVyZmFjZS4gQnV0IGlmCj4gPnlvdSB3YW50IHRvIHVz ZSB3cml0ZWJhY2sgaW4geW91ciBjb21wb3NpdG9yIHlvdSBtdXN0IGtub3cgd2hpY2ggYXRvbWlj Cj4gPmttcyB1cGRhdGUgcmVzdWx0cyBpbiB3aGljaCBmcmFtZSwgc2luY2UgaWYgeW91IGRvbid0 IHlvdSBjYW4ndCB1c2UgdGhhdAo+ID5jb21wb3NpdGVkIGJ1ZmZlciBmb3IgdGhlIG5leHQgZnJh bWUgcmVsaWFibGUuCj4gPgo+ID5Gb3IgdGhhdCBjYXNlIEkgdGhpbmsgYSBkcm0tb25seSBzb2x1 dGlvbiB3b3VsZCBiZSBiZXR0ZXIsIHRvIG1ha2Ugc3VyZQo+ID55b3UgY2FuIGRvIGFuIGF0b21p YyB1cGRhdGUgYW5kIHdyaXRlYmFjayBpbiBvbmUgc3RlcC4gdjRsIHNlZW1zIHRvIGdyb3cKPiA+ YW4gYXRvbWljIGFwaSBvZiBpdHMgb3duLCBidXQgSSBkb24ndCB0aGluayB3ZSdsbCBoYXZlIG9u ZSBzcGFubmluZwo+ID5zdWJzeXN0ZW1zIGFueXRpbWUgc29vbi4KPiA+Cj4gCj4gSSd2ZSBiZWVu IHRoaW5raW5nIGFib3V0IHRoaXMgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBhIEhXQ29tcG9z ZXIKPiBpbXBsZW1lbnRhdGlvbiBhbmQgSSB0aGluayB0aGUgaHlicmlkIERSTS1WNEwyIGRldmlj ZSB3b3VsZCB3b3JrIE9LLgo+IEhvd2V2ZXIgaXQgZGVwZW5kcyBvbiB0aGUgYmVoYXZpb3VyIEkg bWVudGlvbmVkIGFib3ZlOgo+IAo+ID4+IGlmIHRoZSBzY3JlZW4gaXMgYWN0aXZlbHkgZGlzcGxh eWluZyBhCj4gPj4gc3RhdGljIHNjZW5lIGFuZCB0aGUgVjRMMiBjbGllbnQgcXVldWVzIHVwIGEg YnVmZmVyLCBpdCB3b24ndCBnZXQKPiA+PiBmaWxsZWQgdW50aWwgdGhlIERSTSBzY2VuZSBjaGFu Z2VzLgo+IAo+IFY0TDIgYnVmZmVyIHF1ZXVlcyBhcmUgRklGTywgc28gYXMgbG9uZyBhcyB0aGUg Y29tcG9zaXRvciBxdWV1ZXMgb25seQo+IG9uZSBWNEwyIGJ1ZmZlciBwZXIgYXRvbWljIHVwZGF0 ZSwgdGhlcmUncyBubyBhbWJpZ3VpdHkuCj4gSW4gdGhlIG1vc3Qgc2ltcGxpc3RpYyBjYXNlIHRo ZSBjb21wb3NpdG9yIHdvdWxkIGFsdGVybmF0ZSBiZXR3ZWVuOgo+ICAgLSBRdWV1ZSBWNEwyIGJ1 ZmZlcgo+ICAgLSBEUk0gYXRvbWljIHVwZGF0ZQo+IC4uLiBhbmQgZGVxdWV1ZSBlaXRoZXIgaW4g dGhlIHNhbWUgdGhyZWFkIG9yIGEgZGlmZmVyZW50IG9uZS4gQXMgbG9uZwo+IGFzIHRoZSBjb21w b3NpdG9yIGtlZXBzIHRyYWNrIG9mIGhvdyBtYW55IGJ1ZmZlcnMgaXQgaGFzIHF1ZXVlZCBhbmQK PiBob3cgbWFueSBhdG9taWMgdXBkYXRlcyBpdCdzIG1hZGUsIGl0IGRvZXNuJ3QgcmVhbGx5IG1h dHRlci4KPiAKPiBXZSdkIHByb2JhYmx5IGJlIGxvb2tpbmcgdG8gYWRkIGluIFY0TDIgYXN5bmNo cm9ub3VzIGRlcXVldWUgdXNpbmcKPiBmZW5jZXMgZm9yIHN5bmNocm9uaXNhdGlvbiwgYnV0IHRo YXQncyBhIHNlcGFyYXRlIGlzc3VlLgo+IAo+ID5Gb3IgdGhlIGttcy1vbmx5IGludGVyZmFjZSB0 aGUgaWRlYSB3YXMgdG8gYWRkIGEgcHJvcGVydHkgb24gdGhlIGNydGMKPiA+d2hlcmUgeW91IGNh biBhdHRhY2ggYSB3cml0ZWJhY2sgZHJtX2ZyYW1lYnVmZmVyLiBFeHRlbmRpbmcgdGhhdCBpZGVh IHRvCj4gPnRoZSBkcm0tPnY0bCBjYXNlIHdlIGNvdWxkIGNyZWF0ZSBzcGVjaWFsIGRybV9mcmFt ZWJ1ZmZlciBvYmplY3RzCj4gPnJlcHJlc2VudGluZyBhIHY0bCBzaW5rLCBhbmQgYXR0YWNoIHRo ZW0gdG8gdGhlIHNhbWUgcHJvcGVydHkuIFRoYXQgd291bGQKPiA+YWxzbyBzb2x2ZSB0aGUgcHJv YmxlbSBvZiBnZXR0aW5nIHNvbWUgYWdyZWVtZW50IG9uIGJ1ZmZlciBtZXRhZGF0YQo+ID5iZXR3 ZWVuIHY0bCBhbmQgZHJtIHNpZGUuCj4gPgo+IAo+IEkgdGhpbmsgYSBkcm1fZnJhbWVidWZmZXIg b24gaXRzIG93biB3b3VsZG4ndCBiZSBlbm91Z2ggdG8gaGFuZGxlIG91cgo+IHNjYWxpbmcgY2Fz ZSAtIGF0IHRoYXQgcG9pbnQgaXQgc3RhcnRzIHRvIGxvb2sgbW9yZSBsaWtlIGEgcGxhbmUuCj4g SG93ZXZlciwgaWYgInNwZWNpYWwiIENSVEMgc2lua3MgYmVjYW1lIGEgdGhpbmcgaXQgY291bGQg YWxsb3cgdXMgdG8KPiBjaGFpbiBvdXIgd3JpdGViYWNrIG91dHB1dCB0byBhbm90aGVyIENSVEMn cyBpbnB1dCAodmlhIG1lbW9yeSkKPiB3aXRob3V0IGEgdHJpcCB0aHJvdWdoIHVzZXJzcGFjZSwg d2hpY2ggd291bGQgYmUgbmljZS4KCk15IHRoaW5raW5nIGhhcyBiZWVuIHRoYXQgd2UgY291bGQg cmVwcmVzZW50IHRoZSB3cml0ZWJhY2sgc2luawphcyBhIGNvbm5lY3Rvci4gQ29tYmluZSB0aGF0 IHdpdGggbXkgb3RoZXIgaWRlYSBvZiBleHBvc2luZyBhCmZpeGVkIG1vZGUgcHJvcGVydHkgZm9y IGVhY2ggY29ubmVjdG9yICh0byBtYWtlIG91dHB1dCBzY2FsaW5nCnVzZXIgY29uZmlndXJhYmxl KSwgYW5kIHdlIHNob3VsZCBlbmQgdXAgd2l0aCBhIHdheSB0byBjb250cm9sCnRoZSBzY2FsaW5n IG9mIHRoZSB3cml0ZWJhY2sgcGF0aC4KCkFsc28gaXQgd291bGQgbWVhbiB0aGVyZSdzIGFsd2F5 cyBhIGNvbm5lY3RvciBhdHRhY2hlZCB0byB0aGUKY3J0YywgZXZlbiBmb3IgdGhlIHB1cmUgd3Jp dGViYWNrIG9ubHkgY2FzZSwgd2hpY2ggSSB0aGluayBzaG91bGQKcmVzdWx0IGluIGxlc3MgcHJv YmxlbXMgaW4gZ2VuZXJhbCBhcyBJJ20gc3VyZSB0aGVyZSBhcmUgYSBsb3Qgb2YKYXNzdW1wdGlv bnMgaW4gdGhlIGNvZGUgdGhhdCB0aGVyZSBtdXN0IGJlIGF0IGxlYXN0IG9uZSBjb25uZWN0b3IK Zm9yIGFuIGFjdGl2ZSBjcnRjLgoKPiA+TGF1cmVudCBoYWQgc29tZSBwb2MgcGF0Y2hlcyBhIHdo aWxlIGFnbyBmb3IgdGhpcywgaGUncyBkZWZpbml0ZWx5IHRoZSBvbmUKPiA+dG8gcGluZy4KPiAK PiBJJ3ZlIGhhZCBhIGxpdHRsZSBsb29rIGF0OiBodHRwczovL3BhdGNod29yay5rZXJuZWwub3Jn L3BhdGNoLzYwMjY2MTEvCj4gSXQgbG9va3MgcHJldHR5IHNpbWlsYXIgdG8gd2hhdCBJIHdhcyBo b3BpbmcgdG8gZG8uCj4gCj4gV2UgaGF2ZSB0aGUgYWR2YW50YWdlIG9mIGJlaW5nIGFibGUgdG8g dXBkYXRlIHRoZSBkaXNwbGF5IHNjZW5lIGFuZAo+IHdyaXRlYmFjayBidWZmZXIgdG9nZXRoZXIg YXRvbWljYWxseSBpbiBoYXJkd2FyZSwgYW5kIHRvIHdyaXRlLWJhY2sgaW4KPiBhIG9uZS1zaG90 IG1vZGUuIFRoaXMgbGV0cyB1cyBtYWtlIHRoZSBEUk0gdXBkYXRlIHF1ZXVlIGFuZCBWNEwyCj4g YnVmZmVyIHF1ZXVlcyBhZHZhbmNlIGluIGxvY2stc3RlcC4KPiAKPiA+LURhbmllbAo+IAo+IFRo YW5rcywKPiAtQnJpYW4KPiA+Cj4gPj4KPiA+PiBUaGFua3MgZm9yIHlvdXIgdGltZSwKPiA+Pgo+ ID4+IC1Ccmlhbgo+ID4+Cj4gPj4gWzFdIGh0dHA6Ly9tYWxpZGV2ZWxvcGVyLmFybS5jb20vcmVz b3VyY2VzL2RyaXZlcnMvb3Blbi1zb3VyY2UtbWFsaS1kcC1hZGYta2VybmVsLWRldmljZS1kcml2 ZXJzLwo+ID4+IFsyXSBodHRwczovL3Blb3BsZS5mcmVlZGVza3RvcC5vcmcvfmNicmlsbC9kcmkt bG9nLz9jaGFubmVsPWRyaS1kZXZlbCZkYXRlPTIwMTYtMDUtMDQKPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4+IGRyaS1kZXZlbCBtYWlsaW5n IGxpc3QKPiA+PiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gPj4gaHR0cHM6Ly9s aXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKPiA+Cj4gPi0t IAo+ID5EYW5pZWwgVmV0dGVyCj4gPlNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlv bgo+ID5odHRwOi8vYmxvZy5mZndsbC5jaAo+ID4KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiBkcmktZGV2 ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKCi0tIApWaWxsZSBTeXJqw6Rsw6QKSW50ZWwgT1RD Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZl bCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga11.intel.com ([192.55.52.93]:37304 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932517AbcGOK5Z (ORCPT ); Fri, 15 Jul 2016 06:57:25 -0400 Date: Fri, 15 Jul 2016 13:57:15 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Brian Starkey Cc: Daniel Vetter , liviu.dudau@arm.com, laurent.pinchart@ideasonboard.com, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org Subject: Re: DRM device memory writeback (Mali-DP) Message-ID: <20160715105715.GG4329@intel.com> References: <20160714170340.GA32755@e106950-lin.cambridge.arm.com> <20160715073334.GO17101@phenom.ffwll.local> <20160715090918.GB32755@e106950-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160715090918.GB32755@e106950-lin.cambridge.arm.com> Sender: linux-media-owner@vger.kernel.org List-ID: 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. > >Laurent had some poc patches a while ago for this, he's definitely the one > >to ping. > > I've had a little look at: https://patchwork.kernel.org/patch/6026611/ > It looks pretty similar to what I was hoping to do. > > We have the advantage of being able to update the display scene and > writeback buffer together atomically in hardware, and to write-back in > a one-shot mode. This lets us make the DRM update queue and V4L2 > buffer queues advance in lock-step. > > >-Daniel > > Thanks, > -Brian > > > >> > >> Thanks for your time, > >> > >> -Brian > >> > >> [1] http://malideveloper.arm.com/resources/drivers/open-source-mali-dp-adf-kernel-device-drivers/ > >> [2] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2016-05-04 > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >-- > >Daniel Vetter > >Software Engineer, Intel Corporation > >http://blog.ffwll.ch > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC