[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <98702737-2104-6139-8bd3-2e926260263b@redhat.com>
Date: Thu, 16 Dec 2021 01:38:39 +0100
From: Javier Martinez Canillas <javierm@...hat.com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Heiko Stübner <heiko@...ech.de>,
"James (Qian) Wang" <james.qian.wang@....com>,
Noralf Trønnes <noralf@...nnes.org>,
Alexey Brodkin <abrodkin@...opsys.com>,
Alison Wang <alison.wang@....com>,
Anitha Chrisanthus <anitha.chrisanthus@...el.com>,
Boris Brezillon <bbrezillon@...nel.org>,
Brian Starkey <brian.starkey@....com>,
Chen-Yu Tsai <wens@...e.org>,
Chun-Kuang Hu <chunkuang.hu@...nel.org>,
David Lechner <david@...hnology.com>,
Deepak Rawat <drawat.floss@...il.com>,
Edmund Dea <edmund.j.dea@...el.com>,
Emma Anholt <emma@...olt.net>,
Erico Nunes <nunes.erico@...il.com>,
Hans de Goede <hdegoede@...hat.com>,
Hyun Kwon <hyun.kwon@...inx.com>,
Inki Dae <inki.dae@...sung.com>, Joel Stanley <joel@....id.au>,
Joonyoung Shim <jy0922.shim@...sung.com>,
Jyri Sarha <jyri.sarha@....fi>,
Kamlesh Gurudasani <kamlesh.gurudasani@...il.com>,
Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
Laurentiu Palcu <laurentiu.palcu@....nxp.com>,
Linus Walleij <linus.walleij@...aro.org>,
Liviu Dudau <liviu.dudau@....com>,
Lucas Stach <l.stach@...gutronix.de>,
Marek Vasut <marex@...x.de>,
Maxime Ripard <mripard@...nel.org>,
Neil Armstrong <narmstrong@...libre.com>,
Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
Paul Cercueil <paul@...pouillou.net>,
Philipp Zabel <p.zabel@...gutronix.de>,
Philippe Cornu <philippe.cornu@...s.st.com>,
Qiang Yu <yuq825@...il.com>, Rob Clark <robdclark@...il.com>,
Rob Herring <robh@...nel.org>,
Russell King <linux+etnaviv@...linux.org.uk>,
Russell King <linux@...linux.org.uk>,
Sam Ravnborg <sam@...nborg.org>,
Sandy Huang <hjc@...k-chips.com>, Sean Paul <sean@...rly.run>,
Stefan Agner <stefan@...er.ch>,
Thierry Reding <thierry.reding@...il.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Tian Tao <tiantao6@...ilicon.com>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Tomi Valkeinen <tomba@...nel.org>,
Xinliang Liu <xinliang.liu@...aro.org>,
Yannick Fertre <yannick.fertre@...s.st.com>
Subject: Re: [PATCH 00/60] drm: Make all drivers to honour the nomodeset
parameter
On 12/16/21 01:24, Laurent Pinchart wrote:
> Hi Javier,
>
> On Thu, Dec 16, 2021 at 01:13:56AM +0100, Javier Martinez Canillas wrote:
>> Hello Laurent,
>>
>> On 12/16/21 00:35, Laurent Pinchart wrote:
>>
>> [snip]
>>
>>>>
>>>> I've built tested with 'make allmodconfig && make M=drivers/gpu/drm/', but
>>>> only booted in a few devices with and without nomodeset in the cmdline. So
>>>> testing and reviewing for all the drivers would be highly appreciated.
>>>
>>> The fact that the series is so big makes me think it would be better to
>>> handle this in the DRM core. Is there any way we could do so ? Otherwise
>>> we'll chase this issue forever in new drivers, and will be plagued with
>>> cargo cult problems.
>>>
>>
>> Yes, what Thomas suggested is to add a set of drm_module_{pci,platform}_driver()
>> macros in include/drm/drm_drv.h, that will just check whether the driver should
>> be registered or not and call the {pci,platform}_register_driver() functions.
>>
>> That way the change in the drivers would just be something like the following:
>>
>> -module_platform_driver(malidp_platform_driver);
>> +drm_module_platform_driver(malidp_platform_driver);
>>
>> There are some drivers that still need a custom module init functions for various
>> reasons (e.g: register a set of devices/drivers, need to be a late init call, etc)
>> but at least for most drivers this should be handled transparently as long as they
>> use these drm_*_register_driver() macros.
>
> Another option could be to return an error from drm_dev_alloc(). That
> may avoid changes in the drivers.
>
That was actually the first approach I proposed but was told that it wouldn't work
for two reasons:
1) Usually that's called in the driver's probe function and the goal was to make it
fail as early as possible if nomodeset is present, so that means it is desirable
for this to be in the module init function (and is how most drivers implement).
2) Not all KMS drivers should fail if nomodeset is used. For example the simpledrm
driver still needs to be registered and probed since is what users would want
as a fallback / troubleshooting option if their native driver doesn't work.
Solving (2) is easy since we could just add a new .driver_features flag to indicate
that the driver should not fail if nomodeset is present. That way only the drivers
that are the exception would need to be modified.
But (1) is more tricky since this may be DRM driver maintainers preference.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Powered by blists - more mailing lists