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=-16.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 0A137C43217 for ; Fri, 3 Sep 2021 12:42:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E94C0608FB for ; Fri, 3 Sep 2021 12:42:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348703AbhICMnT (ORCPT ); Fri, 3 Sep 2021 08:43:19 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:37774 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234950AbhICMnR (ORCPT ); Fri, 3 Sep 2021 08:43:17 -0400 Received: from [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4] (unknown [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dafna) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 860A91F44E0E; Fri, 3 Sep 2021 13:42:15 +0100 (BST) Subject: Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware 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 , Laurent Pinchart Cc: Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , 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 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> <20210901083215.25984-16-yunfei.dong@mediatek.com> <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> From: Dafna Hirschfeld Message-ID: <0100e846-7ab0-347e-c737-aa6d86fde4af@collabora.com> Date: Fri, 3 Sep 2021 14:42:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02.09.21 08:05, yunfei.dong@mediatek.com wrote: > On Wed, 2021-09-01 at 14:17 +0200, Dafna Hirschfeld wrote: > Hi Dafna, > > Thanks for your suggestion. >> Hi >> >> On 01.09.21 10:32, Yunfei Dong wrote: >>> There are just one core thread, in order to separeate different >>> hardware, using codec type to separeate it in scp driver. >> >> this code seems to relate to the vpu driver not the scp driver. >> Is there a corresponding code added to the vpu driver that test the >> codec_type? >> > Vpu is video processor unit, used to connect with micro processor. > In mt8173: vdec_vpu_if.c -> mtk_vpu.c -> micro processor > In mt8192/mt8183: vdec_vpu_if.c -> mtk_scp.c ->micro processor > > This init/dec start/dec_end interfaces are the same for vpu and scp. >>> >>> Signed-off-by: Yunfei Dong >>> --- >>> .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 >>> ++++++++++++++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++ >>> 3 files changed, 41 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> index 9d8079c4f976..c488f0c40190 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> @@ -35,6 +35,8 @@ enum vdec_ipi_msgid { >>> * @msg_id : vdec_ipi_msgid >>> * @vpu_inst_addr : VPU decoder instance address. Used if ABI >>> version < 2. >>> * @inst_id : instance ID. Used if the ABI version >= 2. >>> + * @codec_type : Codec fourcc >>> + * @reserved : reserved param >>> */ >>> struct vdec_ap_ipi_cmd { >>> uint32_t msg_id; >>> @@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd { >>> uint32_t vpu_inst_addr; >>> uint32_t inst_id; >>> }; >>> + uint32_t codec_type; >>> + uint32_t reserved; >>> }; >>> >>> /** >>> @@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack { >>> /** >>> * struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT >>> * @msg_id : AP_IPIMSG_DEC_INIT >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> * @ap_inst_addr : AP video decoder instance address >>> */ >>> struct vdec_ap_ipi_init { >>> uint32_t msg_id; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> uint64_t ap_inst_addr; >>> }; >>> >>> @@ -77,7 +81,7 @@ struct vdec_ap_ipi_init { >>> * H264 decoder [0]:buf_sz [1]:nal_start >>> * VP8 decoder [0]:width/height >>> * VP9 decoder [0]:profile, [1][2] width/height >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> */ >>> struct vdec_ap_ipi_dec_start { >>> uint32_t msg_id; >>> @@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start { >>> uint32_t inst_id; >>> }; >>> uint32_t data[3]; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> }; >>> >>> /** >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> index bfd8e87dceff..c84fac52fe26 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> @@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, >>> unsigned int len, void *priv) >>> >>> static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void >>> *msg, int len) >>> { >>> - int err; >>> + int err, id, msgid; >>> >>> - mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg); >>> + msgid = *(uint32_t *)msg; >>> + mtk_vcodec_debug(vpu, "id=%X", msgid); >>> >>> vpu->failure = 0; >>> vpu->signaled = 0; >>> >>> - err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu- >>>> id, msg, >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + if (msgid == AP_IPIMSG_DEC_CORE || >>> + msgid == AP_IPIMSG_DEC_CORE_END) >>> + id = vpu->core_id; >>> + else >>> + id = vpu->id; >>> + } else { >>> + id = vpu->id; >>> + } >>> + >>> + err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, >>> msg, >>> len, 2000); >> >> so >>> if (err) { >>> mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X >>> status=%d", >>> - vpu->id, *(uint32_t *)msg, err); >>> + id, msgid, err); >>> return err; >>> } >>> >>> @@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct >>> vdec_vpu_inst *vpu, unsigned int msg_id) >>> msg.vpu_inst_addr = vpu->inst_addr; >>> else >>> msg.inst_id = vpu->inst_id; >>> + msg.codec_type = vpu->codec_type; >>> >>> err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err); >>> @@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu) >>> >>> err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, >>> vpu->id, >>> vpu->handler, "vdec", NULL); >>> - if (err != 0) { >>> + if (err) { >> >> could be nice to send a patch with other such fixes, >> anyway it is better to send unrelated fixes in a separate patch >> > will fix in next patch. >>> mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", >>> err); >>> return err; >>> } >>> >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev- >>>> fw_handler, >>> + vpu->core_id, vpu->handler, >>> + "vdec", NULL); >>> + if (err) { >>> + mtk_vcodec_err(vpu, "vpu_ipi_register core fail >>> status=%d", err); >>> + return err; >>> + } >>> + } >>> + >>> memset(&msg, 0, sizeof(msg)); >>> msg.msg_id = AP_IPIMSG_DEC_INIT; >>> msg.ap_inst_addr = (unsigned long)vpu; >>> + msg.codec_type = vpu->codec_type; >>> >>> mtk_vcodec_debug(vpu, "vdec_inst=%p", vpu); >>> >>> @@ -187,6 +210,7 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, >>> uint32_t *data, unsigned int len) >>> >>> for (i = 0; i < len; i++) >>> msg.data[i] = data[i]; >>> + msg.codec_type = vpu->codec_type; >> >> I don't see where is the vpu->codec_type initialzied >> > This patch just add interface to support core hardware decode, in next > serial patches based on these will used codec type to separate after > these base patches are stable. Then why not send it on the same series? Thanks, Dafna >> Thanks, >> Dafna >> > Thanks > Yunfei Dong >>> >>> err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- ret=%d", err); >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> index ae24b75d1649..802660770a87 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> @@ -14,6 +14,7 @@ struct mtk_vcodec_ctx; >>> /** >>> * struct vdec_vpu_inst - VPU instance for video codec >>> * @id : ipi msg id for each decoder >>> + * @core_id : core id used to separate different hardware >>> * @vsi : driver structure allocated by VPU side and >>> shared to AP side >>> * for control and info share >>> * @failure : VPU execution result status, 0: success, >>> others: fail >>> @@ -26,9 +27,11 @@ struct mtk_vcodec_ctx; >>> * @dev : platform device of VPU >>> * @wq : wait queue to wait VPU message ack >>> * @handler : ipi handler for each decoder >>> + * @codec_type : used codec type to separate different codecs >>> */ >>> struct vdec_vpu_inst { >>> int id; >>> + int core_id; >>> void *vsi; >>> int32_t failure; >>> uint32_t inst_addr; >>> @@ -38,6 +41,7 @@ struct vdec_vpu_inst { >>> struct mtk_vcodec_ctx *ctx; >>> wait_queue_head_t wq; >>> mtk_vcodec_ipi_handler handler; >>> + unsigned int codec_type; >>> }; >>> >>> /** >>> 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=-16.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 4B856C433FE for ; Fri, 3 Sep 2021 12:42:47 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 10CEF608FB for ; Fri, 3 Sep 2021 12:42:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 10CEF608FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DyNOq7T55JS1jRx8nlclvy0tASzxgVAXp2SYII6/nq8=; b=cJxYDShNfdZGPUTa+PCJYbxbZT WgJZgC7NVgPzArk5hphzBSlwlydw3qeD7bhTzVvV/Lflyc4q7aO8r4DnErlox1SZYHBNHoxRrpqAG IQyOa06PX390FL7/J8JVfAcQBF5o1kf3W4qJpoLcNGVV1D6M7CahXNS0aQsjJ+6axnMuOZn4CWduK 3KV5UifKv7l/ETk91DF+Z4BZAdybHDgIdWl5R5XAIqT60Umy7ovjwDAw4tK5WEaKJpB9a3HCpcHNz G+W9Uf2Zbs8x4VbdeOQUixjgQzs0mIkKjr0EOdEyQuHcNc3LQEx+zMkE4n7KQTg3WSKkBizyaxc7/ 9tl1sTsw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM8We-00Bx6L-TL; Fri, 03 Sep 2021 12:42:32 +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 1mM8WR-00Bx3a-99; Fri, 03 Sep 2021 12:42:21 +0000 Received: from [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4] (unknown [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dafna) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 860A91F44E0E; Fri, 3 Sep 2021 13:42:15 +0100 (BST) Subject: Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware 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 , Laurent Pinchart Cc: Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , 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 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> <20210901083215.25984-16-yunfei.dong@mediatek.com> <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> From: Dafna Hirschfeld Message-ID: <0100e846-7ab0-347e-c737-aa6d86fde4af@collabora.com> Date: Fri, 3 Sep 2021 14:42:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210903_054219_615759_7AD3A652 X-CRM114-Status: GOOD ( 32.52 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On 02.09.21 08:05, yunfei.dong@mediatek.com wrote: > On Wed, 2021-09-01 at 14:17 +0200, Dafna Hirschfeld wrote: > Hi Dafna, > > Thanks for your suggestion. >> Hi >> >> On 01.09.21 10:32, Yunfei Dong wrote: >>> There are just one core thread, in order to separeate different >>> hardware, using codec type to separeate it in scp driver. >> >> this code seems to relate to the vpu driver not the scp driver. >> Is there a corresponding code added to the vpu driver that test the >> codec_type? >> > Vpu is video processor unit, used to connect with micro processor. > In mt8173: vdec_vpu_if.c -> mtk_vpu.c -> micro processor > In mt8192/mt8183: vdec_vpu_if.c -> mtk_scp.c ->micro processor > > This init/dec start/dec_end interfaces are the same for vpu and scp. >>> >>> Signed-off-by: Yunfei Dong >>> --- >>> .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 >>> ++++++++++++++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++ >>> 3 files changed, 41 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> index 9d8079c4f976..c488f0c40190 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> @@ -35,6 +35,8 @@ enum vdec_ipi_msgid { >>> * @msg_id : vdec_ipi_msgid >>> * @vpu_inst_addr : VPU decoder instance address. Used if ABI >>> version < 2. >>> * @inst_id : instance ID. Used if the ABI version >= 2. >>> + * @codec_type : Codec fourcc >>> + * @reserved : reserved param >>> */ >>> struct vdec_ap_ipi_cmd { >>> uint32_t msg_id; >>> @@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd { >>> uint32_t vpu_inst_addr; >>> uint32_t inst_id; >>> }; >>> + uint32_t codec_type; >>> + uint32_t reserved; >>> }; >>> >>> /** >>> @@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack { >>> /** >>> * struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT >>> * @msg_id : AP_IPIMSG_DEC_INIT >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> * @ap_inst_addr : AP video decoder instance address >>> */ >>> struct vdec_ap_ipi_init { >>> uint32_t msg_id; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> uint64_t ap_inst_addr; >>> }; >>> >>> @@ -77,7 +81,7 @@ struct vdec_ap_ipi_init { >>> * H264 decoder [0]:buf_sz [1]:nal_start >>> * VP8 decoder [0]:width/height >>> * VP9 decoder [0]:profile, [1][2] width/height >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> */ >>> struct vdec_ap_ipi_dec_start { >>> uint32_t msg_id; >>> @@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start { >>> uint32_t inst_id; >>> }; >>> uint32_t data[3]; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> }; >>> >>> /** >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> index bfd8e87dceff..c84fac52fe26 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> @@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, >>> unsigned int len, void *priv) >>> >>> static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void >>> *msg, int len) >>> { >>> - int err; >>> + int err, id, msgid; >>> >>> - mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg); >>> + msgid = *(uint32_t *)msg; >>> + mtk_vcodec_debug(vpu, "id=%X", msgid); >>> >>> vpu->failure = 0; >>> vpu->signaled = 0; >>> >>> - err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu- >>>> id, msg, >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + if (msgid == AP_IPIMSG_DEC_CORE || >>> + msgid == AP_IPIMSG_DEC_CORE_END) >>> + id = vpu->core_id; >>> + else >>> + id = vpu->id; >>> + } else { >>> + id = vpu->id; >>> + } >>> + >>> + err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, >>> msg, >>> len, 2000); >> >> so >>> if (err) { >>> mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X >>> status=%d", >>> - vpu->id, *(uint32_t *)msg, err); >>> + id, msgid, err); >>> return err; >>> } >>> >>> @@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct >>> vdec_vpu_inst *vpu, unsigned int msg_id) >>> msg.vpu_inst_addr = vpu->inst_addr; >>> else >>> msg.inst_id = vpu->inst_id; >>> + msg.codec_type = vpu->codec_type; >>> >>> err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err); >>> @@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu) >>> >>> err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, >>> vpu->id, >>> vpu->handler, "vdec", NULL); >>> - if (err != 0) { >>> + if (err) { >> >> could be nice to send a patch with other such fixes, >> anyway it is better to send unrelated fixes in a separate patch >> > will fix in next patch. >>> mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", >>> err); >>> return err; >>> } >>> >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev- >>>> fw_handler, >>> + vpu->core_id, vpu->handler, >>> + "vdec", NULL); >>> + if (err) { >>> + mtk_vcodec_err(vpu, "vpu_ipi_register core fail >>> status=%d", err); >>> + return err; >>> + } >>> + } >>> + >>> memset(&msg, 0, sizeof(msg)); >>> msg.msg_id = AP_IPIMSG_DEC_INIT; >>> msg.ap_inst_addr = (unsigned long)vpu; >>> + msg.codec_type = vpu->codec_type; >>> >>> mtk_vcodec_debug(vpu, "vdec_inst=%p", vpu); >>> >>> @@ -187,6 +210,7 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, >>> uint32_t *data, unsigned int len) >>> >>> for (i = 0; i < len; i++) >>> msg.data[i] = data[i]; >>> + msg.codec_type = vpu->codec_type; >> >> I don't see where is the vpu->codec_type initialzied >> > This patch just add interface to support core hardware decode, in next > serial patches based on these will used codec type to separate after > these base patches are stable. Then why not send it on the same series? Thanks, Dafna >> Thanks, >> Dafna >> > Thanks > Yunfei Dong >>> >>> err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- ret=%d", err); >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> index ae24b75d1649..802660770a87 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> @@ -14,6 +14,7 @@ struct mtk_vcodec_ctx; >>> /** >>> * struct vdec_vpu_inst - VPU instance for video codec >>> * @id : ipi msg id for each decoder >>> + * @core_id : core id used to separate different hardware >>> * @vsi : driver structure allocated by VPU side and >>> shared to AP side >>> * for control and info share >>> * @failure : VPU execution result status, 0: success, >>> others: fail >>> @@ -26,9 +27,11 @@ struct mtk_vcodec_ctx; >>> * @dev : platform device of VPU >>> * @wq : wait queue to wait VPU message ack >>> * @handler : ipi handler for each decoder >>> + * @codec_type : used codec type to separate different codecs >>> */ >>> struct vdec_vpu_inst { >>> int id; >>> + int core_id; >>> void *vsi; >>> int32_t failure; >>> uint32_t inst_addr; >>> @@ -38,6 +41,7 @@ struct vdec_vpu_inst { >>> struct mtk_vcodec_ctx *ctx; >>> wait_queue_head_t wq; >>> mtk_vcodec_ipi_handler handler; >>> + unsigned int codec_type; >>> }; >>> >>> /** >>> _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-16.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 CFC8DC433EF for ; Fri, 3 Sep 2021 12:44:11 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 8C22B61057 for ; Fri, 3 Sep 2021 12:44:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8C22B61057 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=A8u6xVh24Y0EEMlodfivSnuZbA9ZJQ4zXh4ZZGLYgWA=; b=YPgdsC46NAW15753MeO7qSasZL sKZo2AghheY/PIEEXLjKhYDNsi8aWCRA43tv8kjQD2X9BpOwpAdyBPDBYdCvBWfm0NNCIa+rX/84n GuUdEUyTz3lwNymIL9S7N8S2bGFzKBhHCSfwKrZhuBY1d6oYb6IqEee8oMw/FtF25Yv9d45U2oZn4 pW6O0dNwXr5Kxi55AuWARaJAztcmvbPKr41aVyQNCrh3KxzsXa9tYkPcGeDmNWoa8tBkTwmUpGxi8 YoPhTUyr3ooc5l+q5nEW44xSyn//zn9RMikGjuvwvHaIusZ5vHzdZR806876chJ6/7Pp09dInh9Mm sI2Ux3zQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM8WV-00Bx4v-Nk; Fri, 03 Sep 2021 12:42:23 +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 1mM8WR-00Bx3a-99; Fri, 03 Sep 2021 12:42:21 +0000 Received: from [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4] (unknown [IPv6:2a02:810a:880:f54:14f0:9e83:10c6:d1a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dafna) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 860A91F44E0E; Fri, 3 Sep 2021 13:42:15 +0100 (BST) Subject: Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware 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 , Laurent Pinchart Cc: Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , 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 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> <20210901083215.25984-16-yunfei.dong@mediatek.com> <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> From: Dafna Hirschfeld Message-ID: <0100e846-7ab0-347e-c737-aa6d86fde4af@collabora.com> Date: Fri, 3 Sep 2021 14:42:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5d53649c1fe2d6d6942e1dd31cdf7a0def46acab.camel@mediatek.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210903_054219_615759_7AD3A652 X-CRM114-Status: GOOD ( 32.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 02.09.21 08:05, yunfei.dong@mediatek.com wrote: > On Wed, 2021-09-01 at 14:17 +0200, Dafna Hirschfeld wrote: > Hi Dafna, > > Thanks for your suggestion. >> Hi >> >> On 01.09.21 10:32, Yunfei Dong wrote: >>> There are just one core thread, in order to separeate different >>> hardware, using codec type to separeate it in scp driver. >> >> this code seems to relate to the vpu driver not the scp driver. >> Is there a corresponding code added to the vpu driver that test the >> codec_type? >> > Vpu is video processor unit, used to connect with micro processor. > In mt8173: vdec_vpu_if.c -> mtk_vpu.c -> micro processor > In mt8192/mt8183: vdec_vpu_if.c -> mtk_scp.c ->micro processor > > This init/dec start/dec_end interfaces are the same for vpu and scp. >>> >>> Signed-off-by: Yunfei Dong >>> --- >>> .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 >>> ++++++++++++++++--- >>> .../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++ >>> 3 files changed, 41 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> index 9d8079c4f976..c488f0c40190 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h >>> @@ -35,6 +35,8 @@ enum vdec_ipi_msgid { >>> * @msg_id : vdec_ipi_msgid >>> * @vpu_inst_addr : VPU decoder instance address. Used if ABI >>> version < 2. >>> * @inst_id : instance ID. Used if the ABI version >= 2. >>> + * @codec_type : Codec fourcc >>> + * @reserved : reserved param >>> */ >>> struct vdec_ap_ipi_cmd { >>> uint32_t msg_id; >>> @@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd { >>> uint32_t vpu_inst_addr; >>> uint32_t inst_id; >>> }; >>> + uint32_t codec_type; >>> + uint32_t reserved; >>> }; >>> >>> /** >>> @@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack { >>> /** >>> * struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT >>> * @msg_id : AP_IPIMSG_DEC_INIT >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> * @ap_inst_addr : AP video decoder instance address >>> */ >>> struct vdec_ap_ipi_init { >>> uint32_t msg_id; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> uint64_t ap_inst_addr; >>> }; >>> >>> @@ -77,7 +81,7 @@ struct vdec_ap_ipi_init { >>> * H264 decoder [0]:buf_sz [1]:nal_start >>> * VP8 decoder [0]:width/height >>> * VP9 decoder [0]:profile, [1][2] width/height >>> - * @reserved : Reserved field >>> + * @codec_type : Codec fourcc >>> */ >>> struct vdec_ap_ipi_dec_start { >>> uint32_t msg_id; >>> @@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start { >>> uint32_t inst_id; >>> }; >>> uint32_t data[3]; >>> - uint32_t reserved; >>> + uint32_t codec_type; >>> }; >>> >>> /** >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> index bfd8e87dceff..c84fac52fe26 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c >>> @@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, >>> unsigned int len, void *priv) >>> >>> static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void >>> *msg, int len) >>> { >>> - int err; >>> + int err, id, msgid; >>> >>> - mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg); >>> + msgid = *(uint32_t *)msg; >>> + mtk_vcodec_debug(vpu, "id=%X", msgid); >>> >>> vpu->failure = 0; >>> vpu->signaled = 0; >>> >>> - err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu- >>>> id, msg, >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + if (msgid == AP_IPIMSG_DEC_CORE || >>> + msgid == AP_IPIMSG_DEC_CORE_END) >>> + id = vpu->core_id; >>> + else >>> + id = vpu->id; >>> + } else { >>> + id = vpu->id; >>> + } >>> + >>> + err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, >>> msg, >>> len, 2000); >> >> so >>> if (err) { >>> mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X >>> status=%d", >>> - vpu->id, *(uint32_t *)msg, err); >>> + id, msgid, err); >>> return err; >>> } >>> >>> @@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct >>> vdec_vpu_inst *vpu, unsigned int msg_id) >>> msg.vpu_inst_addr = vpu->inst_addr; >>> else >>> msg.inst_id = vpu->inst_id; >>> + msg.codec_type = vpu->codec_type; >>> >>> err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err); >>> @@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu) >>> >>> err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, >>> vpu->id, >>> vpu->handler, "vdec", NULL); >>> - if (err != 0) { >>> + if (err) { >> >> could be nice to send a patch with other such fixes, >> anyway it is better to send unrelated fixes in a separate patch >> > will fix in next patch. >>> mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", >>> err); >>> return err; >>> } >>> >>> + if (vpu->ctx->dev->vdec_pdata->hw_arch == >>> MTK_VDEC_LAT_SINGLE_CORE) { >>> + err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev- >>>> fw_handler, >>> + vpu->core_id, vpu->handler, >>> + "vdec", NULL); >>> + if (err) { >>> + mtk_vcodec_err(vpu, "vpu_ipi_register core fail >>> status=%d", err); >>> + return err; >>> + } >>> + } >>> + >>> memset(&msg, 0, sizeof(msg)); >>> msg.msg_id = AP_IPIMSG_DEC_INIT; >>> msg.ap_inst_addr = (unsigned long)vpu; >>> + msg.codec_type = vpu->codec_type; >>> >>> mtk_vcodec_debug(vpu, "vdec_inst=%p", vpu); >>> >>> @@ -187,6 +210,7 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, >>> uint32_t *data, unsigned int len) >>> >>> for (i = 0; i < len; i++) >>> msg.data[i] = data[i]; >>> + msg.codec_type = vpu->codec_type; >> >> I don't see where is the vpu->codec_type initialzied >> > This patch just add interface to support core hardware decode, in next > serial patches based on these will used codec type to separate after > these base patches are stable. Then why not send it on the same series? Thanks, Dafna >> Thanks, >> Dafna >> > Thanks > Yunfei Dong >>> >>> err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg)); >>> mtk_vcodec_debug(vpu, "- ret=%d", err); >>> diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> index ae24b75d1649..802660770a87 100644 >>> --- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> +++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h >>> @@ -14,6 +14,7 @@ struct mtk_vcodec_ctx; >>> /** >>> * struct vdec_vpu_inst - VPU instance for video codec >>> * @id : ipi msg id for each decoder >>> + * @core_id : core id used to separate different hardware >>> * @vsi : driver structure allocated by VPU side and >>> shared to AP side >>> * for control and info share >>> * @failure : VPU execution result status, 0: success, >>> others: fail >>> @@ -26,9 +27,11 @@ struct mtk_vcodec_ctx; >>> * @dev : platform device of VPU >>> * @wq : wait queue to wait VPU message ack >>> * @handler : ipi handler for each decoder >>> + * @codec_type : used codec type to separate different codecs >>> */ >>> struct vdec_vpu_inst { >>> int id; >>> + int core_id; >>> void *vsi; >>> int32_t failure; >>> uint32_t inst_addr; >>> @@ -38,6 +41,7 @@ struct vdec_vpu_inst { >>> struct mtk_vcodec_ctx *ctx; >>> wait_queue_head_t wq; >>> mtk_vcodec_ipi_handler handler; >>> + unsigned int codec_type; >>> }; >>> >>> /** >>> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel