Re: [PATCH v2 00/15] accel/qda: Qualcomm DSP Accelerator driver

[Rob Clark]

On Thu, Sep 10, 2026 at 7:25 AM Bjorn Andersson <andersson@xxxxxxxxxx> wrote:
>
> On Wed, Sep 09, 2026 at 02:48:17PM +0300, Dmitry Baryshkov wrote:
> > On Tue, Sep 08, 2026 at 05:44:10PM -0500, Bjorn Andersson wrote:
> > > On Wed, Aug 26, 2026 at 06:37:00PM +0530, Ekansh Gupta wrote:
> > > > On 20-08-2026 20:17, Rob Clark wrote:
> > > > > On Wed, Aug 19, 2026 at 11:15 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > > >>
> > > > >> On 19/08/2026 17:48, Rob Clark wrote:
> > > > >>> On Wed, Aug 19, 2026 at 8:27 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > > >>>> The rule of usptream development is that we do not accept duplicated
> > > > >>>> code, just because a vendor wants to write something new. This is
> > > > >>>> basically the concept applied all over the drivers tree, where we pushed
> > > > >>>> back against all sorts of duplications all over the vendors.
> > > > >>>>
> > > > >>>> What I miss in this thread is why would there be any exception here. We
> > > > >>>> do not grant exceptions from standard practices on "I want" reasons.
> > > > >>>
> > > > >>> I agree that we should not have duplicated drivers just for vendor
> > > > >>> lolz.  But when it comes to adopting common frameworks and integrating
> > > > >>> better into the ecosystem, this doesn't seem like something we should
> > > > >>> actively discourage.  I don't think this is a case of vendor lolz, but
> > > > >>
> > > > >> No one discourages it. Following standard Linux kernel practices and
> > > > >> requirements is not discouraging, do not twist the narrative here.
> > > > >> Again, it is standard upstream review telling that we do not duplicate
> > > > >> drivers. Ever, unless there is serious exception needed.
> > > > >
> > > > > I wasn't trying to twist the narrative, just trying to come up with a
> > > > > path forward that isn't "no" or "improve existing driver", since
> > > > > neither of those gets us towards a future using common frameworks.
> > > > >
> > > > >> I asked why there should be an exception granted? Is the reason for
> > > > >> exception following:
> > > > >> "We want to adopt common framework"
> > > > >> ?
> > > > >
> > > > > Possibly?  But I don't think we want two drivers to be any sort of
> > > > > long term solution.  (Ie. as long as venus/iris have co-exist.)
> > > > >
> > > > >>
> > > > >>> rather reacting to drm/accel emerging as the standard framework for
> > > > >>> this sort of driver.
> > > > >>>
> > > > >>> So how do we get from here to there?
> > > > >>
> > > > >> What is wrong with my proposal?
> > > > >
> > > > > Maybe I missed something, my understanding was your proposal was
> > > > > "Grow/replace/improve existing driver instead of coming with a
> > > > > duplicate"..  grow or improve doesn't move us toward common
> > > > > frameworks.  Maybe "replace" is a valid option.  If there is something
> > > > > I missed, then I apologize.
> > > > >
> > > > > Options I can think of are:
> > > > >
> > > > > 1. Hardware cutoff.. new hw gets new driver, existing hw gets existing
> > > > >    driver
> > > > > 2. Backwards compat chardev registered by new driver, providing existing
> > > > >    UABI.  I'm not 100% sure about the feasibility/drawbacks of this..
> > > > >    AFAIU the fastrpc folks where planning a backwards compat layer in
> > > > >    userspace, so maybe it is possible.
> > > > > 3. exception?
> > > > >
> > > > > I'd like to know what the feasibility of #2 is, since at a high level
> > > > > that sounds like the best option.  Possibly limit exposure of legacy
> > > > > UABI to existing hw so we don't get into a place of needing to extend
> > > > > the legacy UABI for new hw?
> > > > >
> > > > > But #1 sounds like a non-controversial place to start regardless.
> > > > > Possibly with #2 coming as followup and necessary step before eventual
> > > > > migration to new driver for existing hw?
> > > > >
> > > > > Even if we start with #2, how do we handle first-merge-window
> > > > > bugs/regressions without reverting addition of new driver and removal
> > > > > of old?  It seems like we'd need a window of a couple release cycles
> > > > > where both drivers exist?
> > > > >
> > > > > Maybe others have other/better options in mind?
> > > > To all, I'm seeking on the approach I should follow to go ahead here. I
> > > > can work on implementing #1(as per Rob's list) with hw specific
> > > > compatible for v4 if it's acceptable.
> > > >
> > >
> > > I don't see any reason for you to define a "hw specific compatible",
> > > because as you have shown in this series (and as Rob point out), there's
> > > no difference in the "hardware".
> > >
> > > The only reason for your "hw specific compatible" is to make a software
> > > selection in Linux - and that's not what DeviceTree is for.
> >
> > That's not exactly true. There are protocol differences. For example,
> > polling mode is supported only since a certain timeline in the history.
> > Likewise other interface features are not supported on all the FastRPC
> > devices. For the polling mode support we were already beaten by the lack
> > of SoC-specific compats.
> >
>
> I can see the benefit of capturing some of the generational features in
> a compatible, like the changes related to address width. But for pure
> software features that doesn't have an actual bearing in the hardware,
> I'd prefer if we relied on dynamic discovery.
>
> But none of that applies to the question of "can I use compatible to
> select if we should use the new or old Linux driver".
>

Nit, driver could still have an allow/deny-list of machine
compatibles.  Might be something to keep in mind if a phased
depreciation strategy was desirable..

BR,
-R