Re: [PATCH v3 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding
From: Vijay Kumar Tumati
Date: Tue Oct 28 2025 - 15:18:21 EST
On 10/28/2025 11:39 AM, Krzysztof Kozlowski wrote:
On 28/10/2025 18:45, Vijay Kumar Tumati wrote: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.
Understood. I meant to say that it is consistent with the naming for theSorry, this makes no sense. This device has nothing to do with clockRight, this is done to maintain the consistency with the clock driver on+ - const: tfe1Why not using the same names as before? It really does not matter that
+ - const: tfe2
it is thin or image, all of them are the same because only the
difference against top matters.
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.
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
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.