| Message ID | 20211108140648.795268-1-javierm@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Cleanups for the nomodeset kernel command line parameter logic | expand |
Hi Am 08.11.21 um 15:06 schrieb Javier Martinez Canillas: > There is a lot of historical baggage on this parameter. It is defined in > the vgacon driver as nomodeset, but its set function is called text_mode() > and the value queried with a function named vgacon_text_force(). > > All this implies that it's about forcing text mode for VGA, yet it is not > used in neither vgacon nor other console driver. The only users for these > are DRM drivers, that check for the vgacon_text_force() return value to > determine whether the driver should be loaded or not. > > That makes it quite confusing to read the code, because the variables and > function names don't reflect what they actually do and also are not in the > same subsystem as the drivers that make use of them. > > This patch-set attempts to cleanup the code by moving the nomodseset param > to the DRM subsystem and do some renaming to make their intention clearer. > > This is a v4 of the patches, that address issues pointed out by Thomas > Zimmermann in v3: https://lkml.org/lkml/2021/11/8/384 > > Patch #1 and #2 are just trivial cleanups. > > Patch #3 moves the nomodeset boot option to the DRM subsystem and renames > the variables and functions names. > > Patch #4 removes the relationship between the nomodeset parameter and the > CONFIG_VGA_CONSOLE Kconfig symbol. > > Patch #5 adds nomodeset to the kernel parameters documentation. > > Patch #6 improves the message when nomodeset is enabled to make it more > accurate and less sensational. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Best regards Thomas > > Changes in v4: > - Don't mention the simpledrm driver and instead explain in high level > terms what the nomodeset option is about. > - Don't mention DRM drivers in the kernel message and instead explain > that only the system framebuffer will be available. > > Changes in v3: > - Drop the drm_drv_enabled() function and just call to drm_get_modeset(). > - Make drm_get_modeset() just a getter function and don't return an error. > - Move independent cleanups in drivers as separate preparatory patches. > > Changes in v2: > - Conditionally build drm_nomodeset.o if CONFIG_VGA_CONSOLE is set. > - Squash patches to move nomodeset logic to DRM and do the renaming. > - Name the function drm_check_modeset() and make it return -ENODEV. > - Squash patch to add drm_drv_enabled() and make drivers use it. > - Make the drivers changes before moving nomodeset logic to DRM. > - Make drm_drv_enabled() return an errno and -ENODEV if nomodeset. > - Remove debug and error messages in drivers. > > Javier Martinez Canillas (6): > drm: Don't print messages if drivers are disabled due nomodeset > drm/vboxvideo: Drop CONFIG_VGA_CONSOLE guard to call > vgacon_text_force() > drm: Move nomodeset kernel parameter to the DRM subsystem > drm: Decouple nomodeset from CONFIG_VGA_CONSOLE > Documentation/admin-guide: Document nomodeset kernel parameter > drm: Make the nomodeset message less sensational > > .../admin-guide/kernel-parameters.txt | 7 ++++++ > drivers/gpu/drm/Kconfig | 6 +++++ > drivers/gpu/drm/Makefile | 2 ++ > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++--- > drivers/gpu/drm/ast/ast_drv.c | 4 ++-- > drivers/gpu/drm/drm_nomodeset.c | 24 +++++++++++++++++++ > drivers/gpu/drm/i915/i915_module.c | 4 ++-- > drivers/gpu/drm/mgag200/mgag200_drv.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++-- > drivers/gpu/drm/qxl/qxl_drv.c | 4 ++-- > drivers/gpu/drm/radeon/radeon_drv.c | 10 +++----- > drivers/gpu/drm/tiny/bochs.c | 4 ++-- > drivers/gpu/drm/tiny/cirrus.c | 5 ++-- > drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++--- > drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- > drivers/video/console/vgacon.c | 21 ---------------- > include/drm/drm_mode_config.h | 2 ++ > include/linux/console.h | 6 ----- > 19 files changed, 67 insertions(+), 60 deletions(-) > create mode 100644 drivers/gpu/drm/drm_nomodeset.c >
On Mon, 8 Nov 2021 15:17:13 +0100 Thomas Zimmermann <tzimmermann@suse.de> wrote: > Hi > > Am 08.11.21 um 15:06 schrieb Javier Martinez Canillas: > > There is a lot of historical baggage on this parameter. It is defined in > > the vgacon driver as nomodeset, but its set function is called text_mode() > > and the value queried with a function named vgacon_text_force(). > > > > All this implies that it's about forcing text mode for VGA, yet it is not > > used in neither vgacon nor other console driver. The only users for these > > are DRM drivers, that check for the vgacon_text_force() return value to > > determine whether the driver should be loaded or not. > > > > That makes it quite confusing to read the code, because the variables and > > function names don't reflect what they actually do and also are not in the > > same subsystem as the drivers that make use of them. > > > > This patch-set attempts to cleanup the code by moving the nomodseset param > > to the DRM subsystem and do some renaming to make their intention clearer. > > > > This is a v4 of the patches, that address issues pointed out by Thomas > > Zimmermann in v3: https://lkml.org/lkml/2021/11/8/384 > > > > Patch #1 and #2 are just trivial cleanups. > > > > Patch #3 moves the nomodeset boot option to the DRM subsystem and renames > > the variables and functions names. > > > > Patch #4 removes the relationship between the nomodeset parameter and the > > CONFIG_VGA_CONSOLE Kconfig symbol. > > > > Patch #5 adds nomodeset to the kernel parameters documentation. > > > > Patch #6 improves the message when nomodeset is enabled to make it more > > accurate and less sensational. > > Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Hi, these ideas make sense to me, so FWIW, Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> There is one nitpick I'd like to ask about: +bool drm_get_modeset(void) +{ + return !drm_nomodeset; +} +EXPORT_SYMBOL(drm_get_modeset); Doesn't "get" have a special meaning in the kernel land, like "take a strong reference on an object and return it"? As this is just returning bool without changing anything, the usual word to use is "is". Since this function is also used at most once per driver, which is rarely, it could have a long and descriptive name. For example: bool drm_is_modeset_driver_allowed(void); - "drm" is the namespace - "is" implies it is a read-only boolean inspection - "modeset" is the feature being checked - "driver" implies it is supposed gate driver loading or initialization, rather than modesets after drivers have loaded - "allowed" says it is asking about general policy rather than what a driver does Just a bikeshed, I'll leave it to actual kernel devs to say if this would be more appropriate or worth it. Thanks, pq > > Best regards > Thomas > > > > > Changes in v4: > > - Don't mention the simpledrm driver and instead explain in high level > > terms what the nomodeset option is about. > > - Don't mention DRM drivers in the kernel message and instead explain > > that only the system framebuffer will be available. > > > > Changes in v3: > > - Drop the drm_drv_enabled() function and just call to drm_get_modeset(). > > - Make drm_get_modeset() just a getter function and don't return an error. > > - Move independent cleanups in drivers as separate preparatory patches. > > > > Changes in v2: > > - Conditionally build drm_nomodeset.o if CONFIG_VGA_CONSOLE is set. > > - Squash patches to move nomodeset logic to DRM and do the renaming. > > - Name the function drm_check_modeset() and make it return -ENODEV. > > - Squash patch to add drm_drv_enabled() and make drivers use it. > > - Make the drivers changes before moving nomodeset logic to DRM. > > - Make drm_drv_enabled() return an errno and -ENODEV if nomodeset. > > - Remove debug and error messages in drivers. > > > > Javier Martinez Canillas (6): > > drm: Don't print messages if drivers are disabled due nomodeset > > drm/vboxvideo: Drop CONFIG_VGA_CONSOLE guard to call > > vgacon_text_force() > > drm: Move nomodeset kernel parameter to the DRM subsystem > > drm: Decouple nomodeset from CONFIG_VGA_CONSOLE > > Documentation/admin-guide: Document nomodeset kernel parameter > > drm: Make the nomodeset message less sensational > > > > .../admin-guide/kernel-parameters.txt | 7 ++++++ > > drivers/gpu/drm/Kconfig | 6 +++++ > > drivers/gpu/drm/Makefile | 2 ++ > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++--- > > drivers/gpu/drm/ast/ast_drv.c | 4 ++-- > > drivers/gpu/drm/drm_nomodeset.c | 24 +++++++++++++++++++ > > drivers/gpu/drm/i915/i915_module.c | 4 ++-- > > drivers/gpu/drm/mgag200/mgag200_drv.c | 4 ++-- > > drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++-- > > drivers/gpu/drm/qxl/qxl_drv.c | 4 ++-- > > drivers/gpu/drm/radeon/radeon_drv.c | 10 +++----- > > drivers/gpu/drm/tiny/bochs.c | 4 ++-- > > drivers/gpu/drm/tiny/cirrus.c | 5 ++-- > > drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++--- > > drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- > > drivers/video/console/vgacon.c | 21 ---------------- > > include/drm/drm_mode_config.h | 2 ++ > > include/linux/console.h | 6 ----- > > 19 files changed, 67 insertions(+), 60 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_nomodeset.c > > >
Hello Pekka, On 11/12/21 09:56, Pekka Paalanen wrote: [snip] > > Hi, > > these ideas make sense to me, so FWIW, > > Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> > Thanks. > There is one nitpick I'd like to ask about: > > +bool drm_get_modeset(void) > +{ > + return !drm_nomodeset; > +} > +EXPORT_SYMBOL(drm_get_modeset); > > Doesn't "get" have a special meaning in the kernel land, like "take a > strong reference on an object and return it"? That's a very good point. > As this is just returning bool without changing anything, the usual > word to use is "is". Since this function is also used at most once per > driver, which is rarely, it could have a long and descriptive name. > > For example: > > bool drm_is_modeset_driver_allowed(void); > Yeah, naming is hard. Jani also mentioned that he didn't like this function name, so I don't mind to re-spin the series only for that. > - "drm" is the namespace > - "is" implies it is a read-only boolean inspection > - "modeset" is the feature being checked > - "driver" implies it is supposed gate driver loading or > initialization, rather than modesets after drivers have loaded > - "allowed" says it is asking about general policy rather than what a > driver does > I believe that name is more verbose than needed. But don't have a strong opinion and could use it if others agree. > Just a bikeshed, I'll leave it to actual kernel devs to say if this > would be more appropriate or worth it. > I think is worth it and better to do it now before the patches land, but we could wait for others to chime in. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Hi Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas: > Hello Pekka, > > On 11/12/21 09:56, Pekka Paalanen wrote: > > [snip] > >> >> Hi, >> >> these ideas make sense to me, so FWIW, >> >> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> >> > > Thanks. > >> There is one nitpick I'd like to ask about: >> >> +bool drm_get_modeset(void) >> +{ >> + return !drm_nomodeset; >> +} >> +EXPORT_SYMBOL(drm_get_modeset); >> >> Doesn't "get" have a special meaning in the kernel land, like "take a >> strong reference on an object and return it"? > > That's a very good point. > >> As this is just returning bool without changing anything, the usual >> word to use is "is". Since this function is also used at most once per >> driver, which is rarely, it could have a long and descriptive name. >> >> For example: >> >> bool drm_is_modeset_driver_allowed(void); I'd nominate bool drm_native_drivers_enabled() This is what HW-specific drivers want to query in their init/probing code. The actual semantics of this decision is hidden from the driver. It's also easier to read than the other name IMHO Best regards Thomas >> > > Yeah, naming is hard. Jani also mentioned that he didn't like this > function name, so I don't mind to re-spin the series only for that. > >> - "drm" is the namespace >> - "is" implies it is a read-only boolean inspection >> - "modeset" is the feature being checked >> - "driver" implies it is supposed gate driver loading or >> initialization, rather than modesets after drivers have loaded >> - "allowed" says it is asking about general policy rather than what a >> driver does >> > > I believe that name is more verbose than needed. But don't have a > strong opinion and could use it if others agree. > >> Just a bikeshed, I'll leave it to actual kernel devs to say if this >> would be more appropriate or worth it. >> > > I think is worth it and better to do it now before the patches land, but > we could wait for others to chime in. > > Best regards, > -- > Javier Martinez Canillas > Linux Engineering > Red Hat >
On Fri, 12 Nov 2021 11:09:13 +0100 Thomas Zimmermann <tzimmermann@suse.de> wrote: > Hi > > Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas: > > Hello Pekka, > > > > On 11/12/21 09:56, Pekka Paalanen wrote: > > > > [snip] > > > >> > >> Hi, > >> > >> these ideas make sense to me, so FWIW, > >> > >> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> > >> > > > > Thanks. > > > >> There is one nitpick I'd like to ask about: > >> > >> +bool drm_get_modeset(void) > >> +{ > >> + return !drm_nomodeset; > >> +} > >> +EXPORT_SYMBOL(drm_get_modeset); > >> > >> Doesn't "get" have a special meaning in the kernel land, like "take a > >> strong reference on an object and return it"? > > > > That's a very good point. > > > >> As this is just returning bool without changing anything, the usual > >> word to use is "is". Since this function is also used at most once per > >> driver, which is rarely, it could have a long and descriptive name. > >> > >> For example: > >> > >> bool drm_is_modeset_driver_allowed(void); > > I'd nominate > > bool drm_native_drivers_enabled() > > This is what HW-specific drivers want to query in their init/probing > code. The actual semantics of this decision is hidden from the driver. > It's also easier to read than the other name IMHO Ok, but what is a "native driver"? Or a "non-native driver"? Is that established kernel terminology? I'd think a non-native driver is something that e.g. ndiswrapper is loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is the driver that would not consult this function, right? Thanks, pq > > Best regards > Thomas > > >> > > > > Yeah, naming is hard. Jani also mentioned that he didn't like this > > function name, so I don't mind to re-spin the series only for that. > > > >> - "drm" is the namespace > >> - "is" implies it is a read-only boolean inspection > >> - "modeset" is the feature being checked > >> - "driver" implies it is supposed gate driver loading or > >> initialization, rather than modesets after drivers have loaded > >> - "allowed" says it is asking about general policy rather than what a > >> driver does > >> > > > > I believe that name is more verbose than needed. But don't have a > > strong opinion and could use it if others agree. > > > >> Just a bikeshed, I'll leave it to actual kernel devs to say if this > >> would be more appropriate or worth it. > >> > > > > I think is worth it and better to do it now before the patches land, but > > we could wait for others to chime in. > > > > Best regards, > > -- > > Javier Martinez Canillas > > Linux Engineering > > Red Hat > > >
On 11/12/21 11:22, Pekka Paalanen wrote: [snip] >>> >>>> As this is just returning bool without changing anything, the usual >>>> word to use is "is". Since this function is also used at most once per >>>> driver, which is rarely, it could have a long and descriptive name. >>>> >>>> For example: >>>> >>>> bool drm_is_modeset_driver_allowed(void); >> >> I'd nominate >> >> bool drm_native_drivers_enabled() >> >> This is what HW-specific drivers want to query in their init/probing >> code. The actual semantics of this decision is hidden from the driver. >> It's also easier to read than the other name IMHO > > Ok, but what is a "native driver"? Or a "non-native driver"? > Is that established kernel terminology? > For me the term "native" is also vague. I would prefer to call it platform specific driver or non-generic driver instead. A problem is that "platform driver" has a very specific meaning in the kernel, which are drivers for devices in the "platform" bus (which is also a very overloaded term). > I'd think a non-native driver is something that e.g. ndiswrapper is Yeah, that's why I think that "generic" and "non-generic" is a better way to describe the drivers that could be used for any platform as long as the hardware was already initialized and a struct screen_info filled with data. > loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is > the driver that would not consult this function, right? > Correct. Or maybe just 'bool drm_modeset_enabled()' ? After all, that's really what the "nomodeset" kernel param disables. The fact that DRM drivers abuse that boolean semantics to also prevent the drivers to load is a different topic. > > Thanks, > pq > Best regards,
On Fri, 12 Nov 2021, Pekka Paalanen <ppaalanen@gmail.com> wrote: > On Fri, 12 Nov 2021 11:09:13 +0100 > Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> Hi >> >> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas: >> > Hello Pekka, >> > >> > On 11/12/21 09:56, Pekka Paalanen wrote: >> > >> > [snip] >> > >> >> >> >> Hi, >> >> >> >> these ideas make sense to me, so FWIW, >> >> >> >> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> >> >> >> > >> > Thanks. >> > >> >> There is one nitpick I'd like to ask about: >> >> >> >> +bool drm_get_modeset(void) >> >> +{ >> >> + return !drm_nomodeset; >> >> +} >> >> +EXPORT_SYMBOL(drm_get_modeset); >> >> >> >> Doesn't "get" have a special meaning in the kernel land, like "take a >> >> strong reference on an object and return it"? >> > >> > That's a very good point. >> > >> >> As this is just returning bool without changing anything, the usual >> >> word to use is "is". Since this function is also used at most once per >> >> driver, which is rarely, it could have a long and descriptive name. >> >> >> >> For example: >> >> >> >> bool drm_is_modeset_driver_allowed(void); >> >> I'd nominate >> >> bool drm_native_drivers_enabled() >> >> This is what HW-specific drivers want to query in their init/probing >> code. The actual semantics of this decision is hidden from the driver. >> It's also easier to read than the other name IMHO > > Ok, but what is a "native driver"? Or a "non-native driver"? > Is that established kernel terminology? FWIW, it doesn't mean anything to me. drm_modeset_enabled()? *sigh* I worked so hard not to participate in this bikeshed. ;) BR, Jani. > > I'd think a non-native driver is something that e.g. ndiswrapper is > loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is > the driver that would not consult this function, right? > > > Thanks, > pq > >> >> Best regards >> Thomas >> >> >> >> > >> > Yeah, naming is hard. Jani also mentioned that he didn't like this >> > function name, so I don't mind to re-spin the series only for that. >> > >> >> - "drm" is the namespace >> >> - "is" implies it is a read-only boolean inspection >> >> - "modeset" is the feature being checked >> >> - "driver" implies it is supposed gate driver loading or >> >> initialization, rather than modesets after drivers have loaded >> >> - "allowed" says it is asking about general policy rather than what a >> >> driver does >> >> >> > >> > I believe that name is more verbose than needed. But don't have a >> > strong opinion and could use it if others agree. >> > >> >> Just a bikeshed, I'll leave it to actual kernel devs to say if this >> >> would be more appropriate or worth it. >> >> >> > >> > I think is worth it and better to do it now before the patches land, but >> > we could wait for others to chime in. >> > >> > Best regards, >> > -- >> > Javier Martinez Canillas >> > Linux Engineering >> > Red Hat >> > >> >
Hi Am 12.11.21 um 11:22 schrieb Pekka Paalanen: > On Fri, 12 Nov 2021 11:09:13 +0100 > Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> Hi >> >> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas: >>> Hello Pekka, >>> >>> On 11/12/21 09:56, Pekka Paalanen wrote: >>> >>> [snip] >>> >>>> >>>> Hi, >>>> >>>> these ideas make sense to me, so FWIW, >>>> >>>> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> >>>> >>> >>> Thanks. >>> >>>> There is one nitpick I'd like to ask about: >>>> >>>> +bool drm_get_modeset(void) >>>> +{ >>>> + return !drm_nomodeset; >>>> +} >>>> +EXPORT_SYMBOL(drm_get_modeset); >>>> >>>> Doesn't "get" have a special meaning in the kernel land, like "take a >>>> strong reference on an object and return it"? >>> >>> That's a very good point. >>> >>>> As this is just returning bool without changing anything, the usual >>>> word to use is "is". Since this function is also used at most once per >>>> driver, which is rarely, it could have a long and descriptive name. >>>> >>>> For example: >>>> >>>> bool drm_is_modeset_driver_allowed(void); >> >> I'd nominate >> >> bool drm_native_drivers_enabled() >> >> This is what HW-specific drivers want to query in their init/probing >> code. The actual semantics of this decision is hidden from the driver. >> It's also easier to read than the other name IMHO > > Ok, but what is a "native driver"? Or a "non-native driver"? > Is that established kernel terminology? > > I'd think a non-native driver is something that e.g. ndiswrapper is > loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is > the driver that would not consult this function, right? We use that term for hw-specific drivers. A 'non-native' driver would be called generic or firmware driver. My concern with the 'modeset' term is that it exposes an implementation detail, which can mislead a driver to to the wrong thing: a HW-specifc driver that disables it's modesetting functionality would pass the test for (!modeset). But that's not what we want, we want to disable all of the driver and not even load it. How about we invert the test function and use something like bool drm_firmware_drivers_only() ? HW-native drivers can do if (drm_firmware_drivers_only()) return; as early as possible. fbdev uses the flag FBINFO_MISC_FIRMWARE to mark rsp drivers. So the terminology is there already. Best regards Thomas > > > Thanks, > pq > >> >> Best regards >> Thomas >> >>>> >>> >>> Yeah, naming is hard. Jani also mentioned that he didn't like this >>> function name, so I don't mind to re-spin the series only for that. >>> >>>> - "drm" is the namespace >>>> - "is" implies it is a read-only boolean inspection >>>> - "modeset" is the feature being checked >>>> - "driver" implies it is supposed gate driver loading or >>>> initialization, rather than modesets after drivers have loaded >>>> - "allowed" says it is asking about general policy rather than what a >>>> driver does >>>> >>> >>> I believe that name is more verbose than needed. But don't have a >>> strong opinion and could use it if others agree. >>> >>>> Just a bikeshed, I'll leave it to actual kernel devs to say if this >>>> would be more appropriate or worth it. >>>> >>> >>> I think is worth it and better to do it now before the patches land, but >>> we could wait for others to chime in. >>> >>> Best regards, >>> -- >>> Javier Martinez Canillas >>> Linux Engineering >>> Red Hat >>> >> >
On 11/12/21 11:57, Thomas Zimmermann wrote: [snip] >>> >>> This is what HW-specific drivers want to query in their init/probing >>> code. The actual semantics of this decision is hidden from the driver. >>> It's also easier to read than the other name IMHO >> >> Ok, but what is a "native driver"? Or a "non-native driver"? >> Is that established kernel terminology? >> >> I'd think a non-native driver is something that e.g. ndiswrapper is >> loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is >> the driver that would not consult this function, right? > > We use that term for hw-specific drivers. A 'non-native' driver would be > called generic or firmware driver. > > My concern with the 'modeset' term is that it exposes an implementation > detail, which can mislead a driver to to the wrong thing: a HW-specifc > driver that disables it's modesetting functionality would pass the test > for (!modeset). But that's not what we want, we want to disable all of > the driver and not even load it. > > How about we invert the test function and use something like > > bool drm_firmware_drivers_only() > That name I think is more self explanatory, so it works for me. There was also another bikeshed about where to put the function declaration, I added to <drm/drm_mode_config.h> but with that name I believe that should be in <drm/drm_drv.h> instead. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Hi Am 12.11.21 um 12:20 schrieb Javier Martinez Canillas: > On 11/12/21 11:57, Thomas Zimmermann wrote: > > [snip] > >>>> >>>> This is what HW-specific drivers want to query in their init/probing >>>> code. The actual semantics of this decision is hidden from the driver. >>>> It's also easier to read than the other name IMHO >>> >>> Ok, but what is a "native driver"? Or a "non-native driver"? >>> Is that established kernel terminology? >>> >>> I'd think a non-native driver is something that e.g. ndiswrapper is >>> loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is >>> the driver that would not consult this function, right? >> >> We use that term for hw-specific drivers. A 'non-native' driver would be >> called generic or firmware driver. >> >> My concern with the 'modeset' term is that it exposes an implementation >> detail, which can mislead a driver to to the wrong thing: a HW-specifc >> driver that disables it's modesetting functionality would pass the test >> for (!modeset). But that's not what we want, we want to disable all of >> the driver and not even load it. >> >> How about we invert the test function and use something like >> >> bool drm_firmware_drivers_only() >> > > That name I think is more self explanatory, so it works for me. > > There was also another bikeshed about where to put the function declaration, > I added to <drm/drm_mode_config.h> but with that name I believe that should > be in <drm/drm_drv.h> instead. I agree with drm_drv.h. It's a DRM-wide function and it fit's there best, I'd say. Best regards Thomas > > Best regards, -- > Javier Martinez Canillas > Linux Engineering > Red Hat >
On Fri, 12 Nov 2021 12:20:14 +0100 Javier Martinez Canillas <javierm@redhat.com> wrote: > On 11/12/21 11:57, Thomas Zimmermann wrote: > > [snip] > > >>> > >>> This is what HW-specific drivers want to query in their init/probing > >>> code. The actual semantics of this decision is hidden from the driver. > >>> It's also easier to read than the other name IMHO > >> > >> Ok, but what is a "native driver"? Or a "non-native driver"? > >> Is that established kernel terminology? > >> > >> I'd think a non-native driver is something that e.g. ndiswrapper is > >> loading. Is simpledrm like ndiswrapper in a sense? IIRC, simpledrm is > >> the driver that would not consult this function, right? > > > > We use that term for hw-specific drivers. A 'non-native' driver would be > > called generic or firmware driver. > > > > My concern with the 'modeset' term is that it exposes an implementation > > detail, which can mislead a driver to to the wrong thing: a HW-specifc > > driver that disables it's modesetting functionality would pass the test > > for (!modeset). But that's not what we want, we want to disable all of > > the driver and not even load it. > > > > How about we invert the test function and use something like > > > > bool drm_firmware_drivers_only() > > > > That name I think is more self explanatory, so it works for me. I'm not going to argue against that. :-) Thanks, pq
There is a lot of historical baggage on this parameter. It is defined in the vgacon driver as nomodeset, but its set function is called text_mode() and the value queried with a function named vgacon_text_force(). All this implies that it's about forcing text mode for VGA, yet it is not used in neither vgacon nor other console driver. The only users for these are DRM drivers, that check for the vgacon_text_force() return value to determine whether the driver should be loaded or not. That makes it quite confusing to read the code, because the variables and function names don't reflect what they actually do and also are not in the same subsystem as the drivers that make use of them. This patch-set attempts to cleanup the code by moving the nomodseset param to the DRM subsystem and do some renaming to make their intention clearer. This is a v4 of the patches, that address issues pointed out by Thomas Zimmermann in v3: https://lkml.org/lkml/2021/11/8/384 Patch #1 and #2 are just trivial cleanups. Patch #3 moves the nomodeset boot option to the DRM subsystem and renames the variables and functions names. Patch #4 removes the relationship between the nomodeset parameter and the CONFIG_VGA_CONSOLE Kconfig symbol. Patch #5 adds nomodeset to the kernel parameters documentation. Patch #6 improves the message when nomodeset is enabled to make it more accurate and less sensational. Changes in v4: - Don't mention the simpledrm driver and instead explain in high level terms what the nomodeset option is about. - Don't mention DRM drivers in the kernel message and instead explain that only the system framebuffer will be available. Changes in v3: - Drop the drm_drv_enabled() function and just call to drm_get_modeset(). - Make drm_get_modeset() just a getter function and don't return an error. - Move independent cleanups in drivers as separate preparatory patches. Changes in v2: - Conditionally build drm_nomodeset.o if CONFIG_VGA_CONSOLE is set. - Squash patches to move nomodeset logic to DRM and do the renaming. - Name the function drm_check_modeset() and make it return -ENODEV. - Squash patch to add drm_drv_enabled() and make drivers use it. - Make the drivers changes before moving nomodeset logic to DRM. - Make drm_drv_enabled() return an errno and -ENODEV if nomodeset. - Remove debug and error messages in drivers. Javier Martinez Canillas (6): drm: Don't print messages if drivers are disabled due nomodeset drm/vboxvideo: Drop CONFIG_VGA_CONSOLE guard to call vgacon_text_force() drm: Move nomodeset kernel parameter to the DRM subsystem drm: Decouple nomodeset from CONFIG_VGA_CONSOLE Documentation/admin-guide: Document nomodeset kernel parameter drm: Make the nomodeset message less sensational .../admin-guide/kernel-parameters.txt | 7 ++++++ drivers/gpu/drm/Kconfig | 6 +++++ drivers/gpu/drm/Makefile | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++--- drivers/gpu/drm/ast/ast_drv.c | 4 ++-- drivers/gpu/drm/drm_nomodeset.c | 24 +++++++++++++++++++ drivers/gpu/drm/i915/i915_module.c | 4 ++-- drivers/gpu/drm/mgag200/mgag200_drv.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++-- drivers/gpu/drm/qxl/qxl_drv.c | 4 ++-- drivers/gpu/drm/radeon/radeon_drv.c | 10 +++----- drivers/gpu/drm/tiny/bochs.c | 4 ++-- drivers/gpu/drm/tiny/cirrus.c | 5 ++-- drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++--- drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-- drivers/video/console/vgacon.c | 21 ---------------- include/drm/drm_mode_config.h | 2 ++ include/linux/console.h | 6 ----- 19 files changed, 67 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/drm_nomodeset.c