Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue
Date: Thu Jun 04 2026 - 07:11:10 EST
On 04/06/2026 10:20, Vladimir Zapolskiy wrote:
On 6/4/26 12:06, Bryan O'Donoghue wrote:
On 04/06/2026 09:46, Vladimir Zapolskiy wrote:
On 6/4/26 03:30, Bryan O'Donoghue wrote:
On 04/06/2026 01:07, Vladimir Zapolskiy wrote:
On 6/4/26 00:18, Bryan O'Donoghue wrote:
On 03/06/2026 21:51, Vladimir Zapolskiy wrote:
Actually, one more thing, Why isn't TITAN TOP GDSC here?>>>> +If CSIPHYs are true subdevices under the umbrella CAMSS device and
well
described as subnodes, then likely none of power domains are needed
to be
repeatedly described in the children device nodes, since this
information
can be obtained from the parent device by the driver.
Technically 'power-domains' property can be safely removed, I believe.
The policy is to describe the power-domain dependency fully since DT
describes hardware not software architecture.
It brings no contardiction to the statement I've given above, the needed
power domans will be properly described in the parent device, and there
is no
sense to repeat the properties it again and again in every child
subdevice.
Also for a very practical reason a sub-devices can probe/run
asynchronously of the parent device being active so in fact we do need
to describe the PDs fully.
In opposite to the above this one is precisely a software centric
argument,
which should be excluded from the consideration, as well it's not a big
deal to make a proper async initialization, removing excessive dt
properties
is worth it.
Right look forget about that.
- DT requires you to describe your hardware. You're not entitled to have
some other device vote for a clock or a PD you rely on.
Above are two uncorrelated between each other sentences.
A device ("consumer") can ask another device ("provider") to behave in
one or another way, this is the only possible and thus natually selected
system design, and nothing behind it was asked. There is no justification
for the proposed flood of multiply repeated data, it's avoidable.
CAMSS or rather the components of CAMSS modelled in the current node,
is/are not the provider of the GDSCs or the power-domains, it/they are
consumers themselves from CAMCC.
Well, this is the argument about software, and software can be changed.
The producer/consumer model is CAMCC to components within the Camera
block. Some components depend on say MXA, MXC, some do not. Nothing in
CAMSS itself is a power-domain provider.
That's exactly the type of downstream short cut we are trying to zap.
- In our case we also need to vote on PDs individually when the PHY
is active.
In extremis say we are only running the TPG then we have no reason to
vote for CSIPHY specific rails or operating points in the parent device.
So, TPG shall communicate with CAMSS, there is no CSIPHY in the equation.
Right but it would be inappropriate to enable all of the PDs for all of
the components in the CAMSS block when we can do so more granularly.
Whenever it is actually necessary, it should be possible to split PDs into
generic/parent and subdevice specific groups, it's a part of software
implementation. In some cases there might be no need to define any child
side PDs, likely CSIPHY falls into this category.
Completely not a discussion about software. DT needs to represent hardware. Its a different mindset.
I don't think we are going to resolve this debating the same thing again.
My position is the CSIPHY should list the set of power-domain dependencies it has. The PDs don't come from any other thing in the CAMSS block so the producer/consumer model is CSIPHY to CAMCC and CSIPHY to RPMPD respectively.
I'll just ask @Rob, @Krzysztof or @Conor to offer up their opinion as DT maintainers and work from there.
---
bod