From mboxrd@z Thu Jan 1 00:00:00 1970 From: "james qian wang (Arm Technology China)" Subject: Re: [PATCH] drm/komeda: Adds VRR support Date: Fri, 5 Jul 2019 12:33:14 +0000 Message-ID: <20190705123307.GA8435@jamwan02-TSP300> References: <1562138723-29546-1-git-send-email-lowry.li@arm.com> <20190703100149.GF15868@phenom.ffwll.local> <20190704105653.GB9747@jamwan02-TSP300> <20190704154136.gib3puo7dzivnasu@DESKTOP-E1NTVVP.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130074.outbound.protection.outlook.com [40.107.13.74]) by gabe.freedesktop.org (Postfix) with ESMTPS id D578A6E09F for ; Fri, 5 Jul 2019 12:33:18 +0000 (UTC) In-Reply-To: <20190704154136.gib3puo7dzivnasu@DESKTOP-E1NTVVP.localdomain> Content-Language: en-US Content-ID: 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: nd , Ayan Halder , "airlied@linux.ie" , Liviu Dudau , "Jonathan Chai (Arm Technology China)" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Julien Yin (Arm Technology China)" , "seanpaul@chromium.org" , "Lowry Li (Arm Technology China)" List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBKdWwgMDQsIDIwMTkgYXQgMTE6NDE6MzhQTSArMDgwMCwgQnJpYW4gU3RhcmtleSB3 cm90ZToKPiBIaSwKPiAKPiBPbiBUaHUsIEp1bCAwNCwgMjAxOSBhdCAxMTo1NzowMEFNICswMTAw LCBqYW1lcyBxaWFuIHdhbmcgKEFybSBUZWNobm9sb2d5IENoaW5hKSB3cm90ZToKPiA+IE9uIFdl ZCwgSnVsIDAzLCAyMDE5IGF0IDEyOjAxOjQ5UE0gKzAyMDAsIERhbmllbCBWZXR0ZXIgd3JvdGU6 Cj4gPiA+IAo+ID4gPiBVaCwgd2hhdCBleGFjdGx5IGFyZSB5b3UgZG9pbmcgcmVpbnZlbnRpbmcg dWFwaSBwcm9wZXJ0aWVzIHRoYXQgd2UgYWxyZWFkeQo+ID4gPiBzdGFuZGFyZGl6ZWQ/Cj4gPiA+ IAo+ID4gCj4gPiBTb3JyeSwgV2lsbCB1c2UgdGhlIG1vZGVfY29uZmlnLT5WUlJfRU5BQkxFRAo+ IAo+IExldCdzIGhhdmUgYSBjaGF0IGFib3V0IHdoYXQgeW91J3JlIHBsYW5uaW5nIGhlcmUuIFRo ZSB1cHN0cmVhbSBWUlIKPiBwcm9wZXJ0aWVzIGFyZW4ndCBhIGRpcmVjdCBtYXRjaCBmb3Igb3Vy IEhXICh3aGljaCB3ZSBkaXNjdXNzZWQKPiBiZWZvcmUpIC0gc28gZWl0aGVyIHdlIG5lZWQgdG8g aGlkZSB0aGF0IGluIHRoZSBrZXJuZWwgd2l0aCBzb21lIGZyYW1lCj4gdGltaW5nIGhldXJpc3Rp Y3MsIG9yIHdlIHNob3VsZG4ndCBleHBvc2Ugb3VyIGZlYXR1cmUgdmlhIHRoZSBleGlzdGluZwo+ IHByb3BlcnRpZXMuCgpAQnJpYW46CgoJLyoqCgkgKiBAdnJyX2VuYWJsZWQ6CgkgKgoJICogSW5k aWNhdGVzIGlmIHZhcmlhYmxlIHJlZnJlc2ggcmF0ZSBzaG91bGQgYmUgZW5hYmxlZCBmb3IgdGhl IENSVEMuCgkgKiBTdXBwb3J0IGZvciB0aGUgcmVxdWVzdGVkIHZyciBzdGF0ZSB3aWxsIGRlcGVu ZCBvbiBkcml2ZXIgYW5kCgkgKiBoYXJkd2FyZSBjYXBhYmlsdGl5IC0gbGFja2luZyBzdXBwb3J0 IGlzIG5vdCB0cmVhdGVkIGFzIGZhaWx1cmUuCgkgKi8KCWJvb2wgdnJyX2VuYWJsZWQ7CgpJdCdz IG5vdCBIVyBzcGVjaWZpYyBmbGFnIChsaWtlIEFNRCBmcmVlc3luYyksIEkgdGhpbmsgY2FuIHVz ZSB0aGlzIHN0YW5kYXJkCmZsYWcuIAoKPiBJTU8sIGl0J3MgYmV0dGVyIGZvciBLb21lZGEgdG8g anVzdCBhbGxvdyBzZXR0aW5nIGEgbmV3IENSVEMgbW9kZSB0bwo+IG9uZSB3aXRoIGEgZGlmZmVy ZW50IFZGUCAoYnV0IGV2ZXJ5dGhpbmcgZWxzZSB0aGUgc2FtZSkgd2l0aG91dCBhIGZ1bGwKPiBt b2Rlc2V0Lgo+IAo+IFlvdSBjb3VsZCB0cnkgYW5kIGltcGxlbWVudCB0aGUgdXBzdHJlYW0gVlJS IHByb3BlcnRpZXMgdG9vIC0gYnV0IHlvdQo+IGNhbiBnZXQgdGhlIGZ1bmN0aW9uYWxpdHkgYWRk ZWQgYnkgdGhpcyBwYXRjaCB3aXRob3V0IGNoYW5naW5nIGFueQo+IFVBUEkuCj4gCj4gKE5vdGUg dGhlIG9ubHkgcmVhc29uIHdlIGV2ZXIgYWRkZWQgdGhlIGlkZWEgb2YgcGFzc2luZyBpbiBWRlAg YnkKPiBpdHNlbGYgaXMgYmVjYXVzZSBpbiBBREYsIG1vZGVzZXQgd2FzIGEgc2VwYXJhdGUgaW9j dGwgZW50aXJlbHksIHNvIHdlCj4gY291bGRuJ3QgZG8gaXQgYXRvbWljYWxseSkKClllcywgd2Ug Y2FuLgpCdXQgRFJNLUtNUyAodGhlIGhlbHBlcnMpIGRlZmF1bHQgZG9lc24ndCBzdXBwb3J0IHN1 Y2ggbGlnaHQgbW9kZS1zZXQuCndlIGNhbiBub3QgcmVseSBvbiB0aGUgaGVscGVycywgYnV0IG5l ZWQgdG8gaW1wbGVtZW50IGJ5IG91cnNlbHZlcy4KSXMgaXQgd29ydGggdG8gZG8gaXQ/CgpNeSBw bGFuIGlzOgoKRmlyc3Q6CkkgdGhpbmsgdGhlIGtleSBwcm9ibGVtIGhlcmUgaXMgbm90IGhvdyB0 byBlbmFibGUgVlJSIGZvciBvdXIgZGlzcGxheSwKYnV0IGhvdyB0byBwYXNzIHRoZSBWUlIgY2Fw cyBmcm9tIHRoZSBjb25uZWN0b3IgdG8gb3VyIGRpc3BsYXkuCgpBbmQgaXQncyBub3Qgb25seSB0 aGUgVlJSIHByYmxlbSBidXQgbGlrZSB0aGUgY29tbWFuZF9tb2RlL2R1YWwtbGluawphbGwgdGhl IG5vbmUgc3RhbmRhcmQgY29ubmVjdG9yIGZlYXR1cmVzIHRoYXQgbmVlZGVkIGJ5IG91ciBIVy4K ClVubGlrZSB0aGUgaW50ZWwvYW1kL05WIG1vc3RseSB0aGV5IGhhdmUgdGhlaXIgb3duIHRyYW5z bWl0dGVyIEhXCihhbmQgY29ubmVjdG9yIGRyaXZlciksIFNvIHRoZXkgY2FuIGVhc2lseSBwYXNz IHRoZSBpbmZvIGJldHdlZW4KY29ubmVjdG9yIGFuZCBkaXNwbGF5LgoKQnV0IGZvciB1cyB0aGF0 J3MgdGhlIHRoaXJkIHBhcnQsIGFuZCB3ZSBjYW4gbm90IGRvIGFueSBhc3N1bXB0aW9uIHRvCnRo ZW0sIGFuZCBmb3IgdXMgdGhleSBhcmUgdGhlIGRybV9jb25uZWN0b3IsIGJ1dCB3ZSBjYW4gbm90 IGdvdCB0aGVzZQppbmZvcyB2aWEgYSBkcm1fY29ubmVjdG9yLgoKU28gSSB0aGluayB3ZSBuZWVk IGEgc3RhbmRhcmQgd2F5IHRvIHBhc3MgdGhlc2UgcHJpdmF0ZSBpbmZvcy4KCkkgcGxhbiB0byBh ZGQgYSBuZXcgcXVlcnkgZnVuY3Rpb24gdG8gZHJtX2JyaWRnZSBsaWtlCgogICgqcXVlcnkpKHU2 NCBxdWVyeV9pZCwgeHh4LXR5cGUgcmV0dXJuX3ZhKTsKCmFuZCBxdWVyeV9pZCBpcyBsaWtlIHRo ZSBtb2RpZmllcnM6IGZpcnN0IDhiaXQgaXMgdmVuZG9yX2lkLgoKd2hlbiB0aGUgdGhpcmQgcGFy dCBjb25uZWN0b3IgaW50ZWdyYXRzIHRvIG91ciBkaXNwbGF5LCBpZiB0aGUKdHJhbnNtaXR0ZXIg SFcgc3VwcG9ydCB0aGUgZmVhdHVyZXMgdGhhdCBvdXIgZGlzcGxheSBuZWVkZWQsIHRoZXkKY2Fu IHN1cHBseSB0aGlzIHF1ZXJ5IGZ1bmN0aW9uIHRvIG5vdGlmeSB0aGUgY2FwcyBzdXBwb3J0IHRv IHVzLgpJZiB0aGUgY29ubmVjdG9yIGRvZXNuJ3QgaGF2ZSB0aGlzIHF1ZXJ5LCBvciBxdWVyeSBm YWlsIHdlIHRyZWF0CnRoZSBmZWF0dXJlIGlzIG5vdCBzdXBwb3J0IGJ5IHRoaXMgY29ubmVjdG9y LgoKQW5kIEZvciB0aGlzIFZSUi4KClVzZXIgb25seSBuZWVkIHRvIEVuL0RpcyBWUlIsIE9uY2Ug a29tZWRhIHJlY2VpdmVkIEVuYWJsZSBjb21tYW5kCi0gcXVlcnkgdGhlIGNvbm5lY3RvciBmb3Ig VkZQIHJhbmdlCiAgMS4gY29ubmVjdG9yIGRvZXNuJ3Qgc3VwcG9ydCBWUlIsICBpZ25vcmUgb3Ig cmV0dXJuIGVycm9yID8uCiAgMi4gZ290IHRoZSBWRlAgcmFuZ2UsIGNvbmZpZ3VyZSB0aGUgZGlz cGxheSBhY2NvcmRpbmcgdGhlIHJhbmdlLgoKT25jZSB0aGUgZGlzYWJsZSByZWNlaXZlZCwgcmVz dG9yZSB0aGUgbW9kZSB2ZnAuCgpUaGFua3MKSmFtZXMKCj4gPiAKPiA+IHdlIHVzZSB0aGlzIHBy aXZhdGUgcHJvcGVydHkgYmVjYXVzZSB3ZSdyZSBzd2l0Y2hpbmcgdG8gaW4tdHJlZSwgYmVmb3Jl Cj4gPiBmaW5pc2ggdGhlIHN3aXRjaCwgd2Ugc3RpbGwgbmVlZCB0byBtYWludGFpbiBvdXIgb3V0 LW9mLXRyZWUgZHJpdmVyIHdoaWNoCj4gPiBkZXBlbmQgb24gYSBvbGRlciBhbmQgZG9lc24ndCBo YXZlIHRoZSBWUlJfRU5BQkxFRCBwcm9wZXJ0eS4gZm9yIGF2b2lkCj4gPiBkaXZlcmdpbmcgdGhl IHR3byBicmFuY2guIG15IG9sZCBwbGFuIGlzIGZpcnN0IHN3aXRjaCB0byBpbi10cmVlLCB0aGVu IGRyb3AKPiA+IHRoZSBvdXQtb2YtdHJlZSBkcml2ZXIgYW5kIHRoZW4gdW5pZnkgdGhlIHVzYWdl Lgo+ID4gCj4gPiA+ID4gKwlpZiAoIXByb3ApCj4gPiA+ID4gKwkJcmV0dXJuIC1FTk9NRU07Cj4g PiA+ID4gKwo+ID4gPiA+ICsJZHJtX29iamVjdF9hdHRhY2hfcHJvcGVydHkoJmNydGMtPmJhc2Us IHByb3AsIDApOwo+ID4gPiA+ICsJa2NydGMtPnZycl9lbmFibGVfcHJvcGVydHkgPSBwcm9wOwo+ ID4gPiA+ICsKPiA+ID4gPiArCXJldHVybiAwOwo+ID4gPiA+ICt9Cj4gPiA+ID4gKwo+ID4gPiA+ ICBzdGF0aWMgc3RydWN0IGRybV9wbGFuZSAqCj4gPiA+ID4gIGdldF9jcnRjX3ByaW1hcnkoc3Ry dWN0IGtvbWVkYV9rbXNfZGV2ICprbXMsIHN0cnVjdCBrb21lZGFfY3J0YyAqY3J0YykKPiA+ID4g PiAgewo+ID4gPiA+IEBAIC02NTksNiArNzE3LDEwIEBAIHN0YXRpYyBpbnQga29tZWRhX2NydGNf YWRkKHN0cnVjdCBrb21lZGFfa21zX2RldiAqa21zLAo+ID4gPiA+ICAJaWYgKGVycikKPiA+ID4g PiAgCQlyZXR1cm4gZXJyOwo+ID4gPiA+ICAKPiA+ID4gPiArCWVyciA9IGtvbWVkYV9jcnRjX2Ny ZWF0ZV92cnJfcHJvcGVydHkoa2NydGMpOwo+ID4gPiA+ICsJaWYgKGVycikKPiA+ID4gPiArCQly ZXR1cm4gZXJyOwo+ID4gPiA+ICsKPiA+ID4gPiAgCXJldHVybiBlcnI7Cj4gPiA+ID4gIH0KPiA+ ID4gPiAgCj4gPiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1L2RybS9hcm0vZGlzcGxheS9r b21lZGEva29tZWRhX2ttcy5oIGIvZHJpdmVycy9ncHUvZHJtL2FybS9kaXNwbGF5L2tvbWVkYS9r b21lZGFfa21zLmgKPiA+ID4gPiBpbmRleCBkYzFkNDM2Li5kMGNmODM4IDEwMDY0NAo+ID4gPiA+ IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9hcm0vZGlzcGxheS9rb21lZGEva29tZWRhX2ttcy5oCj4g PiA+ID4gKysrIGIvZHJpdmVycy9ncHUvZHJtL2FybS9kaXNwbGF5L2tvbWVkYS9rb21lZGFfa21z LmgKPiA+ID4gPiBAQCAtOTgsNiArOTgsMTIgQEAgc3RydWN0IGtvbWVkYV9jcnRjIHsKPiA+ID4g PiAgCj4gPiA+ID4gIAkvKiogQHNsYXZlX3BsYW5lc19wcm9wZXJ0eTogcHJvcGVydHkgZm9yIHNs YXZlcyBvZiB0aGUgcGxhbmVzICovCj4gPiA+ID4gIAlzdHJ1Y3QgZHJtX3Byb3BlcnR5ICpzbGF2 ZV9wbGFuZXNfcHJvcGVydHk7Cj4gPiA+IAo+ID4gPiBBbmQgdGhpcyBzZWVtcyB0byBub3QgYmUg dGhlIGZpcnN0IHRpbWUgdGhpcyBoYXBwZW5lZC4gTG9va2luZyBhdCBrb21lZGEKPiA+ID4gd2l0 aCBhIHF1aWNrIGdpdCBncmVwIG9uIHByb3BlcnRpZXMgeW91J3ZlIGFjdHVhbGx5IGFjY3VtdWxh dGVkIHF1aXRlIGEKPiA+ID4gcGlsZSBvZiBzdWNoIGRyaXZlciBwcm9wZXJ0aWVzIGFscmVhZHku IFdoZXJlJ3MgdGhlIHVzZXJzcGFjZSBmb3IgdGhpcz8KPiA+ID4gV2hlcmUncyB0aGUgdWFwaSBk aXNjdXNzaW9ucyBmb3IgdGhpcyBzdHVmZj8gV2hlcmUncyB0aGUgaWd0IHRlc3RzIGZvcgo+ID4g PiB0aGlzICh5ZXMgYSBidW5jaCBhcmUgYWZ0ZXIgd2UgYWdyZWVkIHRvIGhhdmUgdGVzdGNhc2Vz IGZvciB0aGlzKS4KPiA+ID4gCj4gPiA+IEkga25vdyB0aGF0IGluIHRoZSBwYXN0IHdlJ3ZlIGJl ZW4gc29tZXdoYXQgc2xvcHB5IHByb3BlcnRpZXMsIGJ1dCB0aGF0Cj4gPiA+IHdhcyBhIG1pc3Rh a2UgYW5kIHdlJ3ZlIGNyYW5rZWQgZG93biBvbiB0aGlzIGhhcmQuIFByb2JhYmx5IG5lZWQgdG8g Zml4Cj4gPiA+IHRoaXMgd2l0aCBhIHBpbGUgb2YgcmV2ZXJ0cyBhbmQgc3RhcnQgb3Zlci4KPiA+ ID4gLURhbmllbAo+ID4gCj4gPiBTb3JyeSBhZ2Fpbi4KPiA+IAo+ID4gRmlyc3QgSSdsbCBzZW5k IHNvbWUgcGF0Y2hlcyB0byByZW1vdmUgdGhlc2UgcHJpdmF0ZSBwcm9wZXJ0aWVzLgo+ID4gCj4g PiBhbmQgdGhlbiBkaXNjdXNzIGZvciBob3cgdG8gaW1wZWxlbWVudCB0aGVtLgo+ID4gCj4gPiBU aGUgY3VycmVudCBrb21lZGEgcHJpdmF0ZXMgYXJlOgo+ID4gCj4gPiBjcnRjOgo+ID4gICAgY2xv Y2tfcmF0aW8KPiA+ICAgIHNsYXZlX3BsYW5lcwo+ID4gCj4gPiBwbGFuZToKPiA+ICAgIGltZ19l bmhhbmNlbWVudAo+ID4gICAgbGF5ZXJfc3BsaXQKPiA+IAo+ID4gTGF5ZXJfc3BsaXQ6IGl0IGNh biBiZSBkZWxldGVkIGFuZCBjb21wdXRlZCBpbiBrZXJuZWwuCj4gPiAKPiA+IGltZ19lbmhhbmNl bWVudDoKPiA+ICAgaXQgaXMgZm9yIGltYWdlIGVuaGFuY2VtZW50LCBjYW4gYmUgcmVtb3ZlZCBh bmQgY29tcHV0ZWQgaW4ga2VybmVsLgo+ID4gICBidXQgSSdkIGxpa2UgdG8gaGF2ZSBpdCwgc2lu Y2UgaXQncyBhIHNlcGVyYXRlZCBmdW5jdGlvbiAoTk9UIG9ubHkKPiA+ICAgZm9yIHNjYWxpbmcg b3IgWVVWIGZvcm1hdCksIEkgdGhpbmsgb25seSB1c2VyIGNhbiByZWFsIGtub3cgaWYgbmVlZAo+ ID4gICB0byBlbmFibGUgaXQuCj4gPiAKPiA+IAo+ID4gaW1nX2VuaGFuY2VtZW50Ogo+ID4gICBp dCBpcyBmb3IgaW1hZ2UgZW5oYW5jZW1lbnQsIGNhbiBiZSByZW1vdmVkIGFuZCBjb21wdXRlZCBp biBrZXJuZWwuCj4gPiAgIGJ1dCBJJ2QgbGlrZSB0byBoYXZlIGl0LCBzaW5jZSBpdCdzIGEgc2Vw ZXJhdGVkIGZ1bmN0aW9uIChOT1Qgb25seQo+ID4gICBmb3Igc2NhbGluZyBvciBZVVYgZm9ybWF0 KSwgSSB0aGluayBvbmx5IHVzZXIgY2FuIHJlYWwga25vdyBpZiBuZWVkCj4gPiAgIHRvIGVuYWJs ZSBpdC4KPiA+ICAgSSB0aGluayBtYXliZSB3ZSBjYW4gYWRkIGl0IENPUkUgYXMgYW4gb3B0aW9u YWwgZHJtX3BsYW5lIHByb3BlcnR5Lgo+IAo+IEkgcmVhbGx5IGRvbid0IHRoaW5rIHdlIHNob3Vs ZCBiZSBleHBvc2luZyB0aGlzLiBJdCdzIHB1cmVseSB0aGVyZSB0bwo+IGhlbHAgaW1wcm92ZSBh biBpbWFnZSBhZnRlciBzY2FsaW5nIChlZmZlY3RpdmVseSwgc2hhcnBlbmluZykuIEl0J3MKPiBu b3QgYSBnZW5lcmFsIHB1cnBvc2UgImltYWdlIGVuaGFuY2VyIi4gRXhwb3NpbmcgYSBwcm9wZXJ0 eSB3aGljaCBzYXlzCj4gImltYWdlIGVuaGFuY2VtZW50IiBpc24ndCB1c2VmdWwgdG8gYW55IGFw cGxpY2F0aW9uIC0gd2hhdCBraW5kIG9mCj4gZW5oYW5jZW1lbnQgaXMgaXQgZG9pbmc/Cj4gCj4g PiAKPiA+IGNsb2NrX3JhdGlvOgo+ID4gICBJdCdzIHRoZSBjbG9jayByYXRpbyBvZiAobWFpbiBl bmdpbmUgbG9jay9vdXRwdXQgcGl4ZWwgY2xrKSBmb3IKPiA+ICAga29tZWRhIEhXJ3MgZG93bnNj YWxpbmcgcmVzdHJpY3Rpb24sIGFzIGJlbG93Ogo+ID4gCj4gPiAgIEQ3MSBkb3duc2NhbGluZyBt dXN0IHNhdGlzZnkgdGhlIGZvbGxvd2luZyBlcXVhdGlvbgo+ID4gCj4gPiAgIE1DTEsgICAgICAg ICAgICAgICAgICAgaF9pbiAqIHZfaW4KPiA+ICAtLS0tLS0tID49IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ID4gIFBYTENMSyAgICAgKGhfdG90YWwgLSAo MSArIDIgKiB2X2luIC8gdl9vdXQpKSAqIHZfb3V0Cj4gPiAKPiA+ICBJbiBvbmx5IGhvcml6b250 YWwgZG93bnNjYWxpbmcgc2l0dWF0aW9uLCB0aGUgcmlnaHQgc2lkZSBzaG91bGQgYmUKPiA+ICBt dWx0aXBsaWVkIGJ5IChoX3RvdGFsIC0gMykgLyAoaF9hY3RpdmUgLSAzKSwgdGhlbiBlcXVhdGlv biBiZWNvbWVzCj4gPiAKPiA+ICAgTUNMSyAgICAgICAgICBoX2luCj4gPiAgLS0tLS0tLSA+PSAt LS0tLS0tLS0tLS0tLS0tCj4gPiAgIFBYTENMSyAgICAgKGhfYWN0aXZlIC0gMykKPiA+IAo+ID4g c2xhdmVfcGxhbmVzOgo+ID4gICBpdCdzIG5vdCBvbmx5IGZvciB0aGUgenBvcywgYnV0IG1vc3Qg aW1wb3J0YW50bHkgZm9yIG5vdGlmeSB0aGUgdXNlcgo+ID4gICB0byBncm91cCB0aGUgcGxhbmVz IHRvIHR3byByZXNvdXJjZSBzZXRzIChwaXBlbGluZS0wIHJlc291cmNlcyBhbmQgcGlwZWxpbmUx KS4KPiA+ICAgUGVyIG91ciBIVyBkZXNpZ24gdGhlIHR3byBwaXBlbGluZXMgY2FuIGJlIGR5bmFt aWMgYXNzaWduZWQgdG8gQ1JUQwo+ID4gICBhY2NvcmRpbmcgdG8gdGhlIHVzYWdlLgo+ID4gICAt IGxpa2UgdXNlciBvbmx5IGVuYWJsZSBvbmUgQ1JUQyB3aGljaCBjYW4gdXNlIGFsbCB0d28gcGlw ZWxpbmVzCj4gPiAgICAgKHR3byByZXNvdXJjZSByZXNvdXJjZSBzZXRzKQo+ID4gICAtIGJ1dCBp ZiBlbmFibGVkIHR3byBDUlRDcywgb25seSBvbmUgcmVzb3VyY2Ugc2V0IGF2YWlsYWJsZSBmb3IK PiA+ICAgICBlYWNoIENSVEMuCj4gPiAKPiA+IGtvbWVkYSB1c2VyIG5lZWQgdG8ga25vd24gdGhl IGNsb2NrX3JhdGlvIGFuZCBzbGF2ZV9wbGFuZXMsIGJ1dCBob3cKPiA+IHRvIGV4cG9zZSB0aGVt OiBwcml2YXRlX3Byb3BlcnR5LCBzeXNmcyBvciBvdGhlciB3YXlzLCBzZWVtcyB3ZSBuZWVkCj4g PiB0byBkaXNzY3Vzcy4gOikKPiAKPiBARGFuaWVsLAo+IAo+IFRoZXNlIHR3byBhcmUgYSBzeW1w dG9tIG9mIGEgZnVuZGFtZW50YWwgaW1wZWRhbmNlIG1pc21hdGNoIGJldHdlZW4KPiBob3cgS01T IHdvcmtzIGFuZCBhY3R1YWxseSBtYWtpbmcgb3B0aW1hbCB1c2Ugb2YgSFcgKG9yOiBob3cgQW5k cm9pZAo+IHdvcmtzKS4KPiAKPiBIV0NvbXBvc2VyIGlzIGV4cGVjdGVkIHRvIGhhdmUgZ29vZCBr bm93bGVkZ2Ugb2YgaG93IHRoZSB1bmRlcmx5aW5nIEhXCj4gb3BlcmF0ZXMsIHNvIHRoYXQgaXQg Y2FuIGVmZmVjdGl2ZWx5IHNjaGVkdWxlIGEgc2NlbmUuICJURVNUX09OTFkgdGlsCj4gaXQgd29y a3MiIGlzbid0IGEgdmlhYmxlIHN0cmF0ZWd5LCBhbmQgaXQgYWJzb2x1dGVseSBzaG91bGRuJ3Qg YmUKPiBuZWVkZWQgZm9yIGEgcGllY2Ugb2YgY29kZSB3aGljaCBoYXMgYmVlbiB3cml0dGVuIF9z cGVjaWZpY2FsbHlfIHRvCj4gZHJpdmUga29tZWRhLgo+IAo+IEl0J3MgYWNrbm93bGVkZ2VkIHRo YXQgSFctc3BlY2lmaWMgcGxhbm5lcnMgbWF5IGJlIG5lZWRlZCBldmVuIGluCj4gZHJtLWh3Y29t cG9zZXIsIGFuZCB0aG9zZSBwbGFubmVycyBhcmUgZ29pbmcgdG8gbmVlZCB0byBnZXQgdG9sZCBz b21lCj4gc3R1ZmYgYWJvdXQgdGhlIEhXLiBXaGV0aGVyIHRoYXQgaW5mbyBzaG91bGQgZ28gdGhy b3VnaCBhdG9taWMKPiBwcm9wZXJ0aWVzIG9yIG5vdCBpcyB1cCBmb3IgZGViYXRlIChhZGRpbmcg cHJvcGVydGllcyB3aXRob3V0Cj4gZm9sbG93aW5nIHRoZSBydWxlcyBub3R3aXRoc3RhbmRpbmcp Lgo+IAo+IFdoYXQncyBjZXJ0YWluIGlzIHRoYXQgZGVidWdmcyBpcyBub3Qgd29ya2FibGUsIGJl Y2F1c2UgaXQncyBub3QKPiBhdmFpbGFibGUgaW4gYSBwcm9kdWN0aW9uIEFuZHJvaWQgZGV2aWNl IChub3Igc2hvdWxkIGl0IGJlKS4KPiAKPiBBbmQgb2YgY291cnNlLCB0aGVyZSdzIHJvb20gZm9y IG1ha2luZyB0aGUgaW5mb3JtYXRpb24gbW9yZSBnZW5lcmljIGFzCj4gZmFyIGFzIHBvc3NpYmxl LCBhdCB3aGljaCBwb2ludCB0aGV5IG1pZ2h0IGJlIGJldHRlciBjYW5kaWRhdGVzIGZvcgo+IERS TSBVQVBJLgo+IAo+IFRoYW5rcywKPiAtQnJpYW4KPiAKPiA+IAo+ID4gVGhhbmtzCj4gPiBKYW1l cwo+ID4gCj4gPiA+ID4gKwo+ID4gPiA+ICsJLyoqIEB2cnJfcHJvcGVydHk6IHByb3BlcnR5IGZv ciB2YXJpYWJsZSByZWZyZXNoIHJhdGUgKi8KPiA+ID4gPiArCXN0cnVjdCBkcm1fcHJvcGVydHkg KnZycl9wcm9wZXJ0eTsKPiA+ID4gPiArCj4gPiA+ID4gKwkvKiogQHZycl9lbmFibGVfcHJvcGVy dHk6IHByb3BlcnR5IGZvciBlbmFibGUvZGlzYWJsZSB0aGUgdnJyICovCj4gPiA+ID4gKwlzdHJ1 Y3QgZHJtX3Byb3BlcnR5ICp2cnJfZW5hYmxlX3Byb3BlcnR5Owo+ID4gPiA+ICB9Owo+ID4gPiA+ ICAKPiA+ID4gPiAgLyoqCj4gPiA+ID4gQEAgLTEyNiw2ICsxMzIsMTIgQEAgc3RydWN0IGtvbWVk YV9jcnRjX3N0YXRlIHsKPiA+ID4gPiAgCj4gPiA+ID4gIAkvKiogQG1heF9zbGF2ZV96b3JkZXI6 IHRoZSBtYXhpbXVtIG9mIHNsYXZlIHpvcmRlciAqLwo+ID4gPiA+ICAJdTMyIG1heF9zbGF2ZV96 b3JkZXI7Cj4gPiA+ID4gKwo+ID4gPiA+ICsJLyoqIEB2ZnA6IHRoZSB2YWx1ZSBvZiB2ZXJ0aWNh bCBmcm9udCBwb3JjaCAqLwo+ID4gPiA+ICsJdTMyIHZmcDsKPiA+ID4gPiArCj4gPiA+ID4gKwkv KiogQGVuX3ZycjogZW5hYmxlIHN0YXR1cyBvZiB2YXJpYWJsZSByZWZyZXNoIHJhdGUgKi8KPiA+ ID4gPiArCXU4IGVuX3ZyciA6IDE7Cj4gPiA+ID4gIH07Cj4gPiA+ID4gIAo+ID4gPiA+ICAvKiog c3RydWN0IGtvbWVkYV9rbXNfZGV2IC0gZm9yIGdhdGhlciBLTVMgcmVsYXRlZCB0aGluZ3MgKi8K PiA+ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL2FybS9kaXNwbGF5L2tvbWVkYS9r b21lZGFfcGlwZWxpbmUuaCBiL2RyaXZlcnMvZ3B1L2RybS9hcm0vZGlzcGxheS9rb21lZGEva29t ZWRhX3BpcGVsaW5lLmgKPiA+ID4gPiBpbmRleCAwMGU4MDgzLi42NmQ3NjY0IDEwMDY0NAo+ID4g PiA+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9hcm0vZGlzcGxheS9rb21lZGEva29tZWRhX3BpcGVs aW5lLmgKPiA+ID4gPiArKysgYi9kcml2ZXJzL2dwdS9kcm0vYXJtL2Rpc3BsYXkva29tZWRhL2tv bWVkYV9waXBlbGluZS5oCj4gPiA+ID4gQEAgLTMzNiw3ICszMzYsOSBAQCBzdHJ1Y3Qga29tZWRh X2ltcHJvY19zdGF0ZSB7Cj4gPiA+ID4gIC8qIGRpc3BsYXkgdGltaW5nIGNvbnRyb2xsZXIgKi8K PiA+ID4gPiAgc3RydWN0IGtvbWVkYV90aW1pbmdfY3RybHIgewo+ID4gPiA+ICAJc3RydWN0IGtv bWVkYV9jb21wb25lbnQgYmFzZTsKPiA+ID4gPiAtCXU4IHN1cHBvcnRzX2R1YWxfbGluayA6IDE7 Cj4gPiA+ID4gKwl1OCBzdXBwb3J0c19kdWFsX2xpbmsgOiAxLAo+ID4gPiA+ICsJICAgc3VwcG9y dHNfdnJyIDogMTsKPiA+ID4gPiArCXN0cnVjdCBtYWxpZHBfcmFuZ2UgdmZwX3JhbmdlOwo+ID4g PiA+ICB9Owo+ID4gPiA+ICAKPiA+ID4gPiAgc3RydWN0IGtvbWVkYV90aW1pbmdfY3RybHJfc3Rh dGUgewo+ID4gPiA+IC0tIAo+ID4gPiA+IDEuOS4xCj4gPiA+ID4gCj4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+ID4gPiBkcmktZGV2ZWwg bWFpbGluZyBsaXN0Cj4gPiA+ID4gZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwo+ID4g PiA+IGh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRl dmVsCj4gPiA+IAo+ID4gPiAtLSAKPiA+ID4gRGFuaWVsIFZldHRlcgo+ID4gPiBTb2Z0d2FyZSBF bmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KPiA+ID4gaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1h aWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMu ZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A17C1C46499 for ; Fri, 5 Jul 2019 12:36:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E5A421850 for ; Fri, 5 Jul 2019 12:36:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.i=@armh.onmicrosoft.com header.b="PK6Wbnya" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728544AbfGEMgA (ORCPT ); Fri, 5 Jul 2019 08:36:00 -0400 Received: from mail-eopbgr00041.outbound.protection.outlook.com ([40.107.0.41]:24197 "EHLO EUR02-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725601AbfGEMf7 (ORCPT ); Fri, 5 Jul 2019 08:35:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6RAVUZ4WKn2hUTgwR8RKmPNXNviViUuEXwO7+nrBzgk=; b=PK6WbnyarGQpC3QqEopj9rTjZzIKTRyfKXBn2gs6UTfpcCC4rS1yks2gad79nhqoTBSSvbGi2LoYgHbc1c0QzavYc747X7W31O3elBDOxjri4H7s8pR0CVHXOa0vm7mgnIkuE/BOWvjU4UGge9vjE5LUm4f+axAhmzOtyHbP/c4= Received: from VE1PR08MB5006.eurprd08.prod.outlook.com (10.255.159.31) by VE1PR08MB5086.eurprd08.prod.outlook.com (20.179.29.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 5 Jul 2019 12:33:15 +0000 Received: from VE1PR08MB5006.eurprd08.prod.outlook.com ([fe80::4062:a380:35ba:11d1]) by VE1PR08MB5006.eurprd08.prod.outlook.com ([fe80::4062:a380:35ba:11d1%3]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 12:33:15 +0000 From: "james qian wang (Arm Technology China)" To: Brian Starkey CC: "Lowry Li (Arm Technology China)" , Liviu Dudau , "maarten.lankhorst@linux.intel.com" , "seanpaul@chromium.org" , "airlied@linux.ie" , Ayan Halder , "Jonathan Chai (Arm Technology China)" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Julien Yin (Arm Technology China)" , nd Subject: Re: [PATCH] drm/komeda: Adds VRR support Thread-Topic: [PATCH] drm/komeda: Adds VRR support Thread-Index: AQHVMXCZgYg0h2S+S0iZ8YXT6sjbY6a4qceAgAGhuICAAE+MAIABXayA Date: Fri, 5 Jul 2019 12:33:14 +0000 Message-ID: <20190705123307.GA8435@jamwan02-TSP300> References: <1562138723-29546-1-git-send-email-lowry.li@arm.com> <20190703100149.GF15868@phenom.ffwll.local> <20190704105653.GB9747@jamwan02-TSP300> <20190704154136.gib3puo7dzivnasu@DESKTOP-E1NTVVP.localdomain> In-Reply-To: <20190704154136.gib3puo7dzivnasu@DESKTOP-E1NTVVP.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mutt/1.10.1 (2018-07-13) x-originating-ip: [113.29.88.7] x-clientproxiedby: HK2PR04CA0055.apcprd04.prod.outlook.com (2603:1096:202:14::23) To VE1PR08MB5006.eurprd08.prod.outlook.com (2603:10a6:803:113::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=james.qian.wang@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 337cef65-f3c4-4e34-e3f2-08d70144f2f7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020);SRVR:VE1PR08MB5086; x-ms-traffictypediagnostic: VE1PR08MB5086: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: nodisclaimer: True x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(7916004)(39860400002)(376002)(346002)(366004)(136003)(396003)(199004)(189003)(33656002)(486006)(25786009)(6862004)(4326008)(5660300002)(14454004)(2906002)(99286004)(478600001)(6116002)(3846002)(52116002)(68736007)(66066001)(66446008)(66946007)(66476007)(64756008)(66556008)(6636002)(73956011)(54906003)(58126008)(316002)(33716001)(256004)(14444005)(5024004)(6512007)(8936002)(86362001)(6306002)(9686003)(186003)(53936002)(6486002)(26005)(71190400001)(71200400001)(229853002)(8676002)(81166006)(81156014)(446003)(55236004)(386003)(6506007)(102836004)(11346002)(476003)(6436002)(1076003)(7736002)(30864003)(76176011)(966005)(6246003)(305945005)(21314003);DIR:OUT;SFP:1101;SCL:1;SRVR:VE1PR08MB5086;H:VE1PR08MB5006.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4Se0OvP2t7zMnA1l1vmA+0piqUBddeSrU0QXhU3Iuzl8VUn/3yQnRl9TkdMFYoimop27Km4Ru9+Fi+992VRTMi1mnNGIlfO1S/ZsedBQNyFRUh3tbVMWFmZsyheRyDQwKW26fpCHkgq6rV3BsBFg5lZJ31uiTy1cjBlB5Dv/67Sl5j5hZIGEj/Bn3tgq2DRJJ8Pko1CJYi02bI2AwNLg3ZB7B9+UuCANC85uSzLzTEMeMGrY1Os3Ubgi4G07rZSB0LZhMckV2UczK4ABR2NK56vr2eYMOQk9QPKnym4fHv/ELCwThNpcipGw/2zK4vW2NkM8HgTHJHtVDDw0iL6UNod0XxVilR5QO6jIdBlhgC3+SyCommSTVY2NKRXfrevlqR+wujtcU/cbFuhTCJYjARMPQxRVBr9Oa5VIGcGB0e8= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 337cef65-f3c4-4e34-e3f2-08d70144f2f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 12:33:14.7877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: james.qian.wang@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5086 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 04, 2019 at 11:41:38PM +0800, Brian Starkey wrote: > Hi, >=20 > On Thu, Jul 04, 2019 at 11:57:00AM +0100, james qian wang (Arm Technology= China) wrote: > > On Wed, Jul 03, 2019 at 12:01:49PM +0200, Daniel Vetter wrote: > > >=20 > > > Uh, what exactly are you doing reinventing uapi properties that we al= ready > > > standardized? > > >=20 > >=20 > > Sorry, Will use the mode_config->VRR_ENABLED >=20 > Let's have a chat about what you're planning here. The upstream VRR > properties aren't a direct match for our HW (which we discussed > before) - so either we need to hide that in the kernel with some frame > timing heuristics, or we shouldn't expose our feature via the existing > properties. @Brian: /** * @vrr_enabled: * * Indicates if variable refresh rate should be enabled for the CRTC. * Support for the requested vrr state will depend on driver and * hardware capabiltiy - lacking support is not treated as failure. */ bool vrr_enabled; It's not HW specific flag (like AMD freesync), I think can use this standar= d flag.=20 > IMO, it's better for Komeda to just allow setting a new CRTC mode to > one with a different VFP (but everything else the same) without a full > modeset. >=20 > You could try and implement the upstream VRR properties too - but you > can get the functionality added by this patch without changing any > UAPI. >=20 > (Note the only reason we ever added the idea of passing in VFP by > itself is because in ADF, modeset was a separate ioctl entirely, so we > couldn't do it atomically) Yes, we can. But DRM-KMS (the helpers) default doesn't support such light mode-set. we can not rely on the helpers, but need to implement by ourselves. Is it worth to do it? My plan is: First: I think the key problem here is not how to enable VRR for our display, but how to pass the VRR caps from the connector to our display. And it's not only the VRR prblem but like the command_mode/dual-link all the none standard connector features that needed by our HW. Unlike the intel/amd/NV mostly they have their own transmitter HW (and connector driver), So they can easily pass the info between connector and display. But for us that's the third part, and we can not do any assumption to them, and for us they are the drm_connector, but we can not got these infos via a drm_connector. So I think we need a standard way to pass these private infos. I plan to add a new query function to drm_bridge like (*query)(u64 query_id, xxx-type return_va); and query_id is like the modifiers: first 8bit is vendor_id. when the third part connector integrats to our display, if the transmitter HW support the features that our display needed, they can supply this query function to notify the caps support to us. If the connector doesn't have this query, or query fail we treat the feature is not support by this connector. And For this VRR. User only need to En/Dis VRR, Once komeda received Enable command - query the connector for VFP range 1. connector doesn't support VRR, ignore or return error ?. 2. got the VFP range, configure the display according the range. Once the disable received, restore the mode vfp. Thanks James > >=20 > > we use this private property because we're switching to in-tree, before > > finish the switch, we still need to maintain our out-of-tree driver whi= ch > > depend on a older and doesn't have the VRR_ENABLED property. for avoid > > diverging the two branch. my old plan is first switch to in-tree, then = drop > > the out-of-tree driver and then unify the usage. > >=20 > > > > + if (!prop) > > > > + return -ENOMEM; > > > > + > > > > + drm_object_attach_property(&crtc->base, prop, 0); > > > > + kcrtc->vrr_enable_property =3D prop; > > > > + > > > > + return 0; > > > > +} > > > > + > > > > static struct drm_plane * > > > > get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *c= rtc) > > > > { > > > > @@ -659,6 +717,10 @@ static int komeda_crtc_add(struct komeda_kms_d= ev *kms, > > > > if (err) > > > > return err; > > > > =20 > > > > + err =3D komeda_crtc_create_vrr_property(kcrtc); > > > > + if (err) > > > > + return err; > > > > + > > > > return err; > > > > } > > > > =20 > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/driv= ers/gpu/drm/arm/display/komeda/komeda_kms.h > > > > index dc1d436..d0cf838 100644 > > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h > > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h > > > > @@ -98,6 +98,12 @@ struct komeda_crtc { > > > > =20 > > > > /** @slave_planes_property: property for slaves of the planes */ > > > > struct drm_property *slave_planes_property; > > >=20 > > > And this seems to not be the first time this happened. Looking at kom= eda > > > with a quick git grep on properties you've actually accumulated quite= a > > > pile of such driver properties already. Where's the userspace for thi= s? > > > Where's the uapi discussions for this stuff? Where's the igt tests fo= r > > > this (yes a bunch are after we agreed to have testcases for this). > > >=20 > > > I know that in the past we've been somewhat sloppy properties, but th= at > > > was a mistake and we've cranked down on this hard. Probably need to f= ix > > > this with a pile of reverts and start over. > > > -Daniel > >=20 > > Sorry again. > >=20 > > First I'll send some patches to remove these private properties. > >=20 > > and then discuss for how to impelement them. > >=20 > > The current komeda privates are: > >=20 > > crtc: > > clock_ratio > > slave_planes > >=20 > > plane: > > img_enhancement > > layer_split > >=20 > > Layer_split: it can be deleted and computed in kernel. > >=20 > > img_enhancement: > > it is for image enhancement, can be removed and computed in kernel. > > but I'd like to have it, since it's a seperated function (NOT only > > for scaling or YUV format), I think only user can real know if need > > to enable it. > >=20 > >=20 > > img_enhancement: > > it is for image enhancement, can be removed and computed in kernel. > > but I'd like to have it, since it's a seperated function (NOT only > > for scaling or YUV format), I think only user can real know if need > > to enable it. > > I think maybe we can add it CORE as an optional drm_plane property. >=20 > I really don't think we should be exposing this. It's purely there to > help improve an image after scaling (effectively, sharpening). It's > not a general purpose "image enhancer". Exposing a property which says > "image enhancement" isn't useful to any application - what kind of > enhancement is it doing? >=20 > >=20 > > clock_ratio: > > It's the clock ratio of (main engine lock/output pixel clk) for > > komeda HW's downscaling restriction, as below: > >=20 > > D71 downscaling must satisfy the following equation > >=20 > > MCLK h_in * v_in > > ------- >=3D --------------------------------------------- > > PXLCLK (h_total - (1 + 2 * v_in / v_out)) * v_out > >=20 > > In only horizontal downscaling situation, the right side should be > > multiplied by (h_total - 3) / (h_active - 3), then equation becomes > >=20 > > MCLK h_in > > ------- >=3D ---------------- > > PXLCLK (h_active - 3) > >=20 > > slave_planes: > > it's not only for the zpos, but most importantly for notify the user > > to group the planes to two resource sets (pipeline-0 resources and pi= peline1). > > Per our HW design the two pipelines can be dynamic assigned to CRTC > > according to the usage. > > - like user only enable one CRTC which can use all two pipelines > > (two resource resource sets) > > - but if enabled two CRTCs, only one resource set available for > > each CRTC. > >=20 > > komeda user need to known the clock_ratio and slave_planes, but how > > to expose them: private_property, sysfs or other ways, seems we need > > to disscuss. :) >=20 > @Daniel, >=20 > These two are a symptom of a fundamental impedance mismatch between > how KMS works and actually making optimal use of HW (or: how Android > works). >=20 > HWComposer is expected to have good knowledge of how the underlying HW > operates, so that it can effectively schedule a scene. "TEST_ONLY til > it works" isn't a viable strategy, and it absolutely shouldn't be > needed for a piece of code which has been written _specifically_ to > drive komeda. >=20 > It's acknowledged that HW-specific planners may be needed even in > drm-hwcomposer, and those planners are going to need to get told some > stuff about the HW. Whether that info should go through atomic > properties or not is up for debate (adding properties without > following the rules notwithstanding). >=20 > What's certain is that debugfs is not workable, because it's not > available in a production Android device (nor should it be). >=20 > And of course, there's room for making the information more generic as > far as possible, at which point they might be better candidates for > DRM UAPI. >=20 > Thanks, > -Brian >=20 > >=20 > > Thanks > > James > >=20 > > > > + > > > > + /** @vrr_property: property for variable refresh rate */ > > > > + struct drm_property *vrr_property; > > > > + > > > > + /** @vrr_enable_property: property for enable/disable the vrr */ > > > > + struct drm_property *vrr_enable_property; > > > > }; > > > > =20 > > > > /** > > > > @@ -126,6 +132,12 @@ struct komeda_crtc_state { > > > > =20 > > > > /** @max_slave_zorder: the maximum of slave zorder */ > > > > u32 max_slave_zorder; > > > > + > > > > + /** @vfp: the value of vertical front porch */ > > > > + u32 vfp; > > > > + > > > > + /** @en_vrr: enable status of variable refresh rate */ > > > > + u8 en_vrr : 1; > > > > }; > > > > =20 > > > > /** struct komeda_kms_dev - for gather KMS related things */ > > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b= /drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > > > > index 00e8083..66d7664 100644 > > > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h > > > > @@ -336,7 +336,9 @@ struct komeda_improc_state { > > > > /* display timing controller */ > > > > struct komeda_timing_ctrlr { > > > > struct komeda_component base; > > > > - u8 supports_dual_link : 1; > > > > + u8 supports_dual_link : 1, > > > > + supports_vrr : 1; > > > > + struct malidp_range vfp_range; > > > > }; > > > > =20 > > > > struct komeda_timing_ctrlr_state { > > > > --=20 > > > > 1.9.1 > > > >=20 > > > > _______________________________________________ > > > > dri-devel mailing list > > > > dri-devel@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > >=20 > > > --=20 > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch