Message-ID: <c2125dbf-bbef-426e-adf9-7767ad822ae1@oss.qualcomm.com>
Date: Tue, 16 Dec 2025 16:46:56 -0800
From: Vijay Kumar Tumati <vijay.tumati@....qualcomm.com>
To: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
        Loic Poulain <loic.poulain@....qualcomm.com>,
        Robert Foss
 <rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, Todor Tomov <todor.too@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        aiqun.yu@....qualcomm.com, tingwei.zhang@....qualcomm.com,
        trilok.soni@....qualcomm.com, yijie.yang@....qualcomm.com,
        Jingyi Wang <jingyi.wang@....qualcomm.com>,
        Atiya Kailany <atiya.kailany@....qualcomm.com>
Subject: Re: [PATCH v6 1/5] media: dt-bindings: Add CAMSS device for Kaanapali


On 12/16/2025 4:02 PM, Vladimir Zapolskiy wrote:
> 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.
>
Thanks for the comments, Vladimir. Bryan's and Krzysztof's argument was 
that the bindings are required to describe the full hardware regardless 
of the driver support and either way not modifiable in the future, so 
they preferred having the HW properties of the key functional blocks in 
the bindings. And we were specifically asked to add the properties into 
this node in this patch series. Having said that, my knowledge on how 
the bindings are handled upstream in the long run as the requirements 
evolve, is limited. So I will look for some expert advise from Bryan 
here as he strongly advised for these. Thanks again.
>> 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.
>>
>

Powered by blists - more mailing lists