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

Vijay Kumar Tumati
2025-10-28T19:18:21Z

On 10/28/2025 11:39 AM, Krzysztof Kozlowski wrote:
> On 28/10/2025 18:45, Vijay Kumar Tumati wrote:
>>>>>> + - const: tfe1
>>>>>> + - const: tfe2
>>>>> Why not using the same names as before? It really does not matter that
>>>>> it is thin or image, all of them are the same because only the
>>>>> difference against top matters.
>>>> Right, this is done to maintain the consistency with the clock driver on
>>> Sorry, this makes no sense. This device has nothing to do with clock
>>> driver. Don't ever use clock drivers as arguments for doing something in
>>> completely different place.
>>>
>>> Not mentioning that drivers don't matter much for the bindings, so I
>>> really do not get what you try to explain here.
>> Understood. I meant to say that it is consistent with the naming for the
>> TFE device that is available on Kaanapali. If our intention is to keep
>> the names in the bindings same as previous generations despite the
>> changing HW architectures, we could change these to IFEs, to be
>> consistent with previous  generations. Please advise. Appreciate your
>> inputs here.
>
> You name these based on the provider, the clock controller or whatever
> controller, and that's the mistake. Names are coming from this device
> point of view, from the consumer. This device does not care whether this
> is Thin or Image or Whatever GDSC.
>
>
> Best regards,
> Krzysztof
Gotcha. Thanks for the explanation, Krzysztof. Agree with you, we are
just trying to differentiate the GDSCs / power domains for TOP and to
each of the front end modules, to control them independently based on
the usage, as we have one common device 'camss' in the DT.

Looking at this device as a whole (as a consumer), it has one TOP GDSC
and one GDSC to each of the TFEs (the front end device itself in this
architecture is called TFE) separately for clock gating. TFE_0_GDSC is
enabled only when TFE0 is used, for instance. That way it seemed fitting
too. But if that's not OK, we have two options. One, we change this to
"ife" to be consistent with previous targets or the second, use even
more superficial name like "xfe_0", "xfe_1"etc. for power domain names
that represent any front end (thin or otherwise, which like you said
doesn't matter here) and can be adopted to all future targets. Please
let us know your thoughts. Thank you very much.