Re: [PATCH v9 27/28] media: iris: enable video driver probe of SM8250 SoC

[Dmitry Baryshkov]

On Tue, Feb 04, 2025 at 10:52:45AM +0100, Johan Hovold wrote:
> On Mon, Feb 03, 2025 at 05:37:28PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Feb 03, 2025 at 09:39:00AM +0100, Johan Hovold wrote:
> > > On Fri, Jan 10, 2025 at 08:01:21PM +0200, Dmitry Baryshkov wrote:
> 
> > > > Also as venus and iris drivers are not completely
> > > > equivalent wrt supported platforms, distributions will have to select
> > > > whether to disable support for older platforms or for new platforms:
> > > > Kconfig dependency will make it impossible to enable support for both
> > > > kinds.
> > > 
> > > You shouldn't have both enabled. The only reason for keeping support
> > > for the same hardware in both drivers is that the iris support is
> > > incomplete and considered experimental. No one should enable that except
> > > for development and evaluation purposes until the driver is up to par.
> > > And then you drop support from the old driver along with the config
> > > option.
> > 
> > That's the plan. This modparam is a temporal thing for transition
> > period. And yes, as a developers / platform enablers we want to be able
> > to have a quick turnaround between drivers.
> > 
> > Please stop forcing your decisions on other people. The Linux kernel and
> > its development process has always been about providing a possibility,
> > not a policy.
> 
> 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.

Regarding eDP PSR. It wasn't my implementation, so that's not correct
comparison. 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.

-- 
With best wishes
Dmitry