Re: [PATCH v8 5/7] media: venus: core: Add qcm2290 DT compatible and resource data

[Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>]

On 09/08/25 12:22:39, Dmitry Baryshkov wrote:
> On Sat, Aug 09, 2025 at 11:09:24AM +0200, Jorge Ramirez wrote:
> > On 09/08/25 11:18:21, Dmitry Baryshkov wrote:
> > > On Thu, Aug 07, 2025 at 10:05:10PM +0530, Vikash Garodia wrote:
> > > > 
> > > > 
> > > > On 8/7/2025 7:22 PM, Jorge Ramirez wrote:
> > > > > On 07/08/25 16:36:41, Vikash Garodia wrote:
> > > > >>
> > > > >>> It was agreed that this complexity was not necessary and that we should
> > > > >>> just drop <6.0.55 firmware support (which would in any case only include
> > > > >>> video decode).
> > > > >>>
> > > > >>> And so on v8, I removed the above.
> > > > >>>
> > > > >>> Now I have v9 ready to post it, but Dmitry is asking why cant we have
> > > > >>> the v7 functionality so I am waiting for direction.
> > > > >>
> > > > >> the issue is in firmware for both encoder and decoder. Didn't like the idea of
> > > > >> driver carrying the hack for a firmware issue. Just because, for encoder, we are
> > > > >> unable to hack it in driver, we are ok to have it enabled in a newer version of
> > > > >> the firmware, we can follow the same for decoders as well.
> > > > > 
> > > > > if that is the only reason please do explain what do you mean by hack.
> > > > 
> > > > I meant that the EOS handling was not needed in driver after fixing it in
> > > > firmware, isn't it ? Was trying to avoid carrying this in driver.
> > > > 
> > > > I tend to agree with the comment made by Dmitry in another thread to have decode
> > > > enabled with existing firmware, no option but to support the *already* published
> > > > bins.
> > > > 
> > > > Having said that, these limitation of having a separate EOS dummy buffer is well
> > > > sorted out in gen2 HFI which have an explicit DRAIN cmd for it. Hope this
> > > > motivates you to migrate to iris soon for AR50LITE variants :)
> > > 
> > > Migrating to Iris won't bring gen2 HFI. Think about users which have
> > > OEM-fused hardware. For them it's not possible to switch firmware from
> > > gen1 to gen2. Thus, if the SoC has been released using gen1 HFI, we
> > > should think twice before upgrading it to gen2.
> > >
> > 
> > As I understand it now after the thread, any driver developer working on
> > new features should not be constrained by users with OEM-fused hardware.
> > 
> > Since only the OEM can provide signed firmware updates, it is their
> > responsibility—not ours—to figure out how to deliver those updates if
> > they want their users to benefit from new features (or new fixes).
> 
> The OEMs might go bankrupt, might stop supporting hardware, might not be
> bound by EU laws, etc. If the platform was shipped with gen1 HFI and we
> suddently provide gen2 HFI, the driver must support both firmware
> interfaces for that platform.

sure, that is backwards compatibility

> 
> > The EU Cyber Resilience Act supports this view by placing the update
> > obligation on manufacturers (at least that is what I understand it, let
> > me know if you understand it differently)
> > 
> > Breaking backward compatibility is something we must avoid of
> > course. However, guaranteeing compatibility between old firmwares
> > (whether signed or not) and _new_ features is a separate matter...
> 
> Anyway, the kernel is provided separately from the firmware. If we
> supported a particular firmware set, we can not break that.
> 
> AR50_LITE is a corner case, as we have been shipping the firmware, but
> there was no corresponding open-source driver for that platform.

right

> 
> -- 
> With best wishes
> Dmitry