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

[Bryan O'Donoghue]

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