Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support

[Bryan O'Donoghue <bod@kernel.org>]

On 05/04/2026 20:48, Laurent Pinchart wrote:
> I don't necessarily agree with that. There are pros and cons for using
> HFI on platforms that have an ICP. If correctly written, a firmware can
> improve the throughput in multi-camera use cases by reprogramming the
> time-multiplexed OPE faster. On the other hand, in use cases that don't
> require pushing the platform to its limits, dealing with a closed-source
> firmware often causes lots of issues.
> 
> We should aim at supporting both direct ISP access and HFI with the same
> userspace API, even on a single platform. Which option to start with is
> an open question that we should discuss.

I think - for IPE and BPS ICP/HFI is the way to go.

However thinking about it - inline pixel processing IPP inside of the 
IFE is superior to BPS/IPE for virtually every scenario i.e. why deliver 
a frame to user-space and then submit it directly to BPS via CDM or via 
a firmware interface HFI, if you can do the same processing in the IFE - 
which on the majority of qcom platforms, you can.

Agatti is an outlier in that sense.

So actually I've shifted my focus on Hamoa to IFE/IPP.

You still BTW do want HFI for BPS/IPE - but to get 3a going on the vast 
majority of qcom platforms - you want the PIX/IPP path in the IFE.

OTOH if you want to do offline bayer processing - taking say a saved 
file from the filesystem - then BPS/IPE is the way to do it and IMO HFI 
is the way to do that.

But ICP/BPS/IPE is a nice to have.

I realise that's a word-soup of TLAs but yeah, TL;DR IFE/IPP is the way 
to go on !Agatti and once we get a nice 3a loop going there a fun 
side-project would be offline bayer processing via HFI.

---
bod