Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp1368082rdb; Tue, 30 Jan 2024 17:06:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IENCwNjvK8Qtqn6bx5K3E2GbfhMMErdwW3WEQhRvDC5JJBLdAyQ9qdEIUNXA3gYecb2T28Q X-Received: by 2002:a05:6a20:e18d:b0:19a:b7e4:b42a with SMTP id ks13-20020a056a20e18d00b0019ab7e4b42amr101200pzb.40.1706663183808; Tue, 30 Jan 2024 17:06:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706663183; cv=pass; d=google.com; s=arc-20160816; b=WhlLgzWV8QsHv5Vx0ak6WEG/x35p3WIApbv549uVK8YgPBj12VHvwtfmUlj90yqZRR 7k6r19t2TAz/x4UjO6eY+wsfwsiOZkjYIEJrGQ3QT0isdyK7msB8dC01a4XLhPwEgPnr gYWqRlZLcFle7Yn01LYQEknWoTw9mr17zWsdl2HcPoiY1S6yXtcSRgXs1m+mu1QfdJ+0 7OYP2OHr0ldiUDpAbTnusQHQZz2GTzt1iS1YmkxALkfBaQ44jmFY9QglMJFSf6Ow2pyK /Od9aFSJZ0NKUZquRvcjb8/0Jlm/scbYXziOd3vXxLCZ13n0tN6dDCzHUW7Zr5xH/4S3 Vo4g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=zO95D+j6Kak57QNXe3zOx3q8qIfcgnYPMXOOiCGthq4=; fh=uIB8jPj1zobCcSBnRvdC3XBTfPKZJZ9m3CGpk/jVNKo=; b=Ly/qEFGZAMJts2OcTVNRxehKN1jD35KFu6rbd904avcSvyKVmdWKFAahczuXQevcjH AWWYt+ZVKq1pzNaY0oGpOZhkSSEAmXSaQcBMp35AJccuISYBWxm+rHziHtPquNut5jXR 69j6qPwXhN59VykFELczheoMbP0UQix5tcpSPAetu3a4A3UvHEJh1YBRu+iJIDKtQwAI Kvth8m/Od0+e03ueb9/mfqlSnFzaTLk9bmgXYLN+7HdFWjRmJf65n6Hd3aMQpM8JkJKL xT+MfnMRGaqpQ1Lb91/YcBzzoYp6lbyo4d+2jHd6/uJO81KM7ycOgQ8Wpqhk+zlkkYZv 2MaQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JMnrTdnX; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-45565-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45565-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=1; AJvYcCXv0p3CgP29PJF6lZqPh6NVRHj1pe88+HQlGhNR8og85ncmDRx4CIlXlhU3JhG1oaveLYxDq356qeP164rOPS8sjPxayR7Ag69Pf0Earw== Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id o17-20020a170902e29100b001d4af7a3cd3si3308002plc.83.2024.01.30.17.06.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 17:06:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-45565-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JMnrTdnX; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-45565-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45565-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 0BC4BB233BB for ; Wed, 31 Jan 2024 01:05:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4B5AF15AF; Wed, 31 Jan 2024 01:05:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JMnrTdnX" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4A60736E; Wed, 31 Jan 2024 01:05:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706663137; cv=none; b=SbhgM2tUXVSTFRX7HguNy8Z6Kbi2rEzJHYCNsRfvtoR13mPI9H8o46/pqBcHoau/tUrizVa+ERkPNmxiZePfYamMaBq+hU02rWPd2TOAM7aLkaeIwpJ/ck9WiNhk4cK1f+9GqhFkiwdM6zzn36+4AVcnl97gHPpfnsfQEw0GwHY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706663137; c=relaxed/simple; bh=4Ubd1O/w+RmP1qtyme4A3XL1bfIqNhlnN/YJjjPEy8g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bD46+2GLajBminv4Lf8MTHjNcoYo1xUWHHtypKxQW54+45tDnln/EpB1S+szzwL9XRIaWKuoL70POC0tKJ0i8w6LGr0DlFBZAtL7ubL6dutQyBWRJzQrSQqyl6iTtA1c2v3QmXb0hzBS10lfPHGc0RQQLsJV8jaC1Z3aepUaaxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JMnrTdnX; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4168C433F1; Wed, 31 Jan 2024 01:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706663136; bh=4Ubd1O/w+RmP1qtyme4A3XL1bfIqNhlnN/YJjjPEy8g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JMnrTdnXwTG4IoY/ZXU5OGbA63i4rYhfw9iOH3JwzvOQA/CICiUNKP4xt//+86hFb q9slBvatW/hNlaMEz8Xjj7PT3labBYATZtnoDv67TNBwihg3xTrJ47d6W4fE9+mFzw 6xbR/qV3Lb1T+v4c1zSb9LMAI4q0V9bRIejYSVH+vh2b9F776pLa/MZNdN+GctBB2a TQ5bio2DcHz8LZGANKX+bvfM68W8mZ2hYMMj1Y3yADkYfvWYQs63h5HJqBVifdcABS tjoViNnRNjiHdEudupGrVTxcuVSqVIyS0oKQgdHyvuWNI0dWTOdpVxkjbG6hCDha95 HtpsxXUn2O6KA== Date: Tue, 30 Jan 2024 19:05:33 -0600 From: Bjorn Andersson To: Abel Vesa Cc: "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , Pavel Machek , Len Brown , Greg Kroah-Hartman , Andy Gross , Konrad Dybcio , Michael Turquette , Stephen Boyd , Stanimir Varbanov , Vikash Garodia , Bryan O'Donoghue , Mauro Carvalho Chehab , Taniya Das , Jagadeesh Kona , Dmitry Baryshkov , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-media@vger.kernel.org Subject: Re: [PATCH v4 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode Message-ID: References: <20240122-gdsc-hwctrl-v4-0-9061e8a7aa07@linaro.org> <20240122-gdsc-hwctrl-v4-5-9061e8a7aa07@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240122-gdsc-hwctrl-v4-5-9061e8a7aa07@linaro.org> On Mon, Jan 22, 2024 at 10:47:05AM +0200, Abel Vesa wrote: > From: Jagadeesh Kona > > Use dev_pm_genpd_set_hwmode API to switch the vcodec gdsc to SW/HW > modes at runtime based on requirement for venus V6 variants. > > Before the GDSC HWCTL was available to the consumer, the venus driver > needed to somehow keep the power from collapsing while under the driver > control. The only way to do that was to clear the CORE_PWR_DISABLE bit > (in wrapper POWER_CONTROL register) and, respectively, set it back after > the driver control was completed. Now, that there is a way to switch the > GDSC HW/SW control back and forth, the CORE_PWR_DISABLE toggling in > vcodec_control_v4() can be dropped for V6 variants. > The purpose of this commit is to warrant the need of this new mechanism, but I don't find that it actually describes a problem to be solved. > With newer implementation, the mode of vcodec gdsc gets switched only in Does "With newer implementation" mean "after these patches are applied"? > set_hwmode API and the GDSC should not be switched to HW control mode > before turning off the GDSC, else subsequent GDSC enable may fail, hence > add check to avoid switching the GDSC to HW mode before powering off the > GDSC on V6 variants. > Is this saying that "if we return the GDSC to HW control after turning off the clocks, it might not be possible to turn it on again"? How come? Today this GDSC is operating in HW control mode, before, during and after the clock operation. > Signed-off-by: Jagadeesh Kona > Signed-off-by: Abel Vesa > --- > drivers/media/platform/qcom/venus/pm_helpers.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c > index a1b127caa90a..55e8ec3f4ee9 100644 > --- a/drivers/media/platform/qcom/venus/pm_helpers.c > +++ b/drivers/media/platform/qcom/venus/pm_helpers.c > @@ -412,10 +412,9 @@ static int vcodec_control_v4(struct venus_core *core, u32 coreid, bool enable) > u32 val; > int ret; > > - if (IS_V6(core)) { > - ctrl = core->wrapper_base + WRAPPER_CORE_POWER_CONTROL_V6; > - stat = core->wrapper_base + WRAPPER_CORE_POWER_STATUS_V6; > - } else if (coreid == VIDC_CORE_ID_1) { > + if (IS_V6(core)) > + return dev_pm_genpd_set_hwmode(core->pmdomains[coreid], !enable); > + else if (coreid == VIDC_CORE_ID_1) { > ctrl = core->wrapper_base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL; > stat = core->wrapper_base + WRAPPER_VCODEC0_MMCC_POWER_STATUS; > } else { > @@ -451,9 +450,11 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask) > > vcodec_clks_disable(core, core->vcodec0_clks); > > - ret = vcodec_control_v4(core, VIDC_CORE_ID_1, false); > - if (ret) > - return ret; > + if (!IS_V6(core)) { > + ret = vcodec_control_v4(core, VIDC_CORE_ID_1, false); First I had this expectation that the GDSC will always be in SW control when the GDSC turns on - like the downstream implementation. In this case I felt we should have a similar condition in poweron_coreid() - as there's no point in switching to SW mode when we know we're in SW mode already. But as I finally realized that this is not the case, I now see that by skipping the transition to HW mode here, dev_pm_genpd_set_hwmode() will find the domain in SW mode, and through if (dev_gpd_data(dev)->hw_mode == enable) Will turn the vcodec_control_v4(, true) into a nop. So, my first first instinct of feeling that this should be symmetric between poweron/poweroff was reasonable...I think... I find that this interface does not match the expectations that people will bring from downstream and this example isn't helpful in explaining how to use the new interface. PS. I trust there's no case whre legacy_binding = true, or that that code path does not need similar workaround? Regards, Bjorn > + if (ret) > + return ret; > + } > > ret = pm_runtime_put_sync(core->pmdomains[1]); > if (ret < 0) > @@ -467,9 +468,11 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask) > > vcodec_clks_disable(core, core->vcodec1_clks); > > - ret = vcodec_control_v4(core, VIDC_CORE_ID_2, false); > - if (ret) > - return ret; > + if (!IS_V6(core)) { > + ret = vcodec_control_v4(core, VIDC_CORE_ID_2, false); > + if (ret) > + return ret; > + } > > ret = pm_runtime_put_sync(core->pmdomains[2]); > if (ret < 0) > > -- > 2.34.1 >