On 20-08-2026 20:17, Rob Clark wrote: > 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? 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.
#2(compat driver) is something that we are still exploring as we couldn't find any standard way to achieve it. We might start a separate discussion for that once we have few possible designs with us. Happy to take any other suggestion also.> > BR, > -R
