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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

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.

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

Konrad