From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
deller@gmx.de, daniel@ffwll.ch
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm: Move nomodeset kernel parameter to drivers/video
Date: Fri, 11 Nov 2022 14:06:30 +0100 [thread overview]
Message-ID: <a0cf08f7-d60c-f438-dc26-fb8af0e49f80@suse.de> (raw)
In-Reply-To: <8447ae65-3f44-6e96-2c0e-f62a06b3e712@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2576 bytes --]
Hi
Am 11.11.22 um 10:28 schrieb Javier Martinez Canillas:
> Hello Thomas,
>
> On 11/7/22 11:49, Thomas Zimmermann wrote:
>
> [...]
>
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index a465d5242774a..70178c5f53956 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3777,7 +3777,7 @@
>> shutdown the other cpus. Instead use the REBOOT_VECTOR
>> irq.
>>
>> - nomodeset Disable kernel modesetting. DRM drivers will not perform
>> + nomodeset Disable kernel modesetting. Graphics drivers will not perform
>> display-mode changes or accelerated rendering. Only the
>> system framebuffer will be available for use if this was
>> set-up by the firmware or boot loader.
>
> Not really part of your patch but probably we should reword this a little bit.
>
> Because as this is written, it implies that not only DRM drivers with feature
> DRIVER_MODESET will not be available but also drivers with DRIVER_RENDER. But
> that's not the case, render-only drivers usually just ignore this parameter
> (but not all IIRC), so I wonder how we could make this comment more accurate.
I see what you mean, but it's hard to describe in simple words. The
option is a bit fuzzy. It means that a driver will not replace a
firmware buffer; even if that means it won't initialize at all. I guess
we should spell that out.
>
> Also maybe we can mention in the comment fbdev and DRM? Just to make it clear
> that this will affect to both subsystems? When I first worked on this, there
> were a lot of assumptions in the stack (gdm, mutter, plymouth) that nomodeset
> basically meant "no DRM but fbdev".
I can change the text to say 'DRM and fbdev drivers'.
Best regards
Thomas
>
> [...]
>
>>
>> int drm_dev_set_unique(struct drm_device *dev, const char *name);
>>
>> -extern bool drm_firmware_drivers_only(void);
>> +/* TODO: Inline drm_firmware_drivers_only() in all its callers. */
>
> I guess you plan to do that as follow-up patches once this series land? Just
> to avoid the churn to require acks for all the drivers to merge this series?
>
> The changes looks good to me.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-11-11 13:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 10:49 [PATCH 0/2] video/fbdev: Support 'nomodeset' in PCI drivers Thomas Zimmermann
2022-11-07 10:49 ` [PATCH 1/2] drm: Move nomodeset kernel parameter to drivers/video Thomas Zimmermann
2022-11-11 9:28 ` Javier Martinez Canillas
2022-11-11 12:37 ` Thomas Zimmermann
2022-11-11 13:06 ` Thomas Zimmermann [this message]
2022-11-07 10:49 ` [PATCH 2/2] fbdev: Add support for the nomodeset kernel parameter Thomas Zimmermann
2022-11-07 13:57 ` Helge Deller
2022-11-07 15:30 ` Thomas Zimmermann
2022-11-07 20:46 ` Helge Deller
2022-11-08 8:16 ` Thomas Zimmermann
2022-11-11 9:49 ` Javier Martinez Canillas
2022-11-11 10:49 ` Helge Deller
2022-11-11 11:42 ` Thomas Zimmermann
2022-11-11 13:27 ` Helge Deller
2022-11-11 9:42 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0cf08f7-d60c-f438-dc26-fb8af0e49f80@suse.de \
--to=tzimmermann@suse.de \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=linux-fbdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).