Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding

[Krzysztof Kozlowski <krzk@kernel.org>]

On 16/10/2025 10:47, Loic Poulain wrote:
> On Thu, Oct 16, 2025 at 7:52 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 15/10/2025 05:21, Hangxiang Ma wrote:
>>>>> +      - 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.

Best regards,
Krzysztof