All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: maxime@cerno.tech, Karol Herbst <kherbst@redhat.com>,
	Emma Anholt <emma@anholt.net>, Ben Skeggs <bskeggs@redhat.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <mripard@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Lyude Paul <lyude@redhat.com>
Cc: linux-sunxi@lists.linux.dev, intel-gfx@lists.freedesktop.org,
	"Phil Elwell" <phil@raspberrypi.com>,
	linux-arm-kernel@lists.infradead.org,
	nouveau@lists.freedesktop.org,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Dom Cobley" <dom@raspberrypi.com>,
	dri-devel@lists.freedesktop.org,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	linux-kernel@vger.kernel.org,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>
Subject: Re: [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Date: Thu, 27 Oct 2022 00:02:24 +0200	[thread overview]
Message-ID: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com> (raw)
In-Reply-To: <20220728-rpi-analog-tv-properties-v6-16-e7792734108f@cerno.tech>

Hi Maxime,

First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!

But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder them. Maybe it can be simplified somehow?

Although when I tried to refactor it myself, I ended up with something that's
not better at all. Maybe it needs to be complicated, after all :(

Anyway, the current version seems to have a couple of bugs:

> +	if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> +		mode = drm_mode_analog_pal_576i(connector->dev);
> +		if (!mode)
> +			return 0;
> +
> +		tv_modes[count++] = mode;
> +	}

If the 480i mode has been created properly, but there's an error creating the
576i one (we enter the if (!mode) clause), the 480i mode will leak.

> +	if (count == 1) {

You're handling the count == 1 case specially, but if count == 0, the rest of
the code will assume that two modes exist and probably segfault in the process.

> +	ret = drm_object_property_get_default_value(&connector->base,
> +						    dev->mode_config.tv_mode_property,
> +						    &default_mode);
> +	if (ret)
> +		return 0;
> +
> +	if (cmdline->tv_mode_specified)
> +		default_mode = cmdline->tv_mode;

In case of an error (ret != 0), the modes created so far in the tv_modes array
will leak.

Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.

Best regards,
Mateusz Kwiatkowski


WARNING: multiple messages have this Message-ID (diff)
From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: maxime@cerno.tech, Karol Herbst <kherbst@redhat.com>,
	Emma Anholt <emma@anholt.net>, Ben Skeggs <bskeggs@redhat.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <mripard@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Lyude Paul <lyude@redhat.com>
Cc: "Dom Cobley" <dom@raspberrypi.com>,
	nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	linux-sunxi@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Nouveau] [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Date: Thu, 27 Oct 2022 00:02:24 +0200	[thread overview]
Message-ID: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com> (raw)
In-Reply-To: <20220728-rpi-analog-tv-properties-v6-16-e7792734108f@cerno.tech>

Hi Maxime,

First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!

But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder them. Maybe it can be simplified somehow?

Although when I tried to refactor it myself, I ended up with something that's
not better at all. Maybe it needs to be complicated, after all :(

Anyway, the current version seems to have a couple of bugs:

> +	if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> +		mode = drm_mode_analog_pal_576i(connector->dev);
> +		if (!mode)
> +			return 0;
> +
> +		tv_modes[count++] = mode;
> +	}

If the 480i mode has been created properly, but there's an error creating the
576i one (we enter the if (!mode) clause), the 480i mode will leak.

> +	if (count == 1) {

You're handling the count == 1 case specially, but if count == 0, the rest of
the code will assume that two modes exist and probably segfault in the process.

> +	ret = drm_object_property_get_default_value(&connector->base,
> +						    dev->mode_config.tv_mode_property,
> +						    &default_mode);
> +	if (ret)
> +		return 0;
> +
> +	if (cmdline->tv_mode_specified)
> +		default_mode = cmdline->tv_mode;

In case of an error (ret != 0), the modes created so far in the tv_modes array
will leak.

Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.

Best regards,
Mateusz Kwiatkowski


WARNING: multiple messages have this Message-ID (diff)
From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: maxime@cerno.tech, Karol Herbst <kherbst@redhat.com>,
	Emma Anholt <emma@anholt.net>, Ben Skeggs <bskeggs@redhat.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <mripard@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Lyude Paul <lyude@redhat.com>
Cc: "Dom Cobley" <dom@raspberrypi.com>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	linux-sunxi@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Date: Thu, 27 Oct 2022 00:02:24 +0200	[thread overview]
Message-ID: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com> (raw)
In-Reply-To: <20220728-rpi-analog-tv-properties-v6-16-e7792734108f@cerno.tech>

Hi Maxime,

First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!

But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder them. Maybe it can be simplified somehow?

Although when I tried to refactor it myself, I ended up with something that's
not better at all. Maybe it needs to be complicated, after all :(

Anyway, the current version seems to have a couple of bugs:

> +	if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> +		mode = drm_mode_analog_pal_576i(connector->dev);
> +		if (!mode)
> +			return 0;
> +
> +		tv_modes[count++] = mode;
> +	}

If the 480i mode has been created properly, but there's an error creating the
576i one (we enter the if (!mode) clause), the 480i mode will leak.

> +	if (count == 1) {

You're handling the count == 1 case specially, but if count == 0, the rest of
the code will assume that two modes exist and probably segfault in the process.

> +	ret = drm_object_property_get_default_value(&connector->base,
> +						    dev->mode_config.tv_mode_property,
> +						    &default_mode);
> +	if (ret)
> +		return 0;
> +
> +	if (cmdline->tv_mode_specified)
> +		default_mode = cmdline->tv_mode;

In case of an error (ret != 0), the modes created so far in the tv_modes array
will leak.

Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.

Best regards,
Mateusz Kwiatkowski


WARNING: multiple messages have this Message-ID (diff)
From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: maxime@cerno.tech, Karol Herbst <kherbst@redhat.com>,
	Emma Anholt <emma@anholt.net>, Ben Skeggs <bskeggs@redhat.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <mripard@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Lyude Paul <lyude@redhat.com>
Cc: "Dom Cobley" <dom@raspberrypi.com>,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Phil Elwell" <phil@raspberrypi.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	linux-sunxi@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Intel-gfx] [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Date: Thu, 27 Oct 2022 00:02:24 +0200	[thread overview]
Message-ID: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com> (raw)
In-Reply-To: <20220728-rpi-analog-tv-properties-v6-16-e7792734108f@cerno.tech>

Hi Maxime,

First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!

But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder them. Maybe it can be simplified somehow?

Although when I tried to refactor it myself, I ended up with something that's
not better at all. Maybe it needs to be complicated, after all :(

Anyway, the current version seems to have a couple of bugs:

> +	if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> +		mode = drm_mode_analog_pal_576i(connector->dev);
> +		if (!mode)
> +			return 0;
> +
> +		tv_modes[count++] = mode;
> +	}

If the 480i mode has been created properly, but there's an error creating the
576i one (we enter the if (!mode) clause), the 480i mode will leak.

> +	if (count == 1) {

You're handling the count == 1 case specially, but if count == 0, the rest of
the code will assume that two modes exist and probably segfault in the process.

> +	ret = drm_object_property_get_default_value(&connector->base,
> +						    dev->mode_config.tv_mode_property,
> +						    &default_mode);
> +	if (ret)
> +		return 0;
> +
> +	if (cmdline->tv_mode_specified)
> +		default_mode = cmdline->tv_mode;

In case of an error (ret != 0), the modes created so far in the tv_modes array
will leak.

Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.

Best regards,
Mateusz Kwiatkowski


WARNING: multiple messages have this Message-ID (diff)
From: Mateusz Kwiatkowski <kfyatek@gmail.com>
To: maxime@cerno.tech, Karol Herbst <kherbst@redhat.com>,
	Emma Anholt <emma@anholt.net>, Ben Skeggs <bskeggs@redhat.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Maxime Ripard <mripard@kernel.org>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Lyude Paul <lyude@redhat.com>
Cc: linux-sunxi@lists.linux.dev, intel-gfx@lists.freedesktop.org,
	"Phil Elwell" <phil@raspberrypi.com>,
	linux-arm-kernel@lists.infradead.org,
	nouveau@lists.freedesktop.org,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Dom Cobley" <dom@raspberrypi.com>,
	dri-devel@lists.freedesktop.org,
	"Dave Stevenson" <dave.stevenson@raspberrypi.com>,
	linux-kernel@vger.kernel.org,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>
Subject: Re: [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Date: Thu, 27 Oct 2022 00:02:24 +0200	[thread overview]
Message-ID: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com> (raw)
In-Reply-To: <20220728-rpi-analog-tv-properties-v6-16-e7792734108f@cerno.tech>

Hi Maxime,

First of all, nice idea with the helper function that can be reused by different
drivers. This is neat!

But looking at this function, it feels a bit overcomplicated. You're creating
the two modes, then checking which one is the default, then set the preferred
one and possibly reorder them. Maybe it can be simplified somehow?

Although when I tried to refactor it myself, I ended up with something that's
not better at all. Maybe it needs to be complicated, after all :(

Anyway, the current version seems to have a couple of bugs:

> +	if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> +	    tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> +		mode = drm_mode_analog_pal_576i(connector->dev);
> +		if (!mode)
> +			return 0;
> +
> +		tv_modes[count++] = mode;
> +	}

If the 480i mode has been created properly, but there's an error creating the
576i one (we enter the if (!mode) clause), the 480i mode will leak.

> +	if (count == 1) {

You're handling the count == 1 case specially, but if count == 0, the rest of
the code will assume that two modes exist and probably segfault in the process.

> +	ret = drm_object_property_get_default_value(&connector->base,
> +						    dev->mode_config.tv_mode_property,
> +						    &default_mode);
> +	if (ret)
> +		return 0;
> +
> +	if (cmdline->tv_mode_specified)
> +		default_mode = cmdline->tv_mode;

In case of an error (ret != 0), the modes created so far in the tv_modes array
will leak.

Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.

Best regards,
Mateusz Kwiatkowski


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-10-26 22:02 UTC|newest]

Thread overview: 222+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26 15:33 [PATCH v6 00/23] drm: Analog TV Improvements maxime
2022-10-26 15:33 ` maxime
2022-10-26 15:33 ` [Intel-gfx] " maxime
2022-10-26 15:33 ` maxime
2022-10-26 15:33 ` [Nouveau] " maxime
2022-10-26 15:33 ` [Intel-gfx] [PATCH v6 01/23] drm/tests: Add Kunit Helpers maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33 ` [PATCH v6 02/23] drm/connector: Rename legacy TV property maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 03/23] drm/connector: Only register TV mode property if present maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 04/23] drm/connector: Rename drm_mode_create_tv_properties maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 05/23] drm/connector: Add TV standard property maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 06/23] drm/modes: Add a function to generate analog display modes maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 07/23] drm/client: Add some tests for drm_connector_pick_cmdline_mode() maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 08/23] drm/modes: Move named modes parsing to a separate function maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-11-05 14:02   ` Noralf Trønnes
2022-11-05 14:02     ` [Intel-gfx] " Noralf Trønnes
2022-11-05 14:02     ` Noralf Trønnes
2022-11-05 14:02     ` Noralf Trønnes
2022-11-05 14:02     ` [Nouveau] " Noralf Trønnes
2022-10-26 15:33 ` [PATCH v6 09/23] drm/modes: Switch to named mode descriptors maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-11-05 14:06   ` Noralf Trønnes
2022-11-05 14:06     ` Noralf Trønnes
2022-11-05 14:06     ` [Intel-gfx] " Noralf Trønnes
2022-11-05 14:06     ` Noralf Trønnes
2022-11-05 14:06     ` [Nouveau] " Noralf Trønnes
2022-10-26 15:33 ` [PATCH v6 10/23] drm/modes: Fill drm_cmdline mode from named modes maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-11-06 13:04   ` Noralf Trønnes
2022-11-06 13:04     ` Noralf Trønnes
2022-11-06 13:04     ` [Intel-gfx] " Noralf Trønnes
2022-11-06 13:04     ` Noralf Trønnes
2022-11-06 13:04     ` [Nouveau] " Noralf Trønnes
2022-11-07 10:02     ` Maxime Ripard
2022-11-07 10:02       ` Maxime Ripard
2022-11-07 10:02       ` [Intel-gfx] " Maxime Ripard
2022-11-07 10:02       ` Maxime Ripard
2022-11-07 10:02       ` [Nouveau] " Maxime Ripard
2022-10-26 15:33 ` [PATCH v6 11/23] drm/connector: Add pixel clock to cmdline mode maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-11-06 13:06   ` Noralf Trønnes
2022-11-06 13:06     ` [Intel-gfx] " Noralf Trønnes
2022-11-06 13:06     ` Noralf Trønnes
2022-11-06 13:06     ` Noralf Trønnes
2022-11-06 13:06     ` [Nouveau] " Noralf Trønnes
2022-10-26 15:33 ` [PATCH v6 12/23] drm/connector: Add a function to lookup a TV mode by its name maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 13/23] drm/modes: Introduce the tv_mode property as a command-line option maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-11-06 13:10   ` Noralf Trønnes
2022-11-06 13:10     ` Noralf Trønnes
2022-11-06 13:10     ` [Intel-gfx] " Noralf Trønnes
2022-11-06 13:10     ` Noralf Trønnes
2022-11-06 13:10     ` [Nouveau] " Noralf Trønnes
2022-11-06 15:51     ` Lukas Satin
2022-10-26 15:33 ` [PATCH v6 14/23] drm/modes: Properly generate a drm_display_mode from a named mode maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 21:25   ` Mateusz Kwiatkowski
2022-10-26 21:25     ` Mateusz Kwiatkowski
2022-10-26 21:25     ` [Intel-gfx] " Mateusz Kwiatkowski
2022-10-26 21:25     ` Mateusz Kwiatkowski
2022-10-26 21:25     ` [Nouveau] " Mateusz Kwiatkowski
2022-11-05 17:50   ` Noralf Trønnes
2022-11-05 17:50     ` Noralf Trønnes
2022-11-05 17:50     ` [Intel-gfx] " Noralf Trønnes
2022-11-05 17:50     ` Noralf Trønnes
2022-11-05 17:50     ` [Nouveau] " Noralf Trønnes
2022-11-07 13:34     ` Maxime Ripard
2022-11-07 13:34       ` Maxime Ripard
2022-11-07 13:34       ` [Intel-gfx] " Maxime Ripard
2022-11-07 13:34       ` Maxime Ripard
2022-11-07 13:34       ` [Nouveau] " Maxime Ripard
2022-10-26 15:33 ` [PATCH v6 15/23] drm/modes: Introduce more named modes maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 22:02   ` Mateusz Kwiatkowski [this message]
2022-10-26 22:02     ` Mateusz Kwiatkowski
2022-10-26 22:02     ` [Intel-gfx] " Mateusz Kwiatkowski
2022-10-26 22:02     ` Mateusz Kwiatkowski
2022-10-26 22:02     ` [Nouveau] " Mateusz Kwiatkowski
2022-10-27  9:37     ` Maxime Ripard
2022-10-27  9:37       ` Maxime Ripard
2022-10-27  9:37       ` [Intel-gfx] " Maxime Ripard
2022-10-27  9:37       ` Maxime Ripard
2022-10-27  9:37       ` [Nouveau] " Maxime Ripard
2022-11-06 16:59     ` Noralf Trønnes
2022-11-06 16:59       ` Noralf Trønnes
2022-11-06 16:59       ` [Intel-gfx] " Noralf Trønnes
2022-11-06 16:59       ` Noralf Trønnes
2022-11-06 16:59       ` [Nouveau] " Noralf Trønnes
2022-11-07 10:07       ` Maxime Ripard
2022-11-07 10:07         ` Maxime Ripard
2022-11-07 10:07         ` [Intel-gfx] " Maxime Ripard
2022-11-07 10:07         ` Maxime Ripard
2022-11-07 10:07         ` [Nouveau] " Maxime Ripard
2022-11-07 11:17         ` Noralf Trønnes
2022-11-07 11:17           ` Noralf Trønnes
2022-11-07 11:17           ` [Intel-gfx] " Noralf Trønnes
2022-11-07 11:17           ` Noralf Trønnes
2022-11-07 11:17           ` [Nouveau] " Noralf Trønnes
2022-11-06 16:33   ` Noralf Trønnes
2022-11-06 16:33     ` Noralf Trønnes
2022-11-06 16:33     ` [Intel-gfx] " Noralf Trønnes
2022-11-06 16:33     ` Noralf Trønnes
2022-11-06 16:33     ` [Nouveau] " Noralf Trønnes
2022-11-07 10:21     ` Maxime Ripard
2022-11-07 10:21       ` Maxime Ripard
2022-11-07 10:21       ` [Intel-gfx] " Maxime Ripard
2022-11-07 10:21       ` Maxime Ripard
2022-11-07 10:21       ` [Nouveau] " Maxime Ripard
2022-11-07 11:29       ` Noralf Trønnes
2022-11-07 11:29         ` Noralf Trønnes
2022-11-07 11:29         ` [Intel-gfx] " Noralf Trønnes
2022-11-07 11:29         ` Noralf Trønnes
2022-11-07 11:29         ` [Nouveau] " Noralf Trønnes
2022-11-07 12:45         ` Maxime Ripard
2022-11-07 12:45           ` Maxime Ripard
2022-11-07 12:45           ` [Intel-gfx] " Maxime Ripard
2022-11-07 12:45           ` Maxime Ripard
2022-11-07 12:45           ` [Nouveau] " Maxime Ripard
2022-10-26 15:33 ` [PATCH v6 17/23] drm/atomic-helper: Add a TV properties reset helper maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 18/23] drm/atomic-helper: Add an analog TV atomic_check implementation maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33 ` [PATCH v6 19/23] drm/vc4: vec: Use TV Reset implementation maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33 ` [PATCH v6 20/23] drm/vc4: vec: Check for VEC output constraints maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 21/23] drm/vc4: vec: Convert to the new TV mode property maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 15:33 ` [PATCH v6 22/23] drm/vc4: vec: Add support for more analog TV standards maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 22:32   ` Mateusz Kwiatkowski
2022-10-26 22:32     ` Mateusz Kwiatkowski
2022-10-26 22:32     ` [Intel-gfx] " Mateusz Kwiatkowski
2022-10-26 22:32     ` Mateusz Kwiatkowski
2022-10-26 22:32     ` [Nouveau] " Mateusz Kwiatkowski
2022-10-27 11:58     ` Maxime Ripard
2022-10-27 11:58       ` [Intel-gfx] " Maxime Ripard
2022-10-27 11:58       ` Maxime Ripard
2022-10-27 11:58       ` Maxime Ripard
2022-10-27 11:58       ` [Nouveau] " Maxime Ripard
2022-10-26 15:33 ` [PATCH v6 23/23] drm/sun4i: tv: Convert to the new TV mode property maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Intel-gfx] " maxime
2022-10-26 15:33   ` maxime
2022-10-26 15:33   ` [Nouveau] " maxime
2022-10-26 17:01 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: Analog TV Improvements (rev6) Patchwork

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=8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com \
    --to=kfyatek@gmail.com \
    --cc=airlied@linux.ie \
    --cc=bskeggs@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=dom@raspberrypi.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=geert@linux-m68k.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kherbst@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime@cerno.tech \
    --cc=mripard@kernel.org \
    --cc=noralf@tronnes.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=phil@raspberrypi.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=samuel@sholland.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=tzimmermann@suse.de \
    --cc=wens@csie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.