All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Mateusz Kwiatkowski <kfyatek@gmail.com>
Cc: "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>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Lyude Paul" <lyude@redhat.com>,
	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 11:37:30 +0200	[thread overview]
Message-ID: <20221027093730.tb4oaissdapf6ifr@houat> (raw)
In-Reply-To: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

Hi Mateusz,

On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!

Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.

> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,

If reported as supported by the connector, yes.

> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?

Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.

But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.

So it might be that I'm too careful, but it still seems useful to me.

> 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 :(

Yeah, that was my conclusion too :/

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

Thanks for the review, I'll fix these bugs

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

Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

Hi Mateusz,

On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!

Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.

> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,

If reported as supported by the connector, yes.

> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?

Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.

But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.

So it might be that I'm too careful, but it still seems useful to me.

> 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 :(

Yeah, that was my conclusion too :/

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

Thanks for the review, I'll fix these bugs

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

Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

Hi Mateusz,

On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!

Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.

> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,

If reported as supported by the connector, yes.

> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?

Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.

But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.

So it might be that I'm too careful, but it still seems useful to me.

> 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 :(

Yeah, that was my conclusion too :/

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

Thanks for the review, I'll fix these bugs

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

Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

Hi Mateusz,

On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!

Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.

> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,

If reported as supported by the connector, yes.

> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?

Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.

But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.

So it might be that I'm too careful, but it still seems useful to me.

> 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 :(

Yeah, that was my conclusion too :/

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

Thanks for the review, I'll fix these bugs

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

Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Mateusz Kwiatkowski <kfyatek@gmail.com>
Cc: "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>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Lyude Paul" <lyude@redhat.com>,
	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 11:37:30 +0200	[thread overview]
Message-ID: <20221027093730.tb4oaissdapf6ifr@houat> (raw)
In-Reply-To: <8d0eee22-50f5-5b0a-c1e6-c5f61dd5bbcd@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2797 bytes --]

Hi Mateusz,

On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!

Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.

> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,

If reported as supported by the connector, yes.

> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?

Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.

But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.

So it might be that I'm too careful, but it still seems useful to me.

> 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 :(

Yeah, that was my conclusion too :/

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

Thanks for the review, I'll fix these bugs

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

Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
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-27  9:37 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
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 [this message]
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=20221027093730.tb4oaissdapf6ifr@houat \
    --to=maxime@cerno.tech \
    --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=kfyatek@gmail.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=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.