On 18/05/2022 13: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@xxxxxxxxxx/
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(+)
This doesn't break anything for me on sm8250
Tested-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
for both
