On 10/20/2025 3:56 AM, Bryan O'Donoghue wrote:

On 20/10/2025 11:16, Krzysztof Kozlowski wrote:

quoted

On 16/10/2025 12:43, Krzysztof Kozlowski wrote:

quoted

On 16/10/2025 10:47, Loic Poulain wrote:

quoted

On Thu, Oct 16, 2025 at 7:52 AM Krzysztof Kozlowski 
[off-list ref] wrote:

quoted

On 15/10/2025 05:21, Hangxiang Ma wrote:

quoted

quoted

quoted

+      - const: csiphy4
+      - const: csiphy5
+      - const: vfe0
+      - const: vfe1
+      - const: vfe2
+      - const: vfe_lite0
+      - const: vfe_lite1

Wouldn't it make sense to simplify this and have different camss 
nodes
for the 'main' and 'lite' paths?

[...]

No such plan till now. Other series may take this into 
consideration.

We don't care much about your plan. You are expected to send correct
hardware description.

To be fair, other platforms like sc8280xp-camss already have the
all-in big camss node.
Point is that if Lite and Main blocks are distinct enough we could
have two simpler nodes.
Would it make things any better from a dts and camss perspective?

  camss: isp@9253000 {
     compatible = "qcom,kaanapali-camss";
     [...]
}

camss-lite:ips@9273000 {
    compatible = "qcom,kaanapali-lite-camss";
     [...]
}

That approach would create two distinct CAMSS instances and separate
media pipelines.
However, it may not work with the current implementation, as the CSI
PHYs would need to be shared between them.

I guess this should be part of the broader discussion around
splitting/busifying CAMSS.

And this discussion CAN happen now, stopping this camss and any future
camss till we conclude the discussion. Whatever internal plans of that
teams are, rejecting technical discussion based on "no plans for that"
is a really bad argument, only stalling this patchset and raising 
eyebrows.

To be clear, I expect Loic's comment to be fully and technically
addressed, not with "no plan for that".

This blocks this patchset and any new versions.

Best regards,
Krzysztof

I think we should stick with the existing bindings.

There is no "lite" ISP there are so-called lite blocks within the 
CAMSS block.

It makes sense to split out the PHYs from this block as they have 
their own power-rails but, if you look at the block diagrams for this 
IP there is no specific ISP lite, there are merely blocks within the 
camera called lite.

It might be nice to structure things like this 
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi with each component 
separated out into its own node with its own compat string but, I'd 
have a hard time justifying changing up the bindings we already have 
for that reason - aside from anything else - all of those components 
in CAMSS live inside of the TITAN_TOP_GDSC which is the power-domain 
for the whole camera system.

So not meaning to answer for Hangxiang but, I think the compelling 
logic here is to stick to and extend the existing bindings.

So in fact I have no problem with the bindings as submitted - not 
including the regular fixups these types of submissions entail.

---
bod

Hi @Bryan, @Krzysztof, just my two cents. I think we should consider 
separating CSIPHY, CSID, IFE and IFE Lite into distinct DT nodes. Having 
a modular DT structure brings in several advantages,

     1. Simple to manage with much better readability.
     2. Better control to disable certain HW modules from DT.
     3. Less error prone as we don't need to maintain long lists of 
clocks or other resources against their names. Accordingly, easy to review.
     4. No need to maintain resource lists within the CAMSS driver to 
identify the resources specific to the HW block. Offers centralized 
control for the HW resources.
     5. Allows re use between the platforms when a same version of a 
subset of HW modules is carried over to future chip sets.
     6. Is more scalable when we add more functionality to the CAMSS driver.
     7. Finally, it brings in parallel development ability with 
engineers (within the local teams) working on different HW modules 
within camera subsystem.

If not for the current patches in the pipeline, if you are comfortable 
with this approach, we will try to push the changes for the future chip 
sets with the modular bindings, leaving the existing SOC drivers and 
bindings untouched (if that's recommended). Please let us know your 
thoughts. Thanks.