Re: [RFC PATCH v10 1/2] media: iris: introduce helper module to select video driver

Vikash Garodia
2025-02-04T15:09:19Z

On 2/4/2025 3:01 PM, Johan Hovold wrote:
> On Mon, Feb 03, 2025 at 05:16:50PM +0200, Dmitry Baryshkov wrote:
>> On Mon, Feb 03, 2025 at 09:22:51AM +0100, Johan Hovold wrote:
>>> On Fri, Jan 31, 2025 at 10:44:28AM -0800, Abhinav Kumar wrote:
>
>>>> Solution: If the user prefers iris driver and iris driver has not probed
>>>> yet, and if venus tries to probe ahead of iris we keep -EDEFERing till
>>>> iris probes and succeeds. Vice-versa when the preference is venus as well.
>>>
>>> This sounds wrong too.
>>>
>>> Look, first you guys need to explain *why* you want to have two drivers
>>> for the same hardware (not just to me, in the commit message and cover
>>> letter).
>>>
>>> That's something that really should never be the case and would need to
>>> be motivated properly.
>>
>> I think it has been written several time (not sure about this commit):
>> to provide a way for a migration path _while_ people are working on Iris
>> features. Being able to A/B test Venus and Iris drivers and to report
>> possible regressions or lack of those on the common platforms supported
>> by those (sm8250 at this moment).
>
> You don't need a module parameter for that.
>
> And we're still waiting to hear the answers to all of Hans' questions. I
> still haven't seen anyone explaining why any of this is needed. You
> could have just continued letting Venus support 8250 so presumably there
> is some benefit in using Iris instead. Which? And is that potential
> benefit important enough to not just wait until Iris is up to par
> feature wise?
They are documented in this RFC [1] as comments, and would be added in v10 as we
conclude the ongoing discussion to handle 2 drivers during the transition phase.

[1]
https://patchwork.kernel.org/project/linux-media/patch/20250128080429.3911091-2-quic_dikshita@quicinc.com/

Regards,
Vikash
>
> I'm sure you have some answers, but you need to provide them as part of
> the series.
>
>>> Second, if the reasons for keeping both drivers are deemed justifiable,
>>> you need to come up with mechanism for only binding one of them.
>>>
>>> I already told you that module parameters is not the way to go here (and
>>> the msm drm driver's abuse of module parameters is not a good precedent
>>> here).
>>>
>>> If this is a transitional thing (which it must be), then just add a
>>> Kconfig symbol to determine which driver should probe. That's good
>>> enough for evaluating whatever needs to be evaluated, and doesn't
>>> depend on adding anti-patterns like module parameters (and helper
>>> modules for them).
>>
>> No, Kconfig complicates A/B testing. What you usually want to do is to
>> boot a kernel, then go over a bunch of files testing that they work with
>> both drivers. Kconfig implies booting abother kernel, etc.
>
> No, I'm pretty sure you'd even want to reboot in between so as not to
> rely on state left behind by the other driver.
>
> Unbinding and rebinding drivers is not part of any normal work flow
> expect possibly during development. And a developer can easily compare
> Venus and Iris for 8250 without a module parameter too.
>
> Johan