linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).