| Message ID | 18443e0c3bdbbd16cea4ec63bc7f2079b820b43b.1560783090.git-series.maxime.ripard@bootlin.com |
|---|---|
| State | Accepted |
| Commit | 3aeeb13d899627fe2b86bdbdcd0927cf7192234f |
| Headers | show |
| Series | None | expand |
On Mon, Jun 17, 2019 at 04:51:33PM +0200, Maxime Ripard wrote: > From: Maxime Ripard <maxime.ripard@free-electrons.com> > > The drm subsystem also uses the video= kernel parameter, and in the > documentation refers to the fbdev documentation for that parameter. > > However, that documentation also says that instead of giving the mode using > its resolution we can also give a name. However, DRM doesn't handle that > case at the moment. Even though in most case it shouldn't make any > difference, it might be useful for analog modes, where different standards > might have the same resolution, but still have a few different parameters > that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). > > Reviewed-by: Noralf Trønnes <noralf@tronnes.org> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/gpu/drm/drm_client_modeset.c | 4 ++- > drivers/gpu/drm/drm_connector.c | 3 +- > drivers/gpu/drm/drm_modes.c | 62 +++++++++++++++++++++-------- > include/drm/drm_connector.h | 7 +++- > 4 files changed, 59 insertions(+), 17 deletions(-) This patch causes an issue on various Tegra boards that have so far been running flawlessly. Here's an extract from the boot log: [ 0.000000] Kernel command line: root=/dev/nfs rw netdevwait ip=:::::eth0:on nfsroot=192.168.23.1:/srv/nfs/tegra194 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 vpr=0x8000000@0xf0000000 sdhci_tegra.en_boot_part_access=1 ... [ 18.597001] [drm:drm_connector_init [drm]] cmdline mode for connector DP-1 tegrafb 0x0@60Hz ... [ 18.627145] [drm:drm_connector_init [drm]] cmdline mode for connector DP-2 tegrafb 0x0@60Hz ... [ 18.673770] [drm:drm_connector_init [drm]] cmdline mode for connector HDMI-A-1 tegrafb 0x0@60Hz ... [ 19.057500] [drm:drm_mode_debug_printmodeline [drm]] Modeline "0x0": 0 0 0 0 0 0 0 1 4 1 0x20 0x6 [ 19.066341] [drm:drm_mode_prune_invalid [drm]] Not using 0x0 mode: CLOCK_LOW ... [ 19.677803] [drm:drm_client_modeset_probe [drm]] looking for cmdline mode on connector 60 [ 19.686019] [drm:drm_client_modeset_probe [drm]] found mode 0x0 ... [ 19.851843] drm drm: failed to set initial configuration: -28 So basically what's happening here is that the bootloader is passing a video= parameter on the command-line and after this patch, the DRM core will consider the tegrafb in that parameter to be a named video mode. The mode is then filtered out because it doesn't make any sense, but then drm_client_modeset_probe() still tries to use it, eventually leading to failure because we can't allocate memory for a 0x0 framebuffer. Now, there are obviously a couple of places where things go wrong. On one hand I think if the mode specified on the command-line is already filtered out, then drm_client_modeset_probe() should not be trying to use it. One could also argue that the bootloader shouldn't be passing that video=tegrafb parameter in the first place. Then again, this is nothing out of the ordinary (as documented in Documentation/fb/modedb.rst). The problem with named modes, and you already highlighted this in your comment in the code, is that it's not possible to distinguish between a mode name and a video= option that defines the framebuffer device to use. That said, I wouldn't be surprised if this change ended up breaking on other devices. I'm also not sure that under these circumstances it's a good idea to support named modes. At least not until we have a better way of determining what's a real mode name and what isn't. Looking at the old modedb from fb, not even the standard modes listed there have names associated with them, so I'm not sure how this was ever supposed to work. From the looks of it, some of the fbdev drivers seem to take a mode list from board-code (see for example the mx21ads_modes array from arch/arm/mach-imx/mach-mx21ads.c). The imxfb driver can then take a mode name from the command line and try to match it against a list of known modes. That seems to match what the documentation says. However, that also really only works because this is all directly dealt with in the fbdev drivers. For DRM/KMS we don't do that and instead we rely on the core to provide this backwards-compatibility. However, at the time when we parse the mode from the command line we don't have the list of modes that are considered to be valid, so your patch currently needs to assume that it is a valid mode. I don't think that's a good idea, because clearly not all strings that currently make it through the filter are actually modes. So if we really need this, I think we want some way for the connector to provide the list of named modes that it supports so that by the time we want to parse the command-line we can check whether it's actually a name to avoid false positives like the ones I'm seeing on Tegra. For now it might just be easiest to avoid any of this and disable the named mode support until it's a bit more mature. The patch no longer reverts cleanly, but it should be fairly easy to disable the feature in a follow-up patch again. Thierry > diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c > index 4869a0170bec..33d4988f22ae 100644 > --- a/drivers/gpu/drm/drm_client_modeset.c > +++ b/drivers/gpu/drm/drm_client_modeset.c > @@ -149,6 +149,10 @@ drm_connector_pick_cmdline_mode(struct drm_connector *connector) > prefer_non_interlace = !cmdline_mode->interlace; > again: > list_for_each_entry(mode, &connector->modes, head) { > + /* Check (optional) mode name first */ > + if (!strcmp(mode->name, cmdline_mode->name)) > + return mode; > + > /* check width/height */ > if (mode->hdisplay != cmdline_mode->xres || > mode->vdisplay != cmdline_mode->yres) > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index 3ccdcf3dfcde..3afed5677946 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -139,8 +139,9 @@ static void drm_connector_get_cmdline_mode(struct drm_connector *connector) > connector->force = mode->force; > } > > - DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n", > + DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n", > connector->name, > + mode->name ? mode->name : "", > mode->xres, mode->yres, > mode->refresh_specified ? mode->refresh : 60, > mode->rb ? " reduced blanking" : "", > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index 6debbd6c1763..429d3be17800 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1580,7 +1580,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, > struct drm_cmdline_mode *mode) > { > const char *name; > - bool parse_extras = false; > + bool named_mode = false, parse_extras = false; > unsigned int bpp_off = 0, refresh_off = 0; > unsigned int mode_end = 0; > char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL; > @@ -1599,8 +1599,22 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, > > name = mode_option; > > - if (!isdigit(name[0])) > - return false; > + /* > + * This is a bit convoluted. To differentiate between the > + * named modes and poorly formatted resolutions, we need a > + * bunch of things: > + * - We need to make sure that the first character (which > + * would be our resolution in X) is a digit. > + * - However, if the X resolution is missing, then we end up > + * with something like x<yres>, with our first character > + * being an alpha-numerical character, which would be > + * considered a named mode. > + * > + * If this isn't enough, we should add more heuristics here, > + * and matching unit-tests. > + */ > + if (!isdigit(name[0]) && name[0] != 'x') > + named_mode = true; > > /* Try to locate the bpp and refresh specifiers, if any */ > bpp_ptr = strchr(name, '-'); > @@ -1611,6 +1625,9 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, > > refresh_ptr = strchr(name, '@'); > if (refresh_ptr) { > + if (named_mode) > + return false; > + > refresh_off = refresh_ptr - name; > mode->refresh_specified = true; > } > @@ -1627,12 +1644,16 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, > parse_extras = true; > } > > - ret = drm_mode_parse_cmdline_res_mode(name, mode_end, > - parse_extras, > - connector, > - mode); > - if (ret) > - return false; > + if (named_mode) { > + strncpy(mode->name, name, mode_end); > + } else { > + ret = drm_mode_parse_cmdline_res_mode(name, mode_end, > + parse_extras, > + connector, > + mode); > + if (ret) > + return false; > + } > mode->specified = true; > > if (bpp_ptr) { > @@ -1660,14 +1681,23 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, > extra_ptr = refresh_end_ptr; > > if (extra_ptr) { > - int remaining = strlen(name) - (extra_ptr - name); > + if (!named_mode) { > + int len = strlen(name) - (extra_ptr - name); > > - /* > - * We still have characters to process, while > - * we shouldn't have any > - */ > - if (remaining > 0) > - return false; > + ret = drm_mode_parse_cmdline_extra(extra_ptr, len, > + connector, mode); > + if (ret) > + return false; > + } else { > + int remaining = strlen(name) - (extra_ptr - name); > + > + /* > + * We still have characters to process, while > + * we shouldn't have any > + */ > + if (remaining > 0) > + return false; > + } > } > > return true; > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h > index c802780b0bfc..cdf2fb910010 100644 > --- a/include/drm/drm_connector.h > +++ b/include/drm/drm_connector.h > @@ -933,6 +933,13 @@ struct drm_connector_funcs { > */ > struct drm_cmdline_mode { > /** > + * @name: > + * > + * Name of the mode. > + */ > + char name[DRM_DISPLAY_MODE_LEN]; > + > + /** > * @specified: > * > * Has a mode been read from the command-line? > -- > git-series 0.9.1 > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Thierry, On Wed, Jun 26, 2019 at 05:26:59PM +0200, Thierry Reding wrote: > On Mon, Jun 17, 2019 at 04:51:33PM +0200, Maxime Ripard wrote: > > From: Maxime Ripard <maxime.ripard@free-electrons.com> > > > > The drm subsystem also uses the video= kernel parameter, and in the > > documentation refers to the fbdev documentation for that parameter. > > > > However, that documentation also says that instead of giving the mode using > > its resolution we can also give a name. However, DRM doesn't handle that > > case at the moment. Even though in most case it shouldn't make any > > difference, it might be useful for analog modes, where different standards > > might have the same resolution, but still have a few different parameters > > that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). > > > > Reviewed-by: Noralf Trønnes <noralf@tronnes.org> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/gpu/drm/drm_client_modeset.c | 4 ++- > > drivers/gpu/drm/drm_connector.c | 3 +- > > drivers/gpu/drm/drm_modes.c | 62 +++++++++++++++++++++-------- > > include/drm/drm_connector.h | 7 +++- > > 4 files changed, 59 insertions(+), 17 deletions(-) > > This patch causes an issue on various Tegra boards that have so far been > running flawlessly. Here's an extract from the boot log: > > [ 0.000000] Kernel command line: root=/dev/nfs rw netdevwait ip=:::::eth0:on nfsroot=192.168.23.1:/srv/nfs/tegra194 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues=0.2.2 vpr=0x8000000@0xf0000000 sdhci_tegra.en_boot_part_access=1 > ... > [ 18.597001] [drm:drm_connector_init [drm]] cmdline mode for connector DP-1 tegrafb 0x0@60Hz > ... > [ 18.627145] [drm:drm_connector_init [drm]] cmdline mode for connector DP-2 tegrafb 0x0@60Hz > ... > [ 18.673770] [drm:drm_connector_init [drm]] cmdline mode for connector HDMI-A-1 tegrafb 0x0@60Hz > ... > [ 19.057500] [drm:drm_mode_debug_printmodeline [drm]] Modeline "0x0": 0 0 0 0 0 0 0 1 4 1 0x20 0x6 > [ 19.066341] [drm:drm_mode_prune_invalid [drm]] Not using 0x0 mode: CLOCK_LOW > ... > [ 19.677803] [drm:drm_client_modeset_probe [drm]] looking for cmdline mode on connector 60 > [ 19.686019] [drm:drm_client_modeset_probe [drm]] found mode 0x0 > ... > [ 19.851843] drm drm: failed to set initial configuration: -28 > > So basically what's happening here is that the bootloader is passing a > video= parameter on the command-line and after this patch, the DRM core > will consider the tegrafb in that parameter to be a named video mode. > The mode is then filtered out because it doesn't make any sense, but > then drm_client_modeset_probe() still tries to use it, eventually > leading to failure because we can't allocate memory for a 0x0 > framebuffer. What was the behaviour before? That it wouldn't set a mode at all? > Now, there are obviously a couple of places where things go wrong. On > one hand I think if the mode specified on the command-line is already > filtered out, then drm_client_modeset_probe() should not be trying to > use it. Yeah, that would make sense > One could also argue that the bootloader shouldn't be passing that > video=tegrafb parameter in the first place. Then again, this is nothing > out of the ordinary (as documented in Documentation/fb/modedb.rst). I've read that documentation, and I'm not sure which section in there allows to do that? > The problem with named modes, and you already highlighted this in your > comment in the code, is that it's not possible to distinguish between a > mode name and a video= option that defines the framebuffer device to > use. > > That said, I wouldn't be surprised if this change ended up breaking on > other devices. I'm also not sure that under these circumstances it's a > good idea to support named modes. At least not until we have a better > way of determining what's a real mode name and what isn't. Looking at > the old modedb from fb, not even the standard modes listed there have > names associated with them, so I'm not sure how this was ever supposed > to work. From the looks of it, some of the fbdev drivers seem to take a > mode list from board-code (see for example the mx21ads_modes array from > arch/arm/mach-imx/mach-mx21ads.c). The imxfb driver can then take a mode > name from the command line and try to match it against a list of known > modes. That seems to match what the documentation says. > > However, that also really only works because this is all directly dealt > with in the fbdev drivers. For DRM/KMS we don't do that and instead we > rely on the core to provide this backwards-compatibility. However, at > the time when we parse the mode from the command line we don't have the > list of modes that are considered to be valid, so your patch currently > needs to assume that it is a valid mode. I don't think that's a good > idea, because clearly not all strings that currently make it through the > filter are actually modes. We have a list of named modes in the connector, and we match against that. It already works for sunxi (minus the bugs..). > So if we really need this, I think we want some way for the connector to > provide the list of named modes that it supports so that by the time we > want to parse the command-line we can check whether it's actually a name > to avoid false positives like the ones I'm seeing on Tegra. I guess that could work yep > For now it might just be easiest to avoid any of this and disable the > named mode support until it's a bit more mature. The patch no longer > reverts cleanly, but it should be fairly easy to disable the feature in > a follow-up patch again. If we were to do that, I'd really like to have least get a unit test for that case, and some documentation on how we're supposed to deal with this case. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 4869a0170bec..33d4988f22ae 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -149,6 +149,10 @@ drm_connector_pick_cmdline_mode(struct drm_connector *connector) prefer_non_interlace = !cmdline_mode->interlace; again: list_for_each_entry(mode, &connector->modes, head) { + /* Check (optional) mode name first */ + if (!strcmp(mode->name, cmdline_mode->name)) + return mode; + /* check width/height */ if (mode->hdisplay != cmdline_mode->xres || mode->vdisplay != cmdline_mode->yres) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 3ccdcf3dfcde..3afed5677946 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -139,8 +139,9 @@ static void drm_connector_get_cmdline_mode(struct drm_connector *connector) connector->force = mode->force; } - DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n", + DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n", connector->name, + mode->name ? mode->name : "", mode->xres, mode->yres, mode->refresh_specified ? mode->refresh : 60, mode->rb ? " reduced blanking" : "", diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6debbd6c1763..429d3be17800 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1580,7 +1580,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, struct drm_cmdline_mode *mode) { const char *name; - bool parse_extras = false; + bool named_mode = false, parse_extras = false; unsigned int bpp_off = 0, refresh_off = 0; unsigned int mode_end = 0; char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL; @@ -1599,8 +1599,22 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, name = mode_option; - if (!isdigit(name[0])) - return false; + /* + * This is a bit convoluted. To differentiate between the + * named modes and poorly formatted resolutions, we need a + * bunch of things: + * - We need to make sure that the first character (which + * would be our resolution in X) is a digit. + * - However, if the X resolution is missing, then we end up + * with something like x<yres>, with our first character + * being an alpha-numerical character, which would be + * considered a named mode. + * + * If this isn't enough, we should add more heuristics here, + * and matching unit-tests. + */ + if (!isdigit(name[0]) && name[0] != 'x') + named_mode = true; /* Try to locate the bpp and refresh specifiers, if any */ bpp_ptr = strchr(name, '-'); @@ -1611,6 +1625,9 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, refresh_ptr = strchr(name, '@'); if (refresh_ptr) { + if (named_mode) + return false; + refresh_off = refresh_ptr - name; mode->refresh_specified = true; } @@ -1627,12 +1644,16 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, parse_extras = true; } - ret = drm_mode_parse_cmdline_res_mode(name, mode_end, - parse_extras, - connector, - mode); - if (ret) - return false; + if (named_mode) { + strncpy(mode->name, name, mode_end); + } else { + ret = drm_mode_parse_cmdline_res_mode(name, mode_end, + parse_extras, + connector, + mode); + if (ret) + return false; + } mode->specified = true; if (bpp_ptr) { @@ -1660,14 +1681,23 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option, extra_ptr = refresh_end_ptr; if (extra_ptr) { - int remaining = strlen(name) - (extra_ptr - name); + if (!named_mode) { + int len = strlen(name) - (extra_ptr - name); - /* - * We still have characters to process, while - * we shouldn't have any - */ - if (remaining > 0) - return false; + ret = drm_mode_parse_cmdline_extra(extra_ptr, len, + connector, mode); + if (ret) + return false; + } else { + int remaining = strlen(name) - (extra_ptr - name); + + /* + * We still have characters to process, while + * we shouldn't have any + */ + if (remaining > 0) + return false; + } } return true; diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index c802780b0bfc..cdf2fb910010 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -933,6 +933,13 @@ struct drm_connector_funcs { */ struct drm_cmdline_mode { /** + * @name: + * + * Name of the mode. + */ + char name[DRM_DISPLAY_MODE_LEN]; + + /** * @specified: * * Has a mode been read from the command-line?