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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96DE3C4332F for ; Thu, 17 Feb 2022 14:44:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242016AbiBQOoR (ORCPT ); Thu, 17 Feb 2022 09:44:17 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232351AbiBQOoP (ORCPT ); Thu, 17 Feb 2022 09:44:15 -0500 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB345207FF3 for ; Thu, 17 Feb 2022 06:44:00 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id q4so3512964qki.11 for ; Thu, 17 Feb 2022 06:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=7Dm8/9xh+wmDmQBhMFT43NJgXO5tbOXeBqNcPHzywpk=; b=ZICFIWA9Sbi45aOvx4dcDKut/wdPr6VMVnR4U4cb/kJNSc5ETL1ImhYOA8svydp4va RzN0pqQOm5Dq4JA7d4pON7G9eyLMCXEsZuWHjnT9Fj9mCm+TUeulRj9lF2p9y2RbrWcw Zdpbnbp0nBhk0+kYOrKKXdR396nWX9LG40kL5OO0Sx5HRmFULTOjGINNiVDkIXxd4+xP TOWJ3oYmeQRu60z0DluHgDjZgUZAXTPIUOGK3h/aHozSzMAyMRLTYmepfzaIg3ggnHGr dP2iJfjIiPWmJy73uFUWoYnY+wyUm1t2ktREy2fqVLd/EgvXbdq9nYV+GFUVOklwgQKe rgsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=7Dm8/9xh+wmDmQBhMFT43NJgXO5tbOXeBqNcPHzywpk=; b=b+rgCkwfRi0q5MqhMXCP0IRSEHszMNHqqwG5+ZBX0yD149QlL5Xb1GqKIE+7gRXRHF zD6jIValmlLJ/fdIvHFsJMHndgWvLCUKk9Z5fo5SD7G+q0+6SjuTQIzE1T2ekEaDafNR LWLJUJuYR91UyDAo0PE8UreXTjhBvkvGJCoQl2IdPMXqWSFawdfvAit5iNRMv3VlF+vR rqV0Z8zzGu2SIKwnH/aOkeHFmVnUqLJWYdfHps4lo0F9lIVJvyGuqIwzYStSKdb+dI6e lGg0CuTrcr8FFjyVyjm+/mh1Yqso0++XMueguagtGIcZOP0U1aYi/hwet5bROX2hP89U /gCQ== X-Gm-Message-State: AOAM531FPt9ALF/dzGJY78U1Z0VbOxuYK+MekzPwq4meFDSMtU++eQD1 Qqe87puLfbcV/Ki47O/Vs0fKCg== X-Google-Smtp-Source: ABdhPJxLj1ldRMkUKspCf3+BTfjxi/lSWLS/APEjil4eZvdWbgL26ckX1Mt84cdeQha/7dTmRgmWsw== X-Received: by 2002:ae9:edc6:0:b0:60c:8807:712f with SMTP id c189-20020ae9edc6000000b0060c8807712fmr1821761qkg.14.1645109039947; Thu, 17 Feb 2022 06:43:59 -0800 (PST) Received: from nicolas-tpx395.localdomain (173-246-12-168.qc.cable.ebox.net. [173.246.12.168]) by smtp.gmail.com with ESMTPSA id h19sm13099450qtx.12.2022.02.17.06.43.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 06:43:59 -0800 (PST) Message-ID: <20a43338009164be793abb9fedd002f2e4c9a293.camel@ndufresne.ca> Subject: Re: [PATCH v6, 06/15] media: mtk-vcodec: Refactor get and put capture buffer flow From: Nicolas Dufresne To: "yunfei.dong@mediatek.com" , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa Cc: George Sun , Xiaoyong Lu , Hsin-Yi Wang , Fritz Koenig , Dafna Hirschfeld , Benjamin Gaignard , Daniel Vetter , dri-devel , Irui Wang , AngeloGioacchino Del Regno , Steve Cho , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Date: Thu, 17 Feb 2022 09:43:54 -0500 In-Reply-To: <353328c24f92a0690c8461a9b18c62166b769a40.camel@mediatek.com> References: <20220122035316.18179-1-yunfei.dong@mediatek.com> <20220122035316.18179-7-yunfei.dong@mediatek.com> <353328c24f92a0690c8461a9b18c62166b769a40.camel@mediatek.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.3 (3.42.3-1.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le jeudi 17 février 2022 à 17:03 +0800, yunfei.dong@mediatek.com a écrit : > > > - ret = vdec_if_decode(ctx, bs_src, dst_buf, &res_chg); > > > + ret = vdec_if_decode(ctx, bs_src, NULL, &res_chg); > > >    if (ret) { > > >    mtk_v4l2_err(" <===[%d], src_buf[%d] sz=0x%zx pts=%llu > > > vdec_if_decode() ret=%d res_chg=%d===>", > > >         ctx->id, vb2_src->index, bs_src->size, > > > @@ -220,12 +266,9 @@ static void mtk_vdec_worker(struct work_struct > > > *work) > > >    } > > >    } > > >   > > > - mtk_vdec_stateless_set_dst_payload(ctx, dst_buf); > > > - > > > - v4l2_m2m_buf_done_and_job_finish(dev->m2m_dev_dec, ctx- > > > > m2m_ctx, > > > - ret ? VB2_BUF_STATE_ERROR : > > > VB2_BUF_STATE_DONE); > > > - > > > + mtk_vdec_stateless_out_to_done(ctx, bs_src, ret); > > > > v4l2_m2m_buf_done_and_job_finish() was specially crafted to prevent > > developer > > from implementing the signalling of the request at the wrong moment. > > This patch > > broke this strict ordering. The relevant comment in the helper > > function: > > > > > As we discussed in chat, please help to check whether it's possible to > let lat and core decode in parallel. Thanks, Benjamin is looking into that. For the mailing list here, here's some prior art for a similar problem found by downstream RPi4 HEVC driver developer. The general problem here is that we don't want to signal the request until the decode have complete, yet we want to pick and run second (concurrent job) so that parallel decoding is made possible. For RPi4 it is not multi-core, but the decoding is split in 2 stages, and the decoder run both stages concurrently, which basically means, we need to be able to run two jobs at the same time whenever possible. https://github.com/raspberrypi/linux/commit/964be1d20e2f1335915a6bf8c82a3199bfddf8ac This introduce media_request_pin/unpin, but being able to pin a request and not have it bound to any other object lifetime anymore seems a bit error prone in comparison to the current restrictions. Comments welcome ! > > I will continue to fix h264 issue. Thanks. > > Thanks for your help. > > Best Regards, > Yunfei Dong