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

[Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>]

On 10/9/2026 4:39 PM, Bryan O'Donoghue wrote:
> 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

Hi Bryan,

When reg_update_after_csid_config is set, vfe_enable_output_v2() loads
the buffers but skips reg_update. The RUP is written later from
csid_configure_stream(), after the RX and RDI configuration.

On stream start:

video_start_streaming()
   s_stream(1) on VFE              <- walked upstream from video node
     vfe_enable_output_v2()        <- only load buffers, no reg_update
   s_stream(1) on CSID
     csid_set_stream()
       csid_configure_stream()     <- if need_vc_update, else not
         program RX config
         for each VC:
           program RDI and RX VC config
           AUP + RUP (__csid_reg_update covers both)
           RDI_CTRL start

On this path the VFE reg_update is itself a CSID write, CSID_AUP_CMD
and RUP_SET in csid_subdev_reg_update(), not a VFE register write.
RUP goes in after the configuration writes. Only the RDI_CTRL start
command follows it.

The video streaming function walks the pipeline upstream from the video 
node and calls s_stream(1) on each subdev in turn, so the VFE is always 
started before the CSID. What isn't obvious is that 
vfe_enable_output_v2() depends on that order to get its RUP issued at all.

On Kaanapali, REG_UPDATE has to come after the CSID configuration is 
written, otherwise no RUP DONE or BUF DONE is seen. I haven't reproduced 
the failure case myself as no BUF_DONE count mismatch and frame missing 
events are observed. So I think the information get from hardware 
guidance should be reliable. Thanks.

---
Best Regards,
Hangxiang