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 1501BC433F5 for ; Tue, 5 Apr 2022 15:11:20 +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: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VRPNvy2ahO4y1E6dO10CaljHaeUjKTzm4yMrtspeCMc=; b=JtkedMOVrYJe/w hVg9IFH8E2P5rJ3locjI/ICUOYsn6UsnzKvQ+9Q0Im8Kwud1uHItqtuPrF3e033ywK+GMzREv2p50 BssCjJDyJYGRH8sN6GmLS+ia7ptyVGMs9pEOV1ZA41Yh1ftoHhXNBj+pe09PGJpqVdnDVKig9vhii UTqMorp7LgQPDJgfJOqa/KGQE/gCb6VlQWPjFWOZXDyi6ju198YB2hybKLrQlPG46PvaUhpgZ2rax eoXsh2e2cKNwHSon1U5DKHeBWAsSyT78CpqGpLET1maYCOI0fbThgtAdc1KzXfgyj4g6GhTacH/m1 4Bl9h0kK666AbFeZt/dQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbkpw-001cyR-96; Tue, 05 Apr 2022 15:11:16 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbkps-001cvO-No for linux-rockchip@lists.infradead.org; Tue, 05 Apr 2022 15:11:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nicolas) with ESMTPSA id 14BC11F450DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1649171468; bh=D+PPyG+d8bSZBQUHvuUVVhH3F9DHPinWPY0RxBOGLSk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=fXHyX2PGLz0ROYpReWRUYVsjVnAwYs4vGBfotmSL/S9PIaEyt6ZIvhSApwIsBmKNq u5HY49fCocaxlJF+2UNGHXJdHdioG6Tbxdnd7Z/E0SAMQODKgYIzrLsMRI+gghk96s 5OLzd5Yt6pPZzXW+U8m1u+3hbk6iUTt9PWDaKT195nwD9pJE1GAafVEzuW6OuiCrY6 d+GKTUpMH3nsIEeGyC2tKIGM8RRuy5Dfm1JgzFP+S7vM7Kjj2slaYaFvlu4NZlXHmd Fjlf7E0rFIbcgVx+gQQji44T+NHsmwh6QRGBJXBGuqzo0Q7MQvYKvdexH6nzhfa7wL N6TFMwTeJ9ArQ== Message-ID: <92001085580ac1005596b34f79f1dadcc4b3f3c9.camel@collabora.com> Subject: Re: [PATCH v2 13/23] media: rkvdec: h264: Fix dpb_valid implementation From: Nicolas Dufresne To: Ezequiel Garcia Cc: Mauro Carvalho Chehab , Greg Kroah-Hartman , kernel@collabora.com, Sebastian Fricke , linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Date: Tue, 05 Apr 2022 11:10:57 -0400 In-Reply-To: References: <20220331193726.289559-1-nicolas.dufresne@collabora.com> <20220331193726.289559-14-nicolas.dufresne@collabora.com> User-Agent: Evolution 3.44.0 (3.44.0-1.fc36) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220405_081113_072223_52D99976 X-CRM114-Status: GOOD ( 30.56 ) 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 TGUgc2FtZWRpIDAyIGF2cmlsIDIwMjIgw6AgMDg6MTYgLTAzMDAsIEV6ZXF1aWVsIEdhcmNpYSBh IMOpY3JpdMKgOgo+IE9uIFRodSwgTWFyIDMxLCAyMDIyIGF0IDAzOjM3OjE1UE0gLTA0MDAsIE5p Y29sYXMgRHVmcmVzbmUgd3JvdGU6Cj4gPiBUaGUgcmVmIGJ1aWxkZXIgb25seSBwcm92aWRlZCBy ZWZlcmVuY2VzIHRoYXQgYXJlIG1hcmtlZCBhcyB2YWxpZCBpbiB0aGUKPiA+IGRwYi4gVGh1cyB0 aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBvZiBkcGJfdmFsaWQgd291bGQgYWx3YXlzIHNldCB0 aGUKPiA+IGZsYWcgdG8gMS4gVGhpcyBpcyBub3QgcmVwcmVzZW50aW5nIG1pc3NpbmcgZnJhbWVz ICh0aGlzIGlzIGNhbGxlZAo+ID4gJ25vbi1leGlzdGluZycgcGljdHVyZXMgaW4gdGhlIHNwZWMp LiBJbiBzb21lIGNvbnRleHQsIHRoZXNlIG5vbi1leGlzdGluZwo+ID4gcGljdHVyZXMgc3RpbGwg bmVlZCB0byBvY2N1cHkgYSBzbG90IGluIHRoZSByZWZlcmVuY2UgbGlzdCBhY2NvcmRpbmcgdG8K PiA+IHRoZSBzcGVjLgo+ID4gCj4gCj4gR29vZCBjYXRjaCEgT09DLCBkaWQgeW91IGZpbmQgdGhp cyBiZWNhdXNlIGl0IHdhcyBmYWlsaW5nIGEgdGVzdCB2ZWN0b3I/CgpUaGUgZWZmZWN0IGlzIGNv bXBsZXgsIHNvIEkgY291bGQgbm90IGNvcnJlbGF0ZSB0byBzcGVjaWZpYyB0ZXN0cy4gQWxzbywg d2hhdCBJCndhbnRlZCB0byBmaXggaXNuJ3QgY292ZXJlZCBieSB0aGUgSVRVIGNvbmZvcm1hbmNl LCBpdHMgbW9zdGx5IHJlc2lsaWFuY2UKcmVxdWlyZW1lbnQuIEJ1dCB0aGlzIHNob3VsZCByZW1v dmUgc29tZSBvZiB0aGUgSU9NTVUgZmF1bHQgb24gYnJva2VuIHN0cmVhbXMKYW5kIG1ha2UgaXQg bGVzcyBsaWtlbHkgdG8gdXNlIHJlZmVyZW5jZXMgdGhhdCBkb24ndCBleGlzdHMgb3IgYXJlbid0 IHNldCB3aGF0CndlIGV4cGVjdC4gQWZ0ZXIgdGhpcyBjaGFuZ2UsIHRoZSBkcml2ZXIgd2FzIGdl dHRpbmcgbW9yZSBzdGFibGUsIGFuZCByZXN1bHRzCndhcyBhbHNvIG1vcmUgcmVwcm9kdWNpYmxl IChzcGVjaWFsbHkgaW4gcGFyYWxsZWwgZGVjb2RlIGNhc2UsIHdoaWNoIEkgdXNlIHRvCnNwZWVk IHVwIHRlc3RpbmcpLgoKPiAKPiA+IFNpZ25lZC1vZmYtYnk6IE5pY29sYXMgRHVmcmVzbmUgPG5p Y29sYXMuZHVmcmVzbmVAY29sbGFib3JhLmNvbT4KPiA+IFJldmlld2VkLWJ5OiBTZWJhc3RpYW4g RnJpY2tlIDxzZWJhc3RpYW4uZnJpY2tlQGNvbGxhYm9yYS5jb20+Cj4gCj4gRml4ZXM6IGNkMzNj ODMwNDQ4YmEgKCJtZWRpYTogcmt2ZGVjOiBBZGQgdGhlIHJrdmRlYyBkcml2ZXIiKQo+IFJldmll d2VkLWJ5OiBFemVxdWllbCBHYXJjaWEgPGV6ZXF1aWVsQHZhbmd1YXJkaWFzdXIuY29tLmFyPgoK VGhhbmtzIGZvciB0aGUgcmV2aWV3LgoKPiAKPiBUaGFua3MsCj4gRXplcXVpZWwKPiAKPiA+IC0t LQo+ID4gIGRyaXZlcnMvc3RhZ2luZy9tZWRpYS9ya3ZkZWMvcmt2ZGVjLWgyNjQuYyB8IDMzICsr KysrKysrKysrKysrKystLS0tLS0KPiA+ICAxIGZpbGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygr KSwgOSBkZWxldGlvbnMoLSkKPiA+IAo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9t ZWRpYS9ya3ZkZWMvcmt2ZGVjLWgyNjQuYyBiL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9ya3ZkZWMv cmt2ZGVjLWgyNjQuYwo+ID4gaW5kZXggZGZmODk3MzJkZGQwLi5iY2RlMzdkNzIyNDQgMTAwNjQ0 Cj4gPiAtLS0gYS9kcml2ZXJzL3N0YWdpbmcvbWVkaWEvcmt2ZGVjL3JrdmRlYy1oMjY0LmMKPiA+ ICsrKyBiL2RyaXZlcnMvc3RhZ2luZy9tZWRpYS9ya3ZkZWMvcmt2ZGVjLWgyNjQuYwo+ID4gQEAg LTExMiw2ICsxMTIsNyBAQCBzdHJ1Y3Qgcmt2ZGVjX2gyNjRfcnVuIHsKPiA+ICAJY29uc3Qgc3Ry dWN0IHY0bDJfY3RybF9oMjY0X3NwcyAqc3BzOwo+ID4gIAljb25zdCBzdHJ1Y3QgdjRsMl9jdHJs X2gyNjRfcHBzICpwcHM7Cj4gPiAgCWNvbnN0IHN0cnVjdCB2NGwyX2N0cmxfaDI2NF9zY2FsaW5n X21hdHJpeCAqc2NhbGluZ19tYXRyaXg7Cj4gPiArCWludCByZWZfYnVmX2lkeFtWNEwyX0gyNjRf TlVNX0RQQl9FTlRSSUVTXTsKPiA+ICB9Owo+ID4gIAo+ID4gIHN0cnVjdCBya3ZkZWNfaDI2NF9j dHggewo+ID4gQEAgLTcyNSw2ICs3MjYsMjYgQEAgc3RhdGljIHZvaWQgYXNzZW1ibGVfaHdfcHBz KHN0cnVjdCBya3ZkZWNfY3R4ICpjdHgsCj4gPiAgCX0KPiA+ICB9Cj4gPiAgCj4gPiArc3RhdGlj IHZvaWQgbG9va3VwX3JlZl9idWZfaWR4KHN0cnVjdCBya3ZkZWNfY3R4ICpjdHgsCj4gPiArCQkJ ICAgICAgIHN0cnVjdCBya3ZkZWNfaDI2NF9ydW4gKnJ1bikKPiA+ICt7Cj4gPiArCWNvbnN0IHN0 cnVjdCB2NGwyX2N0cmxfaDI2NF9kZWNvZGVfcGFyYW1zICpkZWNfcGFyYW1zID0gcnVuLT5kZWNv ZGVfcGFyYW1zOwo+ID4gKwl1MzIgaTsKPiA+ICsKPiA+ICsJZm9yIChpID0gMDsgaSA8IEFSUkFZ X1NJWkUoZGVjX3BhcmFtcy0+ZHBiKTsgaSsrKSB7Cj4gPiArCQlzdHJ1Y3QgdjRsMl9tMm1fY3R4 ICptMm1fY3R4ID0gY3R4LT5maC5tMm1fY3R4Owo+ID4gKwkJY29uc3Qgc3RydWN0IHY0bDJfaDI2 NF9kcGJfZW50cnkgKmRwYiA9IHJ1bi0+ZGVjb2RlX3BhcmFtcy0+ZHBiOwo+ID4gKwkJc3RydWN0 IHZiMl9xdWV1ZSAqY2FwX3EgPSAmbTJtX2N0eC0+Y2FwX3FfY3R4LnE7Cj4gPiArCQlpbnQgYnVm X2lkeCA9IC0xOwo+ID4gKwo+ID4gKwkJaWYgKGRwYltpXS5mbGFncyAmIFY0TDJfSDI2NF9EUEJf RU5UUllfRkxBR19BQ1RJVkUpCj4gPiArCQkJYnVmX2lkeCA9IHZiMl9maW5kX3RpbWVzdGFtcChj YXBfcSwKPiA+ICsJCQkJCQkgICAgIGRwYltpXS5yZWZlcmVuY2VfdHMsIDApOwo+ID4gKwo+ID4g KwkJcnVuLT5yZWZfYnVmX2lkeFtpXSA9IGJ1Zl9pZHg7Cj4gPiArCX0KPiA+ICt9Cj4gPiArCj4g PiAgc3RhdGljIHZvaWQgYXNzZW1ibGVfaHdfcnBzKHN0cnVjdCBya3ZkZWNfY3R4ICpjdHgsCj4g PiAgCQkJICAgIHN0cnVjdCBya3ZkZWNfaDI2NF9ydW4gKnJ1bikKPiA+ICB7Cj4gPiBAQCAtNzYy LDcgKzc4Myw3IEBAIHN0YXRpYyB2b2lkIGFzc2VtYmxlX2h3X3JwcyhzdHJ1Y3Qgcmt2ZGVjX2N0 eCAqY3R4LAo+ID4gIAo+ID4gIAlmb3IgKGogPSAwOyBqIDwgUktWREVDX05VTV9SRUZMSVNUOyBq KyspIHsKPiA+ICAJCWZvciAoaSA9IDA7IGkgPCBoMjY0X2N0eC0+cmVmbGlzdHMubnVtX3ZhbGlk OyBpKyspIHsKPiA+IC0JCQl1OCBkcGJfdmFsaWQgPSAwOwo+ID4gKwkJCWJvb2wgZHBiX3ZhbGlk ID0gcnVuLT5yZWZfYnVmX2lkeFtpXSA+PSAwOwo+ID4gIAkJCXU4IGlkeCA9IDA7Cj4gPiAgCj4g PiAgCQkJc3dpdGNoIChqKSB7Cj4gPiBAQCAtNzc5LDggKzgwMCw2IEBAIHN0YXRpYyB2b2lkIGFz c2VtYmxlX2h3X3JwcyhzdHJ1Y3Qgcmt2ZGVjX2N0eCAqY3R4LAo+ID4gIAo+ID4gIAkJCWlmIChp ZHggPj0gQVJSQVlfU0laRShkZWNfcGFyYW1zLT5kcGIpKQo+ID4gIAkJCQljb250aW51ZTsKPiA+ IC0JCQlkcGJfdmFsaWQgPSAhIShkcGJbaWR4XS5mbGFncyAmCj4gPiAtCQkJCSAgICAgICBWNEwy X0gyNjRfRFBCX0VOVFJZX0ZMQUdfQUNUSVZFKTsKPiA+ICAKPiA+ICAJCQlzZXRfcHNfZmllbGQo aHdfcnBzLCBEUEJfSU5GTyhpLCBqKSwKPiA+ICAJCQkJICAgICBpZHggfCBkcGJfdmFsaWQgPDwg NCk7Cj4gPiBAQCAtODU5LDEzICs4NzgsOCBAQCBnZXRfcmVmX2J1ZihzdHJ1Y3Qgcmt2ZGVjX2N0 eCAqY3R4LCBzdHJ1Y3Qgcmt2ZGVjX2gyNjRfcnVuICpydW4sCj4gPiAgCSAgICB1bnNpZ25lZCBp bnQgZHBiX2lkeCkKPiA+ICB7Cj4gPiAgCXN0cnVjdCB2NGwyX20ybV9jdHggKm0ybV9jdHggPSBj dHgtPmZoLm0ybV9jdHg7Cj4gPiAtCWNvbnN0IHN0cnVjdCB2NGwyX2gyNjRfZHBiX2VudHJ5ICpk cGIgPSBydW4tPmRlY29kZV9wYXJhbXMtPmRwYjsKPiA+ICAJc3RydWN0IHZiMl9xdWV1ZSAqY2Fw X3EgPSAmbTJtX2N0eC0+Y2FwX3FfY3R4LnE7Cj4gPiAtCWludCBidWZfaWR4ID0gLTE7Cj4gPiAt Cj4gPiAtCWlmIChkcGJbZHBiX2lkeF0uZmxhZ3MgJiBWNEwyX0gyNjRfRFBCX0VOVFJZX0ZMQUdf QUNUSVZFKQo+ID4gLQkJYnVmX2lkeCA9IHZiMl9maW5kX3RpbWVzdGFtcChjYXBfcSwKPiA+IC0J CQkJCSAgICAgZHBiW2RwYl9pZHhdLnJlZmVyZW5jZV90cywgMCk7Cj4gPiArCWludCBidWZfaWR4 ID0gcnVuLT5yZWZfYnVmX2lkeFtkcGJfaWR4XTsKPiA+ICAKPiA+ICAJLyoKPiA+ICAJICogSWYg YSBEUEIgZW50cnkgaXMgdW51c2VkIG9yIGludmFsaWQsIGFkZHJlc3Mgb2YgY3VycmVudCBkZXN0 aW5hdGlvbgo+ID4gQEAgLTExMDIsNiArMTExNiw3IEBAIHN0YXRpYyBpbnQgcmt2ZGVjX2gyNjRf cnVuKHN0cnVjdCBya3ZkZWNfY3R4ICpjdHgpCj4gPiAgCj4gPiAgCWFzc2VtYmxlX2h3X3NjYWxp bmdfbGlzdChjdHgsICZydW4pOwo+ID4gIAlhc3NlbWJsZV9od19wcHMoY3R4LCAmcnVuKTsKPiA+ ICsJbG9va3VwX3JlZl9idWZfaWR4KGN0eCwgJnJ1bik7Cj4gPiAgCWFzc2VtYmxlX2h3X3Jwcyhj dHgsICZydW4pOwo+ID4gIAljb25maWdfcmVnaXN0ZXJzKGN0eCwgJnJ1bik7Cj4gPiAgCj4gPiAt LSAKPiA+IDIuMzQuMQo+ID4gCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTGludXgtcm9ja2NoaXAgbWFpbGluZyBsaXN0CkxpbnV4LXJvY2tjaGlwQGxp c3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0 aW5mby9saW51eC1yb2NrY2hpcAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8883A7A for ; Tue, 5 Apr 2022 15:11:15 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nicolas) with ESMTPSA id 14BC11F450DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1649171468; bh=D+PPyG+d8bSZBQUHvuUVVhH3F9DHPinWPY0RxBOGLSk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=fXHyX2PGLz0ROYpReWRUYVsjVnAwYs4vGBfotmSL/S9PIaEyt6ZIvhSApwIsBmKNq u5HY49fCocaxlJF+2UNGHXJdHdioG6Tbxdnd7Z/E0SAMQODKgYIzrLsMRI+gghk96s 5OLzd5Yt6pPZzXW+U8m1u+3hbk6iUTt9PWDaKT195nwD9pJE1GAafVEzuW6OuiCrY6 d+GKTUpMH3nsIEeGyC2tKIGM8RRuy5Dfm1JgzFP+S7vM7Kjj2slaYaFvlu4NZlXHmd Fjlf7E0rFIbcgVx+gQQji44T+NHsmwh6QRGBJXBGuqzo0Q7MQvYKvdexH6nzhfa7wL N6TFMwTeJ9ArQ== Message-ID: <92001085580ac1005596b34f79f1dadcc4b3f3c9.camel@collabora.com> Subject: Re: [PATCH v2 13/23] media: rkvdec: h264: Fix dpb_valid implementation From: Nicolas Dufresne To: Ezequiel Garcia Cc: Mauro Carvalho Chehab , Greg Kroah-Hartman , kernel@collabora.com, Sebastian Fricke , linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Date: Tue, 05 Apr 2022 11:10:57 -0400 In-Reply-To: References: <20220331193726.289559-1-nicolas.dufresne@collabora.com> <20220331193726.289559-14-nicolas.dufresne@collabora.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.0 (3.44.0-1.fc36) Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Le samedi 02 avril 2022 =C3=A0 08:16 -0300, Ezequiel Garcia a =C3=A9crit=C2= =A0: > On Thu, Mar 31, 2022 at 03:37:15PM -0400, Nicolas Dufresne wrote: > > The ref builder only provided references that are marked as valid in th= e > > dpb. Thus the current implementation of dpb_valid would always set the > > flag to 1. This is not representing missing frames (this is called > > 'non-existing' pictures in the spec). In some context, these non-existi= ng > > pictures still need to occupy a slot in the reference list according to > > the spec. > >=20 >=20 > Good catch! OOC, did you find this because it was failing a test vector? The effect is complex, so I could not correlate to specific tests. Also, wh= at I wanted to fix isn't covered by the ITU conformance, its mostly resiliance requirement. But this should remove some of the IOMMU fault on broken strea= ms and make it less likely to use references that don't exists or aren't set w= hat we expect. After this change, the driver was getting more stable, and resul= ts was also more reproducible (specially in parallel decode case, which I use = to speed up testing). >=20 > > Signed-off-by: Nicolas Dufresne > > Reviewed-by: Sebastian Fricke >=20 > Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") > Reviewed-by: Ezequiel Garcia Thanks for the review. >=20 > Thanks, > Ezequiel >=20 > > --- > > drivers/staging/media/rkvdec/rkvdec-h264.c | 33 ++++++++++++++++------ > > 1 file changed, 24 insertions(+), 9 deletions(-) > >=20 > > diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/stagi= ng/media/rkvdec/rkvdec-h264.c > > index dff89732ddd0..bcde37d72244 100644 > > --- a/drivers/staging/media/rkvdec/rkvdec-h264.c > > +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c > > @@ -112,6 +112,7 @@ struct rkvdec_h264_run { > > const struct v4l2_ctrl_h264_sps *sps; > > const struct v4l2_ctrl_h264_pps *pps; > > const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix; > > + int ref_buf_idx[V4L2_H264_NUM_DPB_ENTRIES]; > > }; > > =20 > > struct rkvdec_h264_ctx { > > @@ -725,6 +726,26 @@ static void assemble_hw_pps(struct rkvdec_ctx *ctx= , > > } > > } > > =20 > > +static void lookup_ref_buf_idx(struct rkvdec_ctx *ctx, > > + struct rkvdec_h264_run *run) > > +{ > > + const struct v4l2_ctrl_h264_decode_params *dec_params =3D run->decode= _params; > > + u32 i; > > + > > + for (i =3D 0; i < ARRAY_SIZE(dec_params->dpb); i++) { > > + struct v4l2_m2m_ctx *m2m_ctx =3D ctx->fh.m2m_ctx; > > + const struct v4l2_h264_dpb_entry *dpb =3D run->decode_params->dpb; > > + struct vb2_queue *cap_q =3D &m2m_ctx->cap_q_ctx.q; > > + int buf_idx =3D -1; > > + > > + if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE) > > + buf_idx =3D vb2_find_timestamp(cap_q, > > + dpb[i].reference_ts, 0); > > + > > + run->ref_buf_idx[i] =3D buf_idx; > > + } > > +} > > + > > static void assemble_hw_rps(struct rkvdec_ctx *ctx, > > struct rkvdec_h264_run *run) > > { > > @@ -762,7 +783,7 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx, > > =20 > > for (j =3D 0; j < RKVDEC_NUM_REFLIST; j++) { > > for (i =3D 0; i < h264_ctx->reflists.num_valid; i++) { > > - u8 dpb_valid =3D 0; > > + bool dpb_valid =3D run->ref_buf_idx[i] >=3D 0; > > u8 idx =3D 0; > > =20 > > switch (j) { > > @@ -779,8 +800,6 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx, > > =20 > > if (idx >=3D ARRAY_SIZE(dec_params->dpb)) > > continue; > > - dpb_valid =3D !!(dpb[idx].flags & > > - V4L2_H264_DPB_ENTRY_FLAG_ACTIVE); > > =20 > > set_ps_field(hw_rps, DPB_INFO(i, j), > > idx | dpb_valid << 4); > > @@ -859,13 +878,8 @@ get_ref_buf(struct rkvdec_ctx *ctx, struct rkvdec_= h264_run *run, > > unsigned int dpb_idx) > > { > > struct v4l2_m2m_ctx *m2m_ctx =3D ctx->fh.m2m_ctx; > > - const struct v4l2_h264_dpb_entry *dpb =3D run->decode_params->dpb; > > struct vb2_queue *cap_q =3D &m2m_ctx->cap_q_ctx.q; > > - int buf_idx =3D -1; > > - > > - if (dpb[dpb_idx].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE) > > - buf_idx =3D vb2_find_timestamp(cap_q, > > - dpb[dpb_idx].reference_ts, 0); > > + int buf_idx =3D run->ref_buf_idx[dpb_idx]; > > =20 > > /* > > * If a DPB entry is unused or invalid, address of current destinatio= n > > @@ -1102,6 +1116,7 @@ static int rkvdec_h264_run(struct rkvdec_ctx *ctx= ) > > =20 > > assemble_hw_scaling_list(ctx, &run); > > assemble_hw_pps(ctx, &run); > > + lookup_ref_buf_idx(ctx, &run); > > assemble_hw_rps(ctx, &run); > > config_registers(ctx, &run); > > =20 > > --=20 > > 2.34.1 > >=20