On Wed, Aug 19, 2026 at 11:15 PM Krzysztof Kozlowski <[email protected]> wrote: > > On 19/08/2026 17:48, Rob Clark wrote: > > On Wed, Aug 19, 2026 at 8:27 AM Krzysztof Kozlowski <[email protected]> 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? BR, -R
