Re: [PATCH v4 0/5] Add Qualcomm JPEG V4L2 encoder for SM8250

[Dmitry Baryshkov]

On Wed, Jul 08, 2026 at 10:21:43PM +0100, Bryan O'Donoghue wrote:
> On 08/07/2026 13:19, Konrad Dybcio wrote:
> > On 7/7/26 12:41 PM, Bryan O'Donoghue wrote:
> > > On 07/07/2026 11:11, Konrad Dybcio wrote:
> > > > On 7/7/26 12:00 PM, Bryan O'Donoghue wrote:
> > > > > On 07/07/2026 10:24, Konrad Dybcio wrote:
> > > > > > On 7/6/26 3:37 PM, Bryan O'Donoghue wrote:
> > > > > > > On 06/07/2026 14:02, Vladimir Zapolskiy wrote:
> > [...]
> > 
> > > OK, I can see how this thread is confusing.
> > > 
> > > The idea is to start to declare sub-nodes "on the road" to making camss into a bus. The legacy binding we have is really for the IFE domain - that is CSIPHY, CSID, IFE.
> > > 
> > > Right now the camss binding describes those things - so linking say OPE or JPEG back to the thing that describes those isn't right.
> > > 
> > > OTOH we_want_ to make the top-level binding into a bus, we've discussed that several times.
> > > 
> > > To transition from monolith IFE-domain only, to camss-bus, we should have the sub-nodes fully describe themselves as "camss-bus" doesn't exist yet.
> > > 
> > > Once we have compat="camss-bus" then fine, make that linkage, I fully support that.
> > > 
> > > That roadmap BTW is why I'm asking Antanas and Loic to make JPEG and OPE sub-nodes of camss - but make them complete sub-nodes - power-domains, clocks, nocs, including the TOP_GDSC.
> > I think this needlessly increases the amount of combinations we'll
> > have to keep supporting down the line (with a ton of compatibility
> > boilerplate code)
> > 
> > Konrad
> 
> Fine.
> 
> Lets drop the bus idea then. I'm happy to close the conversation as
> peer-nodes.

It think, this would close the path for upgrading existing platforms to
split the driver / bindings. If all IFE / PHY / etc. are subnodes of the
CAMSS, it is easy to play backwards compatibility tricks and
reinstantiate devices on the fly, pick up only certain resources, etc.

If they are sibling nodes, it becomes much more complicated.

I might be wrong here. Maybe we really should try a simple (heh)
experiment. We have your series which adds CSI PHY as a first class
citizen. And we have existing platforms where CSI PHYs were packed into
the camss node (and camss driver FWIW).

Which way of representing device nodes makes it easier to migrate
existing platform to the CSI PHY driver, while keeping compatibility
with old DTs (yeah, ABI, old DTs must continue to work)?

> camss@{
> 	existing CSID/IFE
> 	IFE SID stuff goes here
> 	power-domains = TITAN_TOP_GDSC, IFE_GDSC
> }
> 
> csiphy @ {
> }
> 
> jpeg@ {
> 	JPEG SID stuff goes here
> 	power-domains = TITAN_TOP_GDSC, JPEG_GDSC
> }
> 
> camnoc@ {
> 	modelled as an ICC provider and consumed by

I think, it's a part of camss.

> }
> 
> ---
> bod

-- 
With best wishes
Dmitry