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

[Hangxiang Ma]

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@xxxxxxxxxxxxxxxx/> 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