Re: [PATCH 25/74] media: qcom: camss: vfe: Define output based VFE controls

[Bryan O'Donoghue]

On 08/10/2026 12:35, Gjorgji Rosikopulos (Consultant) wrote:
> Hi Bryan,
>
> On 10/8/2026 2:17 PM, Bryan O'Donoghue wrote:
> > On 08/10/2026 06:55, Gjorgji Rosikopulos (Consultant) wrote:
> > > > +
> > > > +	/* Output based API - new and shiny */
> > > > +	void (*vfe_output_start)(struct vfe_device *vfe, struct vfe_output *output);
> > > > +	void (*vfe_output_stop)(struct vfe_device *vfe, struct vfe_output *output);
> > > > +	void (*vfe_output_buf_done)(struct vfe_device *vfe, struct vfe_output *output);
> > > > +	void (*vfe_output_update)(struct vfe_device *vfe, struct vfe_output *output,
> > > > +				  struct camss_buffer *buf);
> > > > +
> > > This also deserves good commit message, this is exact copy of the other RDI API with other arguments 🙂 Shall we migrate
> > > all existing drivers to this api in respect to use other deprecated API but having both of them leave in vfe file which
> > > creates even more confusion and readability of the code?
> > Ah but that's the point.
> >
> > You add in a parallel API which is 1:1 but which can be extended to
> > describe completion groups not WM indexes.
> >
> > WM indexes have always been wrong - limited to RDI and we have all sorts
> > of spaghetti code to work around that indexing mismatch.
> >
> > The fix is to stop doing that so yes, implement output / bus-client /
> > completion group - with wm and planes described in the output layer and
> > then move everything to that new interface.
> >
> > Including new submissions. The only real barrier is finding old
> > hardware, making the changes and ensuring nothing breaks.
> >
> > Since there's no DT dependency its "just software" - easy.
> You are maintainer and responsible of the code. But i also want to make the point
> again (which i think others may share) that having one vfe core code which is trying to support
> different architectures of the ISP's which are quite different is not correct, it is match easier
> to have different implementations based on ISP generation (different sub-device) and abstract some
> handlers which are shared. As of today camss vfe have mixed interfaces try to match multiple
> generations in one implementation. So that said i will not be convinced that the direction
> which camss is moving is good. However we need to live with it and add support as you are
> proposing, so all is good lets wait those changes to be cleanup and we will start re-basing.

Well for me its about sustainability and paying down technical debt.

RDI as WM indexes is just wrong and I firmly subscribe to Joel Spolsky's 
edict "fix bugs before writing new code".

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

The WM/RDI indexing is absolutely a bug - a design bug - that's just 
been a 'baked in' thing that's been repeated over and over again it 
hasn't mattered while we've been RDI only but, that won't do now.

Its also why I've been so dogmatic about insisting on drivers/phy to 
represent the PHY - its a PHY, so make it a PHY; anything else is a 
design bug.

So from that principle the logical result is fix the representations - 
not implement something else in parallel - we should be able to resue 
existing proven code as much as possible - it also keeps us more honest 
WRT to maintaining the user-space contract re: interface stability.

€0.02

To your point about different versions of the VFE that may be true but 
at least for the bit in front of me right now I don't see the need for 
different version of the VFE core.

---
bod