public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yassine Oudjana <yassine.oudjana@gmail.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Hans Verkuil <hansverk@cisco.com>,
	Yassine Oudjana <y.oudjana@protonmail.com>,
	Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] media: camss: Link CAMSS power domain
Date: Sat, 27 May 2023 09:02:04 +0300	[thread overview]
Message-ID: <GFZAVR.8RI43MBQZ4HN3@gmail.com> (raw)
In-Reply-To: <fa395680-0e6c-3eb0-9d5a-f90a95c394b8@linaro.org>


On Fri, May 26 2023 at 09:49:30 PM +01:00:00, Bryan O'Donoghue 
<bryan.odonoghue@linaro.org> wrote:
> On 26/05/2023 19:07, Yassine Oudjana wrote:
>> From: Yassine Oudjana <y.oudjana@protonmail.com>
>> 
>> The CAMSS power domain was previously enabled implicitly when the VFE
>> power domains were enabled.
>> Commit 46cc03175498 ("media: camss: Split power domain management")
>> delayed enabling VFE power domains which in turn delayed enabling the
>> CAMSS power domain. This made CSIPHY fail to enable camss_top_ahb_clk
>> which requires the CAMSS power domain to be on:
>> 
>> [  199.097810] ------------[ cut here ]------------
>> [  199.097893] camss_top_ahb_clk status stuck at 'off'
>> [  199.097913] WARNING: CPU: 3 PID: 728 at 
>> drivers/clk/qcom/clk-branch.c:91 clk_branch_wait+0x140/0x160
>> ...
>> [  199.100064]  clk_branch_wait+0x140/0x160
>> [  199.100112]  clk_branch2_enable+0x30/0x40
>> [  199.100159]  clk_core_enable+0x6c/0xb0
>> [  199.100211]  clk_enable+0x2c/0x50
>> [  199.100257]  camss_enable_clocks+0x94/0xe0 [qcom_camss]
>> [  199.100342]  csiphy_set_power+0x154/0x2a0 [qcom_camss]
>> ...
>> [  199.101594] ---[ end trace 0000000000000000 ]---
>> 
>> Link the CAMSS power domain in camss_configure_pd to make sure it 
>> gets
>> enabled before CSIPHY tries to enable clocks.
>> 
>> Fixes: 02afa816dbbf ("media: camss: Add basic runtime PM support")
>> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
>> ---
>>   drivers/media/platform/qcom/camss/camss.c | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/media/platform/qcom/camss/camss.c 
>> b/drivers/media/platform/qcom/camss/camss.c
>> index 1ef26aea3eae..9aea8220d923 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -1453,6 +1453,7 @@ static const struct media_device_ops 
>> camss_media_ops = {
>>   static int camss_configure_pd(struct camss *camss)
>>   {
>>   	struct device *dev = camss->dev;
>> +	int camss_pd_index;
>>   	int i;
>>   	int ret;
>>   \x7f@@ -1496,7 +1497,13 @@ static int camss_configure_pd(struct camss 
>> *camss)
>>   		}
>>   	}
>>   \x7f-	if (i > camss->vfe_num) {
>> +	/* Link CAMSS power domain if available */
>> +	camss_pd_index = device_property_match_string(camss->dev, 
>> "power-domain-names", "camss");
>> +	if (camss_pd_index >= 0)
>> +		device_link_add(camss->dev, camss->genpd[camss_pd_index], 
>> DL_FLAG_STATELESS |
>> +				DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
>> +
>> +	if (i > camss->vfe_num && i != camss_pd_index) {
>>   		camss->genpd_link[i - 1] = device_link_add(camss->dev, 
>> camss->genpd[i - 1],
>>   							   DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME |
>>   							   DL_FLAG_RPM_ACTIVE);
> 
> Konrad pointed this out.
> 
> Are you 100% sure you want to do this. We already have a way to count 
> the # of power-domains in camss_configure_pd().
> 
> Your series is now adding a dependency on power-domain-names.
> 
> Is there a good reason to add that dependency ? If not, then lets 
> just take the code from camss_configure_pd() and make it so that it 
> can be used/reused here.

Is there a good reason not to? I found that using the existing 
index-based method would unnecessarily complicate things since an extra 
layer of checks would be needed to differentiate between MSM8996 and 
TITAN SoCs, since those have the TITAN GDSC at the same index where the 
CAMSS GDSC is now added for MSM8996. The same checks will also have to 
be repeated in error paths and during cleanup.

I guessed the only reason we were still using this method for the 
existing PDs was to remain compatible with old DT as Konrad mentioned, 
and since this CAMSS PD is only added now, I thought it'd be a good 
opportunity to introduce power-domain-names and simplify things a bit.

> ---
> bod



  parent reply	other threads:[~2023-05-27  6:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26 18:07 [PATCH v2 0/3] media: camss: Link CAMSS power domain on MSM8996 Yassine Oudjana
2023-05-26 18:07 ` [PATCH v2 1/3] dt-bindings: media: camss: qcom,msm8996-camss: Add CAMSS power domain Yassine Oudjana
2023-05-26 19:46   ` Conor Dooley
2023-05-26 20:05     ` Bryan O'Donoghue
2023-05-26 20:19       ` Conor Dooley
2023-05-26 20:21         ` Bryan O'Donoghue
2023-05-26 20:36           ` Konrad Dybcio
2023-05-26 20:40             ` Bryan O'Donoghue
2023-05-26 20:43               ` Konrad Dybcio
2023-05-26 20:47                 ` Bryan O'Donoghue
2023-05-27  6:05             ` Yassine Oudjana
2023-05-27 15:52               ` Konrad Dybcio
2023-05-26 18:07 ` [PATCH v2 2/3] arm64: dts: qcom: msm8996: Add CAMSS power domain and power-domain-names to CAMSS Yassine Oudjana
2023-05-26 18:07 ` [PATCH v2 3/3] media: camss: Link CAMSS power domain Yassine Oudjana
2023-05-26 20:49   ` Bryan O'Donoghue
2023-05-26 20:57     ` Konrad Dybcio
2023-05-26 21:17       ` Bryan O'Donoghue
2023-05-26 21:28         ` Konrad Dybcio
2023-05-26 21:38           ` Bryan O'Donoghue
2023-05-27  6:02     ` Yassine Oudjana [this message]
2023-05-27 11:13       ` Bryan O'Donoghue
2023-05-26 20:57   ` Bryan O'Donoghue
2026-03-29 13:00 ` [PATCH v2 0/3] media: camss: Link CAMSS power domain on MSM8996 Christopher Obbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=GFZAVR.8RI43MBQZ4HN3@gmail.com \
    --to=yassine.oudjana@gmail.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hansverk@cisco.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=rfoss@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=todor.too@gmail.com \
    --cc=vladimir.zapolskiy@linaro.org \
    --cc=y.oudjana@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox