[PATCH v5 06/12] drm/modes: Support modes names on the command line

Thierry Reding thierry.reding at gmail.com
Wed Jun 26 15:26:59 UTC 2019


On Mon, Jun 17, 2019 at 04:51:33PM +0200, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard at 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 at tronnes.org>
> Signed-off-by: Maxime Ripard <maxime.ripard at 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 at 0xf0000000 sdhci_tegra.en_boot_part_access=1
	...
	[   18.597001] [drm:drm_connector_init [drm]] cmdline mode for connector DP-1 tegrafb 0x0 at 60Hz
	...
	[   18.627145] [drm:drm_connector_init [drm]] cmdline mode for connector DP-2 tegrafb 0x0 at 60Hz
	...
	[   18.673770] [drm:drm_connector_init [drm]] cmdline mode for connector HDMI-A-1 tegrafb 0x0 at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190626/39f65a9a/attachment-0001.sig>


More information about the dri-devel mailing list