From: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
To: Robert Foss <robert.foss@linaro.org>,
Todor Tomov <todor.too@gmail.com>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH 0/2] media: dt-bindings: media: sm8250-camss: Add power-domain-names property
Date: Fri, 20 May 2022 00:53:02 +0300 [thread overview]
Message-ID: <06baf3b7-6b2d-4cc6-64d7-7bd1b3a18335@linaro.org> (raw)
In-Reply-To: <20220518121104.951621-1-vladimir.zapolskiy@linaro.org>
On 5/18/22 15:11, Vladimir Zapolskiy wrote:
> QCOM SM8250 camera subsystem depends on three power domains, at the moment
> all of them are not differentiated one from another, however the power
> domains compose a hierarchical structure with vfe0 and vfe1 as subdomains
> of titan_top, also managing vfe0 and vfe1 separately allows to get more
> fine-grained power control in runtime.
>
> The change relates to my review comment for v2 of CAMSS on SM8250 submission:
>
> https://lore.kernel.org/all/13ad033e-cd5d-3a8c-b036-50a3ac4245c0@linaro.org/
>
> Apparently it becomes important to manage CAMSS power domains much better for
> newer platforms, this referes to platforms with Titan GDSC, for instance CAMSS
> on SM8450 has 6 power domains, and dealing with them in bulk is not an option.
>
> There was a note in commit 2f6f8af67203 ("media: camss: Refactor VFE power
> domain toggling") about problems with power VFE domains on/off, but perhaps
> it's related to the fact that Titan GDSC is a special power domain and VFE
> are subdomains, the latter shall not be enabled earlier than the Titan, but
> the driver did not construct a proper hierarchy and leaves a room for races.
>
> The change should have no implications on any SM8250 CAMSS users, since
> none of the supported in upstream boards enables the camss device tree node.
> The correspondent changes in the driver will follow this dt specific series.
>
> Most likely a similar change is required for SDM845 platform, but it would
> need additional investigation and testing.
>
> Vladimir Zapolskiy (2):
> media: dt-bindings: media: sm8250-camss: Add power-domain-names property
> arm64: dts: qcom: sm8250: camss: Add power-domain-names property
>
> .../devicetree/bindings/media/qcom,sm8250-camss.yaml | 7 +++++++
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 1 +
> 2 files changed, 8 insertions(+)
>
These changes will be unneeded, if it is reliable to state that the order
of 'power-domains' array values is fixed.
From Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml
power-domains:
items:
- description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
- description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
- description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
Apparently it's insufficient to ensure the fixed order of the power domains
by running a check against the schema, and likely it can not be improved,
but please correct me here, if I'm wrong.
That's said, what is the preferred way here? Leave everything as is and rely
on the order of item descriptions, or add a new power-domain-names property?
--
Best wishes,
Vladimir
next prev parent reply other threads:[~2022-05-19 21:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-18 12:11 [PATCH 0/2] media: dt-bindings: media: sm8250-camss: Add power-domain-names property Vladimir Zapolskiy
2022-05-18 12:11 ` [PATCH 1/2] " Vladimir Zapolskiy
2022-05-18 12:11 ` [PATCH 2/2] arm64: dts: qcom: sm8250: camss: " Vladimir Zapolskiy
2022-05-18 13:16 ` [PATCH 0/2] media: dt-bindings: media: sm8250-camss: " Bryan O'Donoghue
2022-05-19 21:53 ` Vladimir Zapolskiy [this message]
2022-06-01 20:24 ` Rob Herring
2022-11-24 9:03 ` Hans Verkuil
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=06baf3b7-6b2d-4cc6-64d7-7bd1b3a18335@linaro.org \
--to=vladimir.zapolskiy@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=robert.foss@linaro.org \
--cc=robh+dt@kernel.org \
--cc=todor.too@gmail.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;
as well as URLs for NNTP newsgroup(s).