Re: [PATCH v19 08/12] media: qcom: camss: vfe: Add support for VFE 1080

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 09/10/2026 03:59, Hangxiang Ma wrote:
>>> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/ 
>>> media/platform/qcom/camss/Makefile
>>> index 218ba3a95939..42a14e8fe1b7 100644
>>> --- a/drivers/media/platform/qcom/camss/Makefile
>>> +++ b/drivers/media/platform/qcom/camss/Makefile
>>> @@ -26,6 +26,7 @@ qcom-camss-objs += \
>>>           camss-vfe-340.o \
>>>           camss-vfe-480.o \
>>>           camss-vfe-680.o \
>>> +        camss-vfe-1080.o \
>>
>> Can't say I'm 1000000% clear on when reg_update() is supposed to 
>> happen in
>> the flow of the logic you have here.
>>
>> I'm a bit suspicious of adding a new flag which skips the update but
>> assumes some other bit of code executes later and does that update.
>>
>> Can you explain this some more please.
>>
> 
> Thanks for the review. These points were discussed in an earlier 
> revision, but I should have explained them directly in this version.
> 
> Vijay once clarified that the configuration principle became more strict 
> since Kaanapali. We can back to <https://lore.kernel.org/all/662a21a3- 
> de8b-406f-a15d-b8a572aa79ab@oss.qualcomm.com/> for more details.
> 
> In short, the hardware guidance asks to issue the REG_UPDATE after all 
> of the CSID configuration registers are written. Kaanapali seems to have 
> very strict dependency in the hardware about this sequence and with the 
> original sequence, no RUP DONE or BUF DONE events are received at all. 
> While other chipsets can work normally.

But how/where are we saying that happens ?

---
bod