Re: [PATCH v8 1/5] media: dt-bindings: Add CAMSS device for Kaanapali

[Vijay Kumar Tumati <vijay.tumati@oss.qualcomm.com>]

On 12/7/2025 5:44 PM, Dmitry Baryshkov wrote:
> On Sat, Dec 06, 2025 at 10:11:20PM +0000, Bryan O'Donoghue wrote:
>> On 01/12/2025 06:30, Hangxiang Ma wrote:
>>> Add the compatible string "qcom,kaanapali-camss" to describe the Camera
>>> Subsystem (CAMSS) on the Qualcomm Kaanapali platform.
>>>
>>> The Kaanapali platform provides:
>>> - 3 x VFE, 5 RDI per VFE
>>> - 2 x VFE Lite, 4 RDI per VFE Lite
>>> - 3 x CSID
>>> - 2 x CSID Lite
>>> - 6 x CSIPHY
>>> - 2 x ICP
>>> - 1 x IPE
>>> - 2 x JPEG DMA & Downscaler
>>> - 2 x JPEG Encoder
>>> - 1 x OFE
>>> - 5 x RT CDM
>>> - 3 x TPG
>>>
>>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>> Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
>>> ---
>>>    .../bindings/media/qcom,kaanapali-camss.yaml       | 647 +++++++++++++++++++++
>>>    1 file changed, 647 insertions(+)
>>>
>>> +      - const: gcc_hf_axi
>> https://patchwork.linuxtv.org/project/linux-media/patch/20251126-add-support-for-camss-on-sm8750-v1-2-646fee2eb720@oss.qualcomm.com/
>>
>> Pointed out by Krzysztof in the 8750 patches but the name of this clock is
>> gcc_axi_hf.
>>
>> ~/Development/worktree/qcom-linux-next
>> ➞  grep gcc_axi_hf * -r | wc -l              [git:platform-qcom-next] ✖
>> 48
>>
>> ~/Development/worktree/qcom-linux-next
>> ➞  grep gcc_hf_axi * -r | wc -l              [git:platform-qcom-next] ✖
>> 0
> My 2c: it should be none of those. gcc_axi_hf is the _source_ of the
> clock, while the bindings (in my opinion) should be describing the
> function of the clock on the consumer side (e.g. bus, iface, something
> else, etc).

Hi Dmitry, this is MMNOC side of the AXI bus clock for the HF clients. 
If it's ok, we can change it to be consistent with previous generations 
for KNP and we can take it up in detail when we refactor the bindings 
for Hawi? Please let me know if you have a strong opinion on this at 
this point and we can discuss accordingly.

Hi Bryan, we are addressing the things that makes sense for KNP as well 
in the next revision. Btw, couple things like a separate CSIPHY DT node 
and ordering of the resources (that were to be added at the end as you 
advised), I believe are not relevant for KNP. As for the GDSC names, we 
preferred the module name and it's GDSC name to be consistent so changed 
the latter as well to VFE. Hope that's ok. Please let us know if you 
would suggest any further changes to KNP v9 bindings and we can move 
forward accordingly.

Thank you both.

>> Please resolve the other inconsitencies pointed out by Krzysztof in that
>> thread here also.
>>
>> I will have to skip application of this series in the meantime.
>>
>> ---
>> bod