On Tue, Feb 04, 2025 at 05:35:26PM +0200, Dmitry Baryshkov wrote: > On Tue, Feb 04, 2025 at 10:52:45AM +0100, Johan Hovold wrote: > > That's just not true. The rule is to not have two drivers for the same > > hardware (even if we very rarely have accepted some well-motivated > > exceptions). > > > > I understand that you may have an unorthodox view of this as you work on > > the MSM DRM driver, but hiding incomplete and broken code behind module > > parameters so that you can game the upstreaming process (e.g. like you > > did for the eDP PSR feature) is simply not a model that anyone should > > follow. > > Let me point you the aic7xxx story, we had, if my memory is correct, > three drivers working with the same hardware at some point, during > transition period. As I also mentioned, there have been exceptions to the rule. > Regarding eDP PSR. It wasn't my implementation, so that's not correct > comparison. Sure, but that module parameter is still there two years later, the functionality is still incomplete and from what I've heard has since also bitrotted (psr_enabled). Done right and enabled by default this feature would have been very useful giving, for example, users of the X13s a 2 h battery boost. Instead, as expected, no one cares about fixing the code after it was "mainlined" or runs the bits that did work often enough to detect when it breaks further. Everyone loses. > MDP5 -> DPU migration is mine and yes, it is implemented in > this way as we can trigger CI jobs having a single kernel, as developers > we can switch between MDP5 and DPU drivers in a quick way, etc. I don't know the backstory there, but at least the commit message didn't mention anything about a plan to transition from one to the other. Johan
