Message ID | 20230228-topic-venus-v2-6-d95d14949c79@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp138342vqo; Thu, 4 May 2023 01:14:40 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6RPPLe0oDEhHk0Y4EVGrWHHu5XpBTjkvzdHKXqtK9ClYxjmhGFxhyRYnVqJbIgohcvBOg5 X-Received: by 2002:a05:6a00:10d4:b0:63b:5c82:e21a with SMTP id d20-20020a056a0010d400b0063b5c82e21amr1525644pfu.1.1683188079900; Thu, 04 May 2023 01:14:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683188079; cv=none; d=google.com; s=arc-20160816; b=H7cSm8NtHU5gyq4+MlBIdcqoSPC3FKUmCzhB1l78dPAqw7KUAhBePa67ulTOIp35H/ EPcMn3etCr/tRJKXj4Woanq+AnTVuNtGEsLIIvzJozJ8oCFzLDI+k+IUQgkt/AzqxdRI wmK8dyh4/pqX5SFiibm6ArMfbCUHye6p380vmCIDBFIvOEOZCXGQQ+4Xh7tiN+TUvntS +jfnkoNboBU49TMMW5N0PJkVD8H8rlFObXBOQ3WGx1tcj7comLZVZw4ptHWlYVpJLGm+ VRffaJIOohfPOZzmxH3CUKNgtPh8WtsdFK5l7c3Hjv2fbO782CCDd3dAR3YC6pZjawGe IuDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=pHuJqh6clnMhDFgSRdYKRfsY4OFox3kTZVS9qASymWE=; b=E/OqJMeT7iTIu6XcH0CGerbBTeOnmAY0tUFbiNTLq8DNo+K0Zhvlk+MbW3+byAtZKr Qhw9d6Ib5pvT8qE5r/Ne5sN4L0adYO7JPBJyHx4wCImPwAtfrw8Y9Y2ButIbpK+CAWZA +8wozzSx+Vq3xjCFGsaalY7uCdDkomCUYIozs/cGiDdD62GIYGXpo4usTwf9TzPemteK S0KkxVCpY6u8h+bNiVfcpsgdUr+CRE6ZALq0ZApNNvcfEwCykdHeviehd2FYu2n0pE3G Yl3Klg2nbfSEWjg0ajg9Gc5Wgar/B90qA43hWEEuJvzk9mSpDRrxAVb1jrGpR8sR31RN ULuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=zUipfNWa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g14-20020a62520e000000b00640f213b6fesi21809586pfb.240.2023.05.04.01.14.25; Thu, 04 May 2023 01:14:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=zUipfNWa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230158AbjEDICB (ORCPT <rfc822;lhua1029@gmail.com> + 99 others); Thu, 4 May 2023 04:02:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229988AbjEDIBk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 4 May 2023 04:01:40 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1C863ABF for <linux-kernel@vger.kernel.org>; Thu, 4 May 2023 01:01:36 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4eff50911bfso178773e87.2 for <linux-kernel@vger.kernel.org>; Thu, 04 May 2023 01:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683187295; x=1685779295; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=pHuJqh6clnMhDFgSRdYKRfsY4OFox3kTZVS9qASymWE=; b=zUipfNWaazL6ADynZcrfI01DUbRNogvA6LUhNvy2poxcQQzU2Jpsb0ktYJC/nSpVFf DkqZSLSzujw/tun5InCQmu35+nV9qnAWVgoGQlOzqQqBMgpw//jzw2E/3xRqDvQ0W91y KaEuNlbZYNYmCO+QChSO4QTI36SicJPWc33Z01H57/lVqzQNH90zBipn4cfencFclMqz KkhcRtp4zyHBFgl3MlqCvU5dvDQ9C8rrbPMR7aHzZaUvUhg48RwhHcK5CcYfG3UdvHuY FNyXAMDHDisRWW2jQifShPgdk61CGuq17aL9bRnNk1V5QX8nlnvsBPlzJ+gJtH80ixOz wPwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683187295; x=1685779295; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pHuJqh6clnMhDFgSRdYKRfsY4OFox3kTZVS9qASymWE=; b=Np79NfvvFN9O/0PWzeCpwRfSg49xNAhlBWANbs/mQn5U2ue24A8kuLi3k2d2mHkWIF 412MgPV0o36VtSENA8heuh8Wo+lQaLgmGGKZHe+itWxLgvcluTruifri/L8YauwPRWKP CZdNo3b18MSd+U7XgI8kG7jqXuFR3hINkA5eZGzs1rOp7n2EIq4qC8bDJueel2g6Qs9b M2dBQuGwYGOKcJSawByeiGTIhLEPxzDw9oJWvd/QTfECkUW/nsuz7Oh0feQjMInSG3t4 c95imSaikHeGl8ocye2uVDg5zdrDPZcA9MhUCEcAuqf9Rztpm3tGG0pC9cO0KBly43hY MBsg== X-Gm-Message-State: AC+VfDzoR6UMkL8eYjl+G1m7OcdBnjV4m7WADj27HrjymGwJcvVHV35N SJDUY67gkLY28fmJ92zO0RuzkA== X-Received: by 2002:a19:7503:0:b0:4f0:4b:538f with SMTP id y3-20020a197503000000b004f0004b538fmr1601126lfe.29.1683187295132; Thu, 04 May 2023 01:01:35 -0700 (PDT) Received: from [192.168.1.101] (abyl248.neoplus.adsl.tpnet.pl. [83.9.31.248]) by smtp.gmail.com with ESMTPSA id n26-20020ac2491a000000b004edc512515fsm917165lfi.47.2023.05.04.01.01.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 01:01:34 -0700 (PDT) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Thu, 04 May 2023 10:01:02 +0200 Subject: [PATCH v2 06/18] media: venus: firmware: Leave a clue for homegrown porters MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230228-topic-venus-v2-6-d95d14949c79@linaro.org> References: <20230228-topic-venus-v2-0-d95d14949c79@linaro.org> In-Reply-To: <20230228-topic-venus-v2-0-d95d14949c79@linaro.org> To: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>, Vikash Garodia <quic_vgarodia@quicinc.com>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Dikshita Agarwal <dikshita@qti.qualcomm.com>, Bryan O'Donoghue <bryan.odonoghue@linaro.org>, Mansur Alisha Shaik <mansur@codeaurora.org>, Jonathan Marek <jonathan@marek.ca>, Hans Verkuil <hans.verkuil@cisco.com>, Dikshita Agarwal <quic_dikshita@quicinc.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Stanimir Varbanov <stanimir.varbanov@linaro.org>, linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Marijn Suijten <marijn.suijten@somainline.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Vikash Garodia <quic_vgarodia@quicinc.com> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1683187284; l=1135; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=EgjRQOY12/YgIbWH62eZ5y8nBX3H3pJik8G0F4SYRFY=; b=nQEw2k9F74MAxmf470Mil8wFjXEeWKtb4BAhs5r6xj+O8SHhrmSmWKpItUFOnSd0pmnBcqWBf EfAAgrecd0rDMOpthvvcK/aABUI8hm23nzqEXoXqbALT36JM+Qmn8SL X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764950623974192766?= X-GMAIL-MSGID: =?utf-8?q?1764950623974192766?= |
Series |
Venus QoL / maintainability fixes
|
|
Commit Message
Konrad Dybcio
May 4, 2023, 8:01 a.m. UTC
Leave a clue about where the seemingly magic values come from, as it is not obvious and requires some digging downstream.. Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> --- drivers/media/platform/qcom/venus/firmware.c | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
On 5/4/2023 1:31 PM, Konrad Dybcio wrote: > Leave a clue about where the seemingly magic values come from, as it > is not obvious and requires some digging downstream.. > > Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> > --- > drivers/media/platform/qcom/venus/firmware.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c > index cfb11c551167..a4cd919e1dbe 100644 > --- a/drivers/media/platform/qcom/venus/firmware.c > +++ b/drivers/media/platform/qcom/venus/firmware.c > @@ -241,6 +241,13 @@ int venus_boot(struct venus_core *core) > return ret; > > if (core->use_tz && res->cp_size) { > + /* > + * Clues for porting using downstream data: > + * cp_start = 0 > + * cp_size = venus_ns/virtual-addr-pool[0] (yes, addr not size) The field is the start address of ns context bank. Since the cp_start is 0, the start address for (next) non-secure context bank is interpreted as size of the (previous) content protection region. > + * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0] > + * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1] > + */ > ret = qcom_scm_mem_protect_video_var(res->cp_start, > res->cp_size, > res->cp_nonpixel_start, >
On 5/5/2023 6:27 PM, Vikash Garodia wrote: > > On 5/4/2023 1:31 PM, Konrad Dybcio wrote: >> Leave a clue about where the seemingly magic values come from, as it >> is not obvious and requires some digging downstream.. Rephrase the commit text. >> Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> >> --- >> drivers/media/platform/qcom/venus/firmware.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/media/platform/qcom/venus/firmware.c >> b/drivers/media/platform/qcom/venus/firmware.c >> index cfb11c551167..a4cd919e1dbe 100644 >> --- a/drivers/media/platform/qcom/venus/firmware.c >> +++ b/drivers/media/platform/qcom/venus/firmware.c >> @@ -241,6 +241,13 @@ int venus_boot(struct venus_core *core) >> return ret; >> if (core->use_tz && res->cp_size) { >> + /* >> + * Clues for porting using downstream data: >> + * cp_start = 0 >> + * cp_size = venus_ns/virtual-addr-pool[0] (yes, addr not size) > > The field is the start address of ns context bank. Since the cp_start > is 0, the start address for (next) non-secure context bank > > is interpreted as size of the (previous) content protection region. > >> + * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0] >> + * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1] >> + */ >> ret = qcom_scm_mem_protect_video_var(res->cp_start, >> res->cp_size, >> res->cp_nonpixel_start, >>
On 5.05.2023 15:00, Vikash Garodia wrote: > > On 5/5/2023 6:27 PM, Vikash Garodia wrote: >> >> On 5/4/2023 1:31 PM, Konrad Dybcio wrote: >>> Leave a clue about where the seemingly magic values come from, as it >>> is not obvious and requires some digging downstream.. > Rephrase the commit text. Please be more specific, do you want me to use the explanations you gave in the previous reply? Konrad >>> Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> >>> --- >>> drivers/media/platform/qcom/venus/firmware.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c >>> index cfb11c551167..a4cd919e1dbe 100644 >>> --- a/drivers/media/platform/qcom/venus/firmware.c >>> +++ b/drivers/media/platform/qcom/venus/firmware.c >>> @@ -241,6 +241,13 @@ int venus_boot(struct venus_core *core) >>> return ret; >>> if (core->use_tz && res->cp_size) { >>> + /* >>> + * Clues for porting using downstream data: >>> + * cp_start = 0 >>> + * cp_size = venus_ns/virtual-addr-pool[0] (yes, addr not size) >> >> The field is the start address of ns context bank. Since the cp_start is 0, the start address for (next) non-secure context bank >> >> is interpreted as size of the (previous) content protection region. >> >>> + * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0] >>> + * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1] >>> + */ >>> ret = qcom_scm_mem_protect_video_var(res->cp_start, >>> res->cp_size, >>> res->cp_nonpixel_start, >>>
On 5/6/2023 12:54 AM, Konrad Dybcio wrote: > > > On 5.05.2023 15:00, Vikash Garodia wrote: >> >> On 5/5/2023 6:27 PM, Vikash Garodia wrote: >>> >>> On 5/4/2023 1:31 PM, Konrad Dybcio wrote: >>>> Leave a clue about where the seemingly magic values come from, as it >>>> is not obvious and requires some digging downstream.. >> Rephrase the commit text. > Please be more specific, do you want me to use the > explanations you gave in the previous reply? Something which describes the patch like - Add comments to describe the arguments of the qcom_scm_mem_protect_video_var TZ call. The TZ call programs the video hardware with CP and non-CP VARs, and the comments describes these VARs. > Konrad >>>> Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com> >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>> Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com> >>>> --- >>>> drivers/media/platform/qcom/venus/firmware.c | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c >>>> index cfb11c551167..a4cd919e1dbe 100644 >>>> --- a/drivers/media/platform/qcom/venus/firmware.c >>>> +++ b/drivers/media/platform/qcom/venus/firmware.c >>>> @@ -241,6 +241,13 @@ int venus_boot(struct venus_core *core) >>>> return ret; >>>> if (core->use_tz && res->cp_size) { >>>> + /* >>>> + * Clues for porting using downstream data: >>>> + * cp_start = 0 >>>> + * cp_size = venus_ns/virtual-addr-pool[0] (yes, addr not size) >>> >>> The field is the start address of ns context bank. Since the cp_start is 0, the start address for (next) non-secure context bank >>> >>> is interpreted as size of the (previous) content protection region. >>> >>>> + * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0] >>>> + * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1] >>>> + */ >>>> ret = qcom_scm_mem_protect_video_var(res->cp_start, >>>> res->cp_size, >>>> res->cp_nonpixel_start, >>>>
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c index cfb11c551167..a4cd919e1dbe 100644 --- a/drivers/media/platform/qcom/venus/firmware.c +++ b/drivers/media/platform/qcom/venus/firmware.c @@ -241,6 +241,13 @@ int venus_boot(struct venus_core *core) return ret; if (core->use_tz && res->cp_size) { + /* + * Clues for porting using downstream data: + * cp_start = 0 + * cp_size = venus_ns/virtual-addr-pool[0] (yes, addr not size) + * cp_nonpixel_start = venus_sec_non_pixel/virtual-addr-pool[0] + * cp_nonpixel_size = venus_sec_non_pixel/virtual-addr-pool[1] + */ ret = qcom_scm_mem_protect_video_var(res->cp_start, res->cp_size, res->cp_nonpixel_start,