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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CFCAC07CA9 for ; Tue, 28 Nov 2023 09:44:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zmf4BVhyaqK1R0XFu0/lzMmzJcj+2aJ+J93CPS3QVgo=; b=shGn8at/fu0JUi 8MdvH+5SllMw42mfeSAyHhHV8A2zAlxAlc26pRVvhWub69onN8gdNa9MmL7t3yz7AjuzM3G6Qak/3 GHZAUwUhsOY7mtPP51R4weJPjHBiOz5TQ6vrt/eapa0qDtAaCXkIwlTWBdeGWm6KRmNMLsuwSaGZ4 uWgjidrs3fN6S89V+OaB8IWtIgmh9D/yCIo9zj6mmbGhu48asODd3HyVC1umaUqjap1Cb5taUZPhG dDDYKGSJ4+kG0CPHwJVEG/+SjbYEXshAspoBkX9GtOVCsOfZ0w2dgDRE1lhpjjgLM6Mblf506WttH HxzRmLpgnJOGf71c1y2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r7ue5-004m9X-0b; Tue, 28 Nov 2023 09:44:45 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r7ue1-004m8R-0z for linux-rockchip@lists.infradead.org; Tue, 28 Nov 2023 09:44:43 +0000 Received: from i53875bf8.versanet.de ([83.135.91.248] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r7udu-0002kA-Qd; Tue, 28 Nov 2023 10:44:34 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Andy Yan , Andy Yan Cc: hjc@rock-chips.com, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org, devicetree@vger.kernel.org, sebastian.reichel@collabora.com, kever.yang@rock-chips.com, chris.obbard@collabora.com, s.hauer@pengutronix.de Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588 Date: Tue, 28 Nov 2023 10:44:33 +0100 Message-ID: <4339687.HovnAMPojK@diego> In-Reply-To: References: <20231122125316.3454268-1-andyshrk@163.com> <4788319.uZKlY2gecq@diego> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231128_014441_342598_1AC443FE X-CRM114-Status: GOOD ( 42.60 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org SGkgQW5keSwKCkFtIERpZW5zdGFnLCAyOC4gTm92ZW1iZXIgMjAyMywgMTA6MzI6NTUgQ0VUIHNj aHJpZWIgQW5keSBZYW46Cj4gT24gMTEvMjcvMjMgMjM6MjksIEhlaWtvIFN0w7xibmVyIHdyb3Rl Ogo+ID4gQW0gTWl0dHdvY2gsIDIyLiBOb3ZlbWJlciAyMDIzLCAxMzo1NTo0NCBDRVQgc2Nocmll YiBBbmR5IFlhbjoKPiA+PiBGcm9tOiBBbmR5IFlhbiA8YW5keS55YW5Acm9jay1jaGlwcy5jb20+ Cj4gPj4KPiA+PiBWT1AyIG9uIHJrMzU4ODoKPiA+Pgo+ID4+IEZvdXIgdmlkZW8gcG9ydHM6Cj4g Pj4gVlAwIE1heCA0MDk2eDIxNjAKPiA+PiBWUDEgTWF4IDQwOTZ4MjE2MAo+ID4+IFZQMiBNYXgg NDA5NngyMTYwCj4gPj4gVlAzIE1heCAyMDQ4eDEwODAKPiA+Pgo+ID4+IDQgNEsgQ2x1c3RlciB3 aW5kb3dzIHdpdGggQUZCQy9saW5lIFJHQiBhbmQgQUZCQy1vbmx5IFlVViBzdXBwb3J0Cj4gPj4g NCA0SyBFc21hcnQgd2luZG93cyB3aXRoIGxpbmUgUkdCL1lVViBzdXBwb3J0Cj4gPj4KPiA+PiBT aWduZWQtb2ZmLWJ5OiBBbmR5IFlhbiA8YW5keS55YW5Acm9jay1jaGlwcy5jb20+Cj4gPj4KPiA+ PiAtLS0KPiA+Pgo+ID4+IENoYW5nZXMgaW4gdjI6Cj4gPj4gLSBhZGQgcmszNTg4XyBwcmVmaXgg Zm9yIGZ1bmN0aW9ucyB3aGljaCBhcmUgcmszNTg4IG9ubHkKPiA+PiAtIG1ha2Ugc29tZSBjYWxj dWxhdGlvbiBhcyBmaXhlZCB2YWx1ZSBhbmQga2VlcCBjYWxjdWxhdGlvbiBmb3JtdWxhIGFzCj4g Pj4gICAgY29tbWVudAo+ID4+IC0gY2hlY2sgcmV0dXJuIHZhbHVlIGZvciBzb21lIGNydSBjYWxj dWxhdGlvbiBmdW5jdGlvbnMuCj4gPj4gLSBjaGVjayByZXR1cm4gdmFsdWUgZm9yIHN5c2Nvbl9y ZWdtYXBfbG9va3VwX2J5X3BoYW5kbGUKPiA+PiAtIGFkZCBOVjIwL05WMzAgZm9yIGVzbWFydCBw bGFuZQo+ID4+Cj4gPj4gICBkcml2ZXJzL2dwdS9kcm0vcm9ja2NoaXAvcm9ja2NoaXBfZHJtX3Zv cDIuYyB8IDM4MSArKysrKysrKysrKysrKysrKystCj4gPj4gICBkcml2ZXJzL2dwdS9kcm0vcm9j a2NoaXAvcm9ja2NoaXBfZHJtX3ZvcDIuaCB8ICA2NiArKysrCj4gPj4gICBkcml2ZXJzL2dwdS9k cm0vcm9ja2NoaXAvcm9ja2NoaXBfdm9wMl9yZWcuYyB8IDIyMSArKysrKysrKysrKwo+ID4+ICAg MyBmaWxlcyBjaGFuZ2VkLCA2NjAgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkKPiA+Pgo+ ID4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0vcm9ja2NoaXAvcm9ja2NoaXBfZHJtX3Zv cDIuYyBiL2RyaXZlcnMvZ3B1L2RybS9yb2NrY2hpcC9yb2NrY2hpcF9kcm1fdm9wMi5jCj4gPj4g aW5kZXggNGJjYzQwNWJjZjExLi45ZWVjYmUxZjcxZjkgMTAwNjQ0Cj4gPj4gLS0tIGEvZHJpdmVy cy9ncHUvZHJtL3JvY2tjaGlwL3JvY2tjaGlwX2RybV92b3AyLmMKPiA+PiArKysgYi9kcml2ZXJz L2dwdS9kcm0vcm9ja2NoaXAvcm9ja2NoaXBfZHJtX3ZvcDIuYwo+ID4+IEBAIC0yNzEsOSArMjgy LDEyIEBAIHN0YXRpYyBib29sIHZvcDJfY2x1c3Rlcl93aW5kb3coY29uc3Qgc3RydWN0IHZvcDJf d2luICp3aW4pCj4gPj4gICBzdGF0aWMgdm9pZCB2b3AyX2NmZ19kb25lKHN0cnVjdCB2b3AyX3Zp ZGVvX3BvcnQgKnZwKQo+ID4+ICAgewo+ID4+ICAgCXN0cnVjdCB2b3AyICp2b3AyID0gdnAtPnZv cDI7Cj4gPj4gKwl1MzIgdmFsOwo+ID4+ICsKPiA+PiArCXZhbCA9IEJJVCh2cC0+aWQpIHwgKEJJ VCh2cC0+aWQpIDw8IDE2KSB8Cj4gPj4gKwkJUkszNTY4X1JFR19DRkdfRE9ORV9fR0xCX0NGR19E T05FX0VOOwo+ID4+ICAgCj4gPj4gLQlyZWdtYXBfc2V0X2JpdHModm9wMi0+bWFwLCBSSzM1Njhf UkVHX0NGR19ET05FLAo+ID4+IC0JCQlCSVQodnAtPmlkKSB8IFJLMzU2OF9SRUdfQ0ZHX0RPTkVf X0dMQl9DRkdfRE9ORV9FTik7Cj4gPj4gKwlyZWdtYXBfc2V0X2JpdHModm9wMi0+bWFwLCBSSzM1 NjhfUkVHX0NGR19ET05FLCB2YWwpOwo+ID4gSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kIHRoYXQg Y29kZToKPiA+ICgxKSB0aGUgd3JpdGUgbWFzayBpcyBhbHNvIHByZXNlbnQgb24gdGhlIHJrMzU2 OCwgc28gc2hvdWxkIHRoaXMgY2hhbmdlCj4gPiAgICAgIGJlIGEgc2VwYXJhdGUgcGF0Y2ggd2l0 aCBhIGZpeGVzIHRhZz8KPiAKPiBUaGUgd3JpdGUgbWFzayBvZiBWUCBjb25maWcgZG9uZSBvbiBy azM1NnggaXMgbWlzc2luZywgdGhhdCBtZWFucwo+IHlvdSBjYW4gd3JpdGUgdGhlIGNvcnJlc3Bv bmRpbmcgbWFzayBiaXQsIGJ1dCBpdCBoYXMgbm8gZWZmZWN0Lgo+Cj4gSSBvbmNlIGNvbnNpZGVy ZWQgbWFraW5nIGl0IGEgc2VwYXJhdGUgcGF0Y2gsICBJIGNhbiBzcGxpdCBpdCBhcyBhIHNlcGFy YXRlIHBhdGNoIGlmCj4geW91IGxpa2UuCgpJIHRoaW5rIEknZCBsaWtlIGl0IHRvIGJlIGEgc2Vw YXJhdGUgcGF0Y2ggcGxlYXNlLgoKCj4gPiAoMikgUkszNTY4X1JFR19DRkdfRE9ORV9fR0xCX0NG R19ET05FX0VOIGRvZXMgbm90IGNvbnRhaW4gdGhlIHBhcnQgZm9yCj4gPiAgICAgIHRoZSB3cml0 ZS1tYXNrCj4gPgo+ID4gCSNkZWZpbmUgUkszNTY4X1JFR19DRkdfRE9ORV9fR0xCX0NGR19ET05F X0VOICAgICBCSVQoMTUpCj4gPgo+ID4gICAgICB3aHkgaXMgdGhpcyB3b3JraW5nIHRoZW4/Cj4g Cj4gCj4gQWN0dWFsbHkgdGhpcyBiaXQgaGFzIG5vIHdyaXRlLW1hc2sgYml0LiDwn5mCCgp3aGVu IGRvaW5nIHRoYXQgc2VwYXJhdGUgcGF0Y2ggbWVudGlvbmVkIGFib3ZlLCBjb3VsZCB5b3UgYWxz byBhZGQgYQpjb21tZW50IHRvIHRoZSBjb2RlIHN0YXRpbmcgdGhhdCBSSzM1NjhfUkVHX0NGR19E T05FX19HTEJfQ0ZHX0RPTkVfRU4KZG9lc24ndCBoYXZlIGEgd3JpdGUgbWFzayBiaXQgcGxlYXNl PwoKQmVjYXVzZSB0aGUgVFJNIGlzIG5vdCBjbGVhciBhbmQgaWRlYWxseSBJJ2Qgbm90IGZvcmdl dCB0aGlzIGZhY3QgZm9yCnRoZSBmdXR1cmUgOi0pIC4KCgo+ID4+ICAgfQo+ID4+ICAgCj4gPj4g ICBzdGF0aWMgdm9pZCB2b3AyX3dpbl9kaXNhYmxlKHN0cnVjdCB2b3AyX3dpbiAqd2luKQo+ID4g Wy4uLl0KPiA+Cj4gPj4gQEAgLTEyOTgsNyArMTM0NiwxMSBAQCBzdGF0aWMgdm9pZCB2b3AyX3Bs YW5lX2F0b21pY191cGRhdGUoc3RydWN0IGRybV9wbGFuZSAqcGxhbmUsCj4gPj4gICAJCQl2b3Ay X3dpbl93cml0ZSh3aW4sIFZPUDJfV0lOX0FGQkNfRU5BQkxFLCAxKTsKPiA+PiAgIAkJdm9wMl93 aW5fd3JpdGUod2luLCBWT1AyX1dJTl9BRkJDX0ZPUk1BVCwgYWZiY19mb3JtYXQpOwo+ID4+ICAg CQl2b3AyX3dpbl93cml0ZSh3aW4sIFZPUDJfV0lOX0FGQkNfVVZfU1dBUCwgdXZfc3dhcCk7Cj4g Pj4gLQkJdm9wMl93aW5fd3JpdGUod2luLCBWT1AyX1dJTl9BRkJDX0FVVE9fR0FUSU5HX0VOLCAw KTsKPiA+PiArCQlpZiAodm9wMi0+ZGF0YS0+c29jX2lkID09IDM1NjYgfHwgdm9wMi0+ZGF0YS0+ c29jX2lkID09IDM1NjgpCj4gPj4gKwkJCXZvcDJfd2luX3dyaXRlKHdpbiwgVk9QMl9XSU5fQUZC Q19BVVRPX0dBVElOR19FTiwgMCk7Cj4gPj4gKwkJZWxzZQo+ID4+ICsJCQl2b3AyX3dpbl93cml0 ZSh3aW4sIFZPUDJfV0lOX0FGQkNfQVVUT19HQVRJTkdfRU4sIDEpOwo+ID4+ICsKPiA+IEkgdGhp bmsgdGhpcyBhdCBsZWFzdCB3YXJyYW50cyBhIGNvbW1lbnQsIHdoYXQgaXMgaGFwcGVuaW5nIGhl cmUuIEFsc28sCj4gPiBjYW4geW91IGFscmVhZHkgc2VlIGhvdyBmdXR1cmUgdm9wMi11c2VycyBh cmUgYmVoYXZpbmcgLSBha2EgYXJlIGFsbCBuZXcKPiA+IHNvY3MgaW4gdGhlICJlbHNlIiBwYXJ0 IG9mIHRoZSBjb25kaXRpb25hbCwgb3Igd291bGQgYSBzd2l0Y2gtY2FzZSBiZXR0ZXIKPiA+IHJl cHJlc2VudCBmdXR1cmUgc29jcz8KPiAKPiAKPiBPbiByazM1NngsIHRoaXMgYml0IGlzIGF1dG8g Z2F0aW5nIGVuYWJsZSwgYnV0IHRoaXMgZnVuY3Rpb24gaXMgbm90IHdvcmsgd2VsbCBzbwo+IHdl IG5lZWQgdG8gZGlzYWJsZSB0aGlzIGZ1bmN0aW9uLgo+IE9uIHJrMzU4OCwgYW5kIHRoZSBmb2xs b3dpbmcgbmV3IHNvYyhyazM1MjgvcmszNTc2KSwgdGhpcyBiaXQgaXMgZ2F0aW5nIGRpc2FibGUs Cj4gd2Ugc2hvdWxkIHdyaXRlIDEgdG8gZGlzYWJsZSBnYXRpbmcgd2hlbiBlbmFibGUgYSBjbHVz dGVyIHdpbmRvdy4KPiAKPiAKPiBNYXliZSBpIGFkZCBzb21lIGNvbW1lbnRzIGluIG5leHQgdmVy c2lvbiA/CgpZZXAgdGhhdCBjb21tZW50IHdvdWxkIGJlIGhlbHBmdWwuIEFuZCB3aXRoIHlvdXIg ZXhwbGFuYXRpb24gdGhlIGNvZGUKaXRzZWxmIGNhbiBzdGF5IGFzIGl0IGlzIDotKQoKVGhhbmtz CkhlaWtvCgoKPiA+PiAgIAkJdm9wMl93aW5fd3JpdGUod2luLCBWT1AyX1dJTl9BRkJDX0JMT0NL X1NQTElUX0VOLCAwKTsKPiA+PiAgIAkJdHJhbnNmb3JtX29mZnNldCA9IHZvcDJfYWZiY190cmFu c2Zvcm1fb2Zmc2V0KHBzdGF0ZSwgaGFsZl9ibG9ja19lbik7Cj4gPj4gICAJCXZvcDJfd2luX3dy aXRlKHdpbiwgVk9QMl9XSU5fQUZCQ19IRFJfUFRSLCB5cmdiX21zdCk7Cj4gPgo+ID4+IEBAIC0x NjI3LDkgKzE5MzcsMTcgQEAgc3RhdGljIHZvaWQgdm9wMl9jcnRjX2F0b21pY19lbmFibGUoc3Ry dWN0IGRybV9jcnRjICpjcnRjLAo+ID4+ICAgCWRybV9mb3JfZWFjaF9lbmNvZGVyX21hc2soZW5j b2RlciwgY3J0Yy0+ZGV2LCBjcnRjX3N0YXRlLT5lbmNvZGVyX21hc2spIHsKPiA+PiAgIAkJc3Ry dWN0IHJvY2tjaGlwX2VuY29kZXIgKnJrZW5jb2RlciA9IHRvX3JvY2tjaGlwX2VuY29kZXIoZW5j b2Rlcik7Cj4gPj4gICAKPiA+PiAtCQlyazM1Njhfc2V0X2ludGZfbXV4KHZwLCBya2VuY29kZXIt PmNydGNfZW5kcG9pbnRfaWQsIHBvbGZsYWdzKTsKPiA+PiArCQkvKgo+ID4+ICsJCSAqIGZvciBk cml2ZSBhIGhpZ2ggcmVzb2x1dGlvbig0S1AxMjAsIDhLKSwgdm9wIG9uIHJrMzU4OC9yazM1NzYg bmVlZAo+ID4+ICsJCSAqIHByb2Nlc3MgbXVsdGkoMS8yLzQvOCkgcGl4ZWxzIHBlciBjeWNsZSwg c28gdGhlIGRjbGsgZmVlZCBieSB0aGUKPiA+PiArCQkgKiBzeXN0ZW0gY3J1IG1heSBiZSB0aGUg MS8yIG9yIDEvNCBvZiBtb2RlLT5jbG9jay4KPiA+PiArCQkgKi8KPiA+PiArCQljbG9jayA9IHZv cDJfc2V0X2ludGZfbXV4KHZwLCBya2VuY29kZXItPmNydGNfZW5kcG9pbnRfaWQsIHBvbGZsYWdz KTsKPiA+PiAgIAl9Cj4gPj4gICAKPiA+PiArCWlmICghY2xvY2spCj4gPj4gKwkJcmV0dXJuOwo+ ID4+ICsKPiA+IGhtbSwgc2hvdWxkbid0IHRoZSBjaGVjayBmb3IgdGhlIHZhbGlkaXR5IG9mIGEg bW9kZSBoYXBwZW4gYmVmb3JlCj4gPiBhdG9taWNfZW5hYmxlIGlzIHJ1bj8gU28gdGhpcyBzaG91 bGRuJ3QgZXJyb3Igb3V0IGluIHRoZSBtaWRkbGUgb2YgdGhlCj4gPiBmdW5jdGlvbj8KPiA+Cj4g Pgo+ID4+ICAgCWlmICh2Y3N0YXRlLT5vdXRwdXRfbW9kZSA9PSBST0NLQ0hJUF9PVVRfTU9ERV9B QUFBICYmCj4gPj4gICAJICAgICEodnBfZGF0YS0+ZmVhdHVyZSAmIFZPUF9GRUFUVVJFX09VVFBV VF8xMEJJVCkpCj4gPj4gICAJCW91dF9tb2RlID0gUk9DS0NISVBfT1VUX01PREVfUDg4ODsKPiA+ Cj4gPiBUaGFua3MKPiA+IEhlaWtvCj4gPgo+ID4KPiA+Cj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gTGludXgtcm9ja2NoaXAgbWFpbGluZyBs aXN0Cj4gPiBMaW51eC1yb2NrY2hpcEBsaXN0cy5pbmZyYWRlYWQub3JnCj4gPiBodHRwOi8vbGlz dHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJvY2tjaGlwCj4gCgoKCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXgtcm9j a2NoaXAgbWFpbGluZyBsaXN0CkxpbnV4LXJvY2tjaGlwQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0 cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1yb2NrY2hpcAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=none Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0DF0DA; Tue, 28 Nov 2023 01:44:48 -0800 (PST) Received: from i53875bf8.versanet.de ([83.135.91.248] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r7udu-0002kA-Qd; Tue, 28 Nov 2023 10:44:34 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Andy Yan , Andy Yan Cc: hjc@rock-chips.com, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org, devicetree@vger.kernel.org, sebastian.reichel@collabora.com, kever.yang@rock-chips.com, chris.obbard@collabora.com, s.hauer@pengutronix.de Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588 Date: Tue, 28 Nov 2023 10:44:33 +0100 Message-ID: <4339687.HovnAMPojK@diego> In-Reply-To: References: <20231122125316.3454268-1-andyshrk@163.com> <4788319.uZKlY2gecq@diego> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Andy, Am Dienstag, 28. November 2023, 10:32:55 CET schrieb Andy Yan: > On 11/27/23 23:29, Heiko St=C3=BCbner wrote: > > Am Mittwoch, 22. November 2023, 13:55:44 CET schrieb Andy Yan: > >> From: Andy Yan > >> > >> VOP2 on rk3588: > >> > >> Four video ports: > >> VP0 Max 4096x2160 > >> VP1 Max 4096x2160 > >> VP2 Max 4096x2160 > >> VP3 Max 2048x1080 > >> > >> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support > >> 4 4K Esmart windows with line RGB/YUV support > >> > >> Signed-off-by: Andy Yan > >> > >> --- > >> > >> Changes in v2: > >> - add rk3588_ prefix for functions which are rk3588 only > >> - make some calculation as fixed value and keep calculation formula as > >> comment > >> - check return value for some cru calculation functions. > >> - check return value for syscon_regmap_lookup_by_phandle > >> - add NV20/NV30 for esmart plane > >> > >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 381 +++++++++++++++++= +- > >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 66 ++++ > >> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 221 +++++++++++ > >> 3 files changed, 660 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gp= u/drm/rockchip/rockchip_drm_vop2.c > >> index 4bcc405bcf11..9eecbe1f71f9 100644 > >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> @@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2= _win *win) > >> static void vop2_cfg_done(struct vop2_video_port *vp) > >> { > >> struct vop2 *vop2 =3D vp->vop2; > >> + u32 val; > >> + > >> + val =3D BIT(vp->id) | (BIT(vp->id) << 16) | > >> + RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN; > >> =20 > >> - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, > >> - BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN); > >> + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val); > > I don't fully understand that code: > > (1) the write mask is also present on the rk3568, so should this change > > be a separate patch with a fixes tag? >=20 > The write mask of VP config done on rk356x is missing, that means > you can write the corresponding mask bit, but it has no effect. > > I once considered making it a separate patch, I can split it as a separa= te patch if > you like. I think I'd like it to be a separate patch please. > > (2) RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN does not contain the part for > > the write-mask > > > > #define RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN BIT(15) > > > > why is this working then? >=20 >=20 > Actually this bit has no write-mask bit. =F0=9F=99=82 when doing that separate patch mentioned above, could you also add a comment to the code stating that RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN doesn't have a write mask bit please? Because the TRM is not clear and ideally I'd not forget this fact for the future :-) . > >> } > >> =20 > >> static void vop2_win_disable(struct vop2_win *win) > > [...] > > > >> @@ -1298,7 +1346,11 @@ static void vop2_plane_atomic_update(struct drm= _plane *plane, > >> vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1); > >> vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format); > >> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap); > >> - vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0); > >> + if (vop2->data->soc_id =3D=3D 3566 || vop2->data->soc_id =3D=3D 356= 8) > >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0); > >> + else > >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1); > >> + > > I think this at least warrants a comment, what is happening here. Also, > > can you already see how future vop2-users are behaving - aka are all new > > socs in the "else" part of the conditional, or would a switch-case bett= er > > represent future socs? >=20 >=20 > On rk356x, this bit is auto gating enable, but this function is not work = well so > we need to disable this function. > On rk3588, and the following new soc(rk3528/rk3576), this bit is gating d= isable, > we should write 1 to disable gating when enable a cluster window. >=20 >=20 > Maybe i add some comments in next version ? Yep that comment would be helpful. And with your explanation the code itself can stay as it is :-) Thanks Heiko > >> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0); > >> transform_offset =3D vop2_afbc_transform_offset(pstate, half_block= _en); > >> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst); > > > >> @@ -1627,9 +1937,17 @@ static void vop2_crtc_atomic_enable(struct drm_= crtc *crtc, > >> drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_m= ask) { > >> struct rockchip_encoder *rkencoder =3D to_rockchip_encoder(encoder= ); > >> =20 > >> - rk3568_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags); > >> + /* > >> + * for drive a high resolution(4KP120, 8K), vop on rk3588/rk3576 ne= ed > >> + * process multi(1/2/4/8) pixels per cycle, so the dclk feed by the > >> + * system cru may be the 1/2 or 1/4 of mode->clock. > >> + */ > >> + clock =3D vop2_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polfla= gs); > >> } > >> =20 > >> + if (!clock) > >> + return; > >> + > > hmm, shouldn't the check for the validity of a mode happen before > > atomic_enable is run? So this shouldn't error out in the middle of the > > function? > > > > > >> if (vcstate->output_mode =3D=3D ROCKCHIP_OUT_MODE_AAAA && > >> !(vp_data->feature & VOP_FEATURE_OUTPUT_10BIT)) > >> out_mode =3D ROCKCHIP_OUT_MODE_P888; > > > > Thanks > > Heiko > > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip >=20 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A9D1FC07CA9 for ; Tue, 28 Nov 2023 09:44:41 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1E94210E470; Tue, 28 Nov 2023 09:44:41 +0000 (UTC) Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by gabe.freedesktop.org (Postfix) with ESMTPS id D50D810E470 for ; Tue, 28 Nov 2023 09:44:38 +0000 (UTC) Received: from i53875bf8.versanet.de ([83.135.91.248] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r7udu-0002kA-Qd; Tue, 28 Nov 2023 10:44:34 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Andy Yan , Andy Yan Subject: Re: [PATCH v2 10/12] drm/rockchip: vop2: Add support for rk3588 Date: Tue, 28 Nov 2023 10:44:33 +0100 Message-ID: <4339687.HovnAMPojK@diego> In-Reply-To: References: <20231122125316.3454268-1-andyshrk@163.com> <4788319.uZKlY2gecq@diego> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, s.hauer@pengutronix.de, chris.obbard@collabora.com, hjc@rock-chips.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kever.yang@rock-chips.com, linux-rockchip@lists.infradead.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, sebastian.reichel@collabora.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Andy, Am Dienstag, 28. November 2023, 10:32:55 CET schrieb Andy Yan: > On 11/27/23 23:29, Heiko St=C3=BCbner wrote: > > Am Mittwoch, 22. November 2023, 13:55:44 CET schrieb Andy Yan: > >> From: Andy Yan > >> > >> VOP2 on rk3588: > >> > >> Four video ports: > >> VP0 Max 4096x2160 > >> VP1 Max 4096x2160 > >> VP2 Max 4096x2160 > >> VP3 Max 2048x1080 > >> > >> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support > >> 4 4K Esmart windows with line RGB/YUV support > >> > >> Signed-off-by: Andy Yan > >> > >> --- > >> > >> Changes in v2: > >> - add rk3588_ prefix for functions which are rk3588 only > >> - make some calculation as fixed value and keep calculation formula as > >> comment > >> - check return value for some cru calculation functions. > >> - check return value for syscon_regmap_lookup_by_phandle > >> - add NV20/NV30 for esmart plane > >> > >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 381 +++++++++++++++++= +- > >> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 66 ++++ > >> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 221 +++++++++++ > >> 3 files changed, 660 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gp= u/drm/rockchip/rockchip_drm_vop2.c > >> index 4bcc405bcf11..9eecbe1f71f9 100644 > >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c > >> @@ -271,9 +282,12 @@ static bool vop2_cluster_window(const struct vop2= _win *win) > >> static void vop2_cfg_done(struct vop2_video_port *vp) > >> { > >> struct vop2 *vop2 =3D vp->vop2; > >> + u32 val; > >> + > >> + val =3D BIT(vp->id) | (BIT(vp->id) << 16) | > >> + RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN; > >> =20 > >> - regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, > >> - BIT(vp->id) | RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN); > >> + regmap_set_bits(vop2->map, RK3568_REG_CFG_DONE, val); > > I don't fully understand that code: > > (1) the write mask is also present on the rk3568, so should this change > > be a separate patch with a fixes tag? >=20 > The write mask of VP config done on rk356x is missing, that means > you can write the corresponding mask bit, but it has no effect. > > I once considered making it a separate patch, I can split it as a separa= te patch if > you like. I think I'd like it to be a separate patch please. > > (2) RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN does not contain the part for > > the write-mask > > > > #define RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN BIT(15) > > > > why is this working then? >=20 >=20 > Actually this bit has no write-mask bit. =F0=9F=99=82 when doing that separate patch mentioned above, could you also add a comment to the code stating that RK3568_REG_CFG_DONE__GLB_CFG_DONE_EN doesn't have a write mask bit please? Because the TRM is not clear and ideally I'd not forget this fact for the future :-) . > >> } > >> =20 > >> static void vop2_win_disable(struct vop2_win *win) > > [...] > > > >> @@ -1298,7 +1346,11 @@ static void vop2_plane_atomic_update(struct drm= _plane *plane, > >> vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1); > >> vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format); > >> vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap); > >> - vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0); > >> + if (vop2->data->soc_id =3D=3D 3566 || vop2->data->soc_id =3D=3D 356= 8) > >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 0); > >> + else > >> + vop2_win_write(win, VOP2_WIN_AFBC_AUTO_GATING_EN, 1); > >> + > > I think this at least warrants a comment, what is happening here. Also, > > can you already see how future vop2-users are behaving - aka are all new > > socs in the "else" part of the conditional, or would a switch-case bett= er > > represent future socs? >=20 >=20 > On rk356x, this bit is auto gating enable, but this function is not work = well so > we need to disable this function. > On rk3588, and the following new soc(rk3528/rk3576), this bit is gating d= isable, > we should write 1 to disable gating when enable a cluster window. >=20 >=20 > Maybe i add some comments in next version ? Yep that comment would be helpful. And with your explanation the code itself can stay as it is :-) Thanks Heiko > >> vop2_win_write(win, VOP2_WIN_AFBC_BLOCK_SPLIT_EN, 0); > >> transform_offset =3D vop2_afbc_transform_offset(pstate, half_block= _en); > >> vop2_win_write(win, VOP2_WIN_AFBC_HDR_PTR, yrgb_mst); > > > >> @@ -1627,9 +1937,17 @@ static void vop2_crtc_atomic_enable(struct drm_= crtc *crtc, > >> drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_m= ask) { > >> struct rockchip_encoder *rkencoder =3D to_rockchip_encoder(encoder= ); > >> =20 > >> - rk3568_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polflags); > >> + /* > >> + * for drive a high resolution(4KP120, 8K), vop on rk3588/rk3576 ne= ed > >> + * process multi(1/2/4/8) pixels per cycle, so the dclk feed by the > >> + * system cru may be the 1/2 or 1/4 of mode->clock. > >> + */ > >> + clock =3D vop2_set_intf_mux(vp, rkencoder->crtc_endpoint_id, polfla= gs); > >> } > >> =20 > >> + if (!clock) > >> + return; > >> + > > hmm, shouldn't the check for the validity of a mode happen before > > atomic_enable is run? So this shouldn't error out in the middle of the > > function? > > > > > >> if (vcstate->output_mode =3D=3D ROCKCHIP_OUT_MODE_AAAA && > >> !(vp_data->feature & VOP_FEATURE_OUTPUT_10BIT)) > >> out_mode =3D ROCKCHIP_OUT_MODE_P888; > > > > Thanks > > Heiko > > > > > > > > _______________________________________________ > > Linux-rockchip mailing list > > Linux-rockchip@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-rockchip >=20