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

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On Thu, Jul 09, 2026 at 08:16:21PM +0200, Konrad Dybcio wrote:
> On 7/9/26 9:33 AM, Dmitry Baryshkov wrote:
> > 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)?
> 
> Quite frankly, I don't consider the existing (meganode) description
> any valid, and would vote to rip it the second a replacement is
> available. But once, not N times.

Rip without providing backwards compatibility?

One of the options would be to follow the 'venus/iris' approach: land
new set of component drivers, which target new platforms and provide
minimal support for one old platform (maybe via autoapplied DT overlay
or other similar techniques). Then continue migrating and phasing out
camss driver for old platforms, while adding support for new blocks in
the new set of drivers and ripping support from the camss driver after
some migration time.

> This is not to blame any of the original implementers, this might
> have seemed like the right idea for the tiny subsystem on msm8916.

Maybe...


-- 
With best wishes
Dmitry