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

[Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>]

Hi Vijay.

On 12/16/25 19:55, Vijay Kumar Tumati wrote:
> 
> On 12/12/2025 4:49 AM, Vladimir Zapolskiy wrote:
>> On 11/18/25 20:44, Konrad Dybcio wrote:
>>> On 11/18/25 7:25 PM, Vijay Kumar Tumati wrote:
>>>>
>>>> On 11/18/2025 7:00 AM, Bryan O'Donoghue wrote:
>>>>> On 14/11/2025 03:29, Hangxiang Ma wrote:
>>>>>> +                  <0x0 0x0900e000 0x0 0x1000>,
>>>>>
>>>>> Why aren't you starting @ 0x0900e000 ? seems to be omitting some of
>>>>> the registers in the ICP block. Should start at +0xd000 not +0xe000 ?
>>>>>
>>>>>> +                  <0x0 0x0902e000 0x0 0x1000>,
>>>>>
>>>>> Same here.
>>>> Hi Bryan, HLOS does not have access to those registers. They are
>>>> configured by the Hyp.
>>>
>>> If that's hyp, please add them. We already have platforms without
>>> Gunyah. Remember, bindings are defined once and for good and I wouldn't
>>> call it impossible that someone would want to run that configuration on
>>> Kaanapali some day
>>>
>>
>> If the ICP register block is added now, then it will practically exclude
>> an option to run hardware demosaic on Kaanapali. There were notorious
>> and still unresolved problems with CSIPHY blocks, which shall be split
>> from CSID/VFE CAMSS on device tree level also, for similar reasons the
>> same should be done with ICP or other blocks. It makes exactly zero
>> sense to pile everything into a monolythic device tree node, and doing
>> so undermines any future advances in CAMSS support in the upstream
>> Linux, the hardware description in downstream is done thoughtfully
>> better,
>> and not for no reason.
>>
> Hi Vladimir, yes, this has been discussed in the past and the general
> consensus from everyone is for not blocking KNP series on this. But yes,
> there is an ongoing effort to modularize the bindings for future
> chipsets and when it's ready, we can review, discuss and take it

My concern is that it makes very little sense to throw any not clearly
defined hardware properties and interconnections into an unorganized and
unmanageable pile of everything, because this closes the door to ever update
the upstream CAMSS driver by adding better CAMSS IP support for any already
manufactured and sold Qualcomm SoC powered board with done CAMSS support.

If some user already holds a phone, a laptop and expects to offload CPU to
CAMSS IP one happy day, it's pretty unsatisfactory to say that it will never
happen on legacy hardware, because there was done an unrecoverable mistake
by adding never tested properties into CAMSS DT bindings, and the remained
option is to "wait for future chipsets". Each added unsupported and unused
property boards up the window of better CAMSS support on manufactured boards.

I don't understand a reason why to do worse for the upstream, when there is
a clear and feasible alternative not to do worse, thus my misunderstanding
and my grief for upstream CAMSS are my concerns.

> forward. As for your ICP concern, if you are referring to the Demosaic
> in OFE, I believe we might still be able to do it either with direct OFE
> config from CPU or using the firmware (preferred), given that we
> properly establish the shared memory and SID IOVA ranges for ICP,
> assuming that the load and authenticate will be taken care by Hyp or TZ.
> Please share your thoughts if I missed something.
> 
> Hi Bryan, please feel free to add your thoughts.
> 

-- 
Best wishes,
Vladimir