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

[Gjorgji Rosikopulos (Consultant)]

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.

~Gjorgji

> 
> ---
> bod