[PATCH v1 00/35] drm: Analog TV Improvements

[PATCH v1 00/35] drm: Analog TV Improvements

[Maxime Ripard]

Hi,

Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.

The named modes support were initially introduced to allow to specify the
analog TV mode to be used.

However, this was causing multiple issues:

  * The mode name parsed on the command line was passed directly to the
    driver, which had to figure out which mode it was suppose to match;

  * Figuring that out wasn't really easy, since the video= argument or what
    the userspace might not even have a name in the first place, but
    instead could have passed a mode with the same timings;

  * The fallback to matching on the timings was mostly working as long as
    we were supporting one 525 lines (most likely NSTC) and one 625 lines
    (PAL), but couldn't differentiate between two modes with the same
    timings (NTSC vs PAL-M vs NSTC-J for example); 

  * There was also some overlap with the tv mode property registered by 
    drm_mode_create_tv_properties(), but named modes weren't interacting
    with that property at all.

  * Even though that property was generic, its possible values were
    specific to each drivers, which made some generic support difficult.

Thus, I chose to tackle in multiple steps:

  * A new TV norm property was introduced, with generic values, each driver
    reporting through a bitmask what standard it supports to the userspace;

  * This option was added to the command line parsing code to be able to
    specify it on the kernel command line, and new atomic_check and reset
    helpers were created to integrate properly into atomic KMS;

  * The named mode parsing code is now creating a proper display mode for
    the given named mode, and the TV standard will thus be part of the
    connector state;

  * Two drivers were converted and tested for now (vc4 and sun4i), with
    some backward compatibility code to translate the old TV mode to the
    new TV mode;

Unit tests were created along the way. Nouveau, ch7006 and gud are
currently broken for now since I expect that work to be reworked fairly
significantly. I'm also not entirely sure about how to migrate GUD to the
new property.

Let me know what you think,
Maxime

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Dom Cobley <dom@raspberrypi.com>
Cc: Phil Elwell <phil@raspberrypi.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: <dri-devel@lists.freedesktop.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

---
Mateusz Kwiatkowski (5):
      drm/vc4: vec: Refactor VEC TV mode setting
      drm/vc4: vec: Remove redundant atomic_mode_set
      drm/vc4: vec: Fix timings for VEC modes
      drm/vc4: vec: Fix definition of PAL-M mode
      drm/vc4: vec: Add support for more analog TV standards

Maxime Ripard (30):
      drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity
      drm/connector: Rename subconnector state variable
      drm/atomic: Add TV subconnector property to get/set_property
      drm/modes: Introduce 480i and 576i modes
      drm/connector: Add TV standard property
      drm/connector: Only register TV mode property if present
      drm/modes: Only consider bpp and refresh before options
      drm/client: Add some tests for drm_connector_pick_cmdline_mode()
      drm/modes: Move named modes parsing to a separate function
      drm/modes: Switch to named mode descriptors
      drm/modes: Fill drm_cmdline mode from named modes
      drmi/modes: Properly generate a drm_display_mode from a named mode
      drm/atomic-helper: Add a TV properties reset helper
      drm/atomic-helper: Add an analog TV atomic_check implementation
      drm/vc4: vec: Remove empty mode_fixup
      drm/vc4: vec: Convert to atomic helpers
      drm/vc4: vec: Switch for common modes
      drm/vc4: vec: Use TV Reset implementation
      drm/vc4: vec: Convert to the new TV mode property
      drm/sun4i: tv: Remove unused mode_valid
      drm/sun4i: tv: Convert to atomic hooks
      drm/sun4i: tv: Merge mode_set into atomic_enable
      drm/sun4i: tv: Remove useless function
      drm/sun4i: tv: Remove useless destroy function
      drm/sun4i: tv: Rename error label
      drm/sun4i: tv: Add missing reset assertion
      drm/sun4i: tv: Convert to the new TV mode property
      drm/connector: Remove TV modes property
      drm/modes: Introduce the tv_mode property as a command-line option
      drm/modes: Introduce more named modes

 drivers/gpu/drm/drm_atomic_state_helper.c       | 166 +++++++++-
 drivers/gpu/drm/drm_atomic_uapi.c               |  12 +-
 drivers/gpu/drm/drm_client_modeset.c            |   4 +
 drivers/gpu/drm/drm_connector.c                 |  46 ++-
 drivers/gpu/drm/drm_modes.c                     | 198 +++++++++--
 drivers/gpu/drm/gud/gud_connector.c             |   2 +-
 drivers/gpu/drm/meson/meson_encoder_cvbs.c      |  18 +-
 drivers/gpu/drm/meson/meson_encoder_cvbs.h      |   2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c                | 173 +++-------
 drivers/gpu/drm/tests/drm_cmdline_parser_test.c | 295 +++++++++++++++++
 drivers/gpu/drm/tests/drm_mode_test.c           | 255 +++++++++++++++
 drivers/gpu/drm/vc4/vc4_hdmi.c                  |   2 +-
 drivers/gpu/drm/vc4/vc4_vec.c                   | 418 ++++++++++++++++--------
 include/drm/drm_atomic_state_helper.h           |   4 +
 include/drm/drm_connector.h                     |  40 ++-
 include/drm/drm_mode_config.h                   |   6 +
 include/drm/drm_modes.h                         |   3 +
 17 files changed, 1314 insertions(+), 330 deletions(-)
---
base-commit: 37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9
change-id: 20220728-rpi-analog-tv-properties-0914dfcee460

Best regards,
-- 
Maxime Ripard <maxime@cerno.tech>

[PATCH v1 01/35] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

[Maxime Ripard]

We currently have two sets of TV properties.

The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.

The second one is there to deal with properties that might be useful on a
TV, creating the overscan margins for example. It's created by calling the
drm_mode_create_tv_margin_properties().

However, we also have a drm_atomic_helper_connector_tv_reset() function
that will reset the TV margin properties to their default values, and thus
is supposed to be called for the latter set. This creates an ambiguity due
to the inconsistent naming.

We can thus rename the drm_atomic_helper_connector_tv_reset() function to
drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity
and hopefully make it more obvious.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index bf31b9d92094..dfb57217253b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -464,12 +464,12 @@ void drm_atomic_helper_connector_reset(struct drm_connector *connector)
 EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
 
 /**
- * drm_atomic_helper_connector_tv_reset - Resets TV connector properties
+ * drm_atomic_helper_connector_tv_margins_reset - Resets TV connector properties
  * @connector: DRM connector
  *
  * Resets the TV-related properties attached to a connector.
  */
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector)
 {
 	struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
 	struct drm_connector_state *state = connector->state;
@@ -479,7 +479,7 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
 	state->tv.margins.top = cmdline->tv_margins.top;
 	state->tv.margins.bottom = cmdline->tv_margins.bottom;
 }
-EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
diff --git a/drivers/gpu/drm/gud/gud_connector.c b/drivers/gpu/drm/gud/gud_connector.c
index d0addd478815..fa636206f232 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -355,7 +355,7 @@ static void gud_connector_reset(struct drm_connector *connector)
 	drm_atomic_helper_connector_reset(connector);
 	connector->state->tv = gconn->initial_tv_state;
 	/* Set margins from command line */
-	drm_atomic_helper_connector_tv_reset(connector);
+	drm_atomic_helper_connector_tv_margins_reset(connector);
 	if (gconn->initial_brightness >= 0)
 		connector->state->tv.brightness = gconn->initial_brightness;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 719a3c3b4ef6..66e38760d5aa 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -397,7 +397,7 @@ static void vc4_hdmi_connector_reset(struct drm_connector *connector)
 	new_state->base.max_bpc = 8;
 	new_state->base.max_requested_bpc = 8;
 	new_state->output_format = VC4_HDMI_OUTPUT_RGB;
-	drm_atomic_helper_connector_tv_reset(connector);
+	drm_atomic_helper_connector_tv_margins_reset(connector);
 }
 
 static struct drm_connector_state *
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 3f8f1d627f7c..192766656b88 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,7 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 					 struct drm_connector_state *conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
 					   struct drm_connector_state *state);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 2c6fa746efac..f185ad862cb1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -671,7 +671,7 @@ struct drm_connector_tv_margins {
 
 /**
  * struct drm_tv_connector_state - TV connector related states
- * @subconnector: selected subconnector
+ * @select_subconnector: selected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 01/35] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> We currently have two sets of TV properties.
> 
> The first one is there to deal with analog TV properties, creating
> properties such as the TV mode, subconnectors, saturation, hue and so on.
> It's created by calling the drm_mode_create_tv_properties() function.
> 
> The second one is there to deal with properties that might be useful on a
> TV, creating the overscan margins for example. It's created by calling the
> drm_mode_create_tv_margin_properties().
> 
> However, we also have a drm_atomic_helper_connector_tv_reset() function
> that will reset the TV margin properties to their default values, and thus
> is supposed to be called for the latter set. This creates an ambiguity due
> to the inconsistent naming.
> 
> We can thus rename the drm_atomic_helper_connector_tv_reset() function to
> drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity
> and hopefully make it more obvious.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>

[PATCH v1 02/35] drm/connector: Rename subconnector state variable

[Maxime Ripard]

There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.

While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.

Worse, the select subconnector property is stored in a field called
subconnector, creating some ambiguity about which property content we're
accessing.

Let's rename that field to one called select_subconnector to make it move
obvious what it's about.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..c74c78a28171 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -687,7 +687,7 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		 */
 		return -EINVAL;
 	} else if (property == config->tv_select_subconnector_property) {
-		state->tv.subconnector = val;
+		state->tv.select_subconnector = val;
 	} else if (property == config->tv_left_margin_property) {
 		state->tv.margins.left = val;
 	} else if (property == config->tv_right_margin_property) {
@@ -795,7 +795,7 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		else
 			*val = connector->dpms;
 	} else if (property == config->tv_select_subconnector_property) {
-		*val = state->tv.subconnector;
+		*val = state->tv.select_subconnector;
 	} else if (property == config->tv_left_margin_property) {
 		*val = state->tv.margins.left;
 	} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f185ad862cb1..f8091edf9a33 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -682,7 +682,7 @@ struct drm_connector_tv_margins {
  * @hue: hue in percent
  */
 struct drm_tv_connector_state {
-	enum drm_mode_subconnector subconnector;
+	enum drm_mode_subconnector select_subconnector;
 	struct drm_connector_tv_margins margins;
 	unsigned int mode;
 	unsigned int brightness;

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 02/35] drm/connector: Rename subconnector state variable

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> There is two TV subconnector related properties registered by
> drm_mode_create_tv_properties(): subconnector and select subconnector.
> 
> While the select subconnector property is stored in the kernel by the
> drm_tv_connector_state structure, the subconnector property isn't stored
> anywhere.
> 
> Worse, the select subconnector property is stored in a field called
> subconnector, creating some ambiguity about which property content we're
> accessing.
> 
> Let's rename that field to one called select_subconnector to make it move
> obvious what it's about.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>

[PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property

[Maxime Ripard]

The subconnector property was created by drm_mode_create_tv_properties(),
but wasn't exposed to the userspace through the generic
atomic_get/set_property implementation, and wasn't stored in any generic
state structure.

Let's solve this.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index c74c78a28171..c06d0639d552 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -688,6 +688,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		return -EINVAL;
 	} else if (property == config->tv_select_subconnector_property) {
 		state->tv.select_subconnector = val;
+	} else if (property == config->tv_subconnector_property) {
+		state->tv.subconnector = val;
 	} else if (property == config->tv_left_margin_property) {
 		state->tv.margins.left = val;
 	} else if (property == config->tv_right_margin_property) {
@@ -796,6 +798,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 			*val = connector->dpms;
 	} else if (property == config->tv_select_subconnector_property) {
 		*val = state->tv.select_subconnector;
+	} else if (property == config->tv_subconnector_property) {
+		*val = state->tv.subconnector;
 	} else if (property == config->tv_left_margin_property) {
 		*val = state->tv.margins.left;
 	} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f8091edf9a33..1e9996b33cc8 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -672,6 +672,7 @@ struct drm_connector_tv_margins {
 /**
  * struct drm_tv_connector_state - TV connector related states
  * @select_subconnector: selected subconnector
+ * @subconnector: detected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent
@@ -683,6 +684,7 @@ struct drm_connector_tv_margins {
  */
 struct drm_tv_connector_state {
 	enum drm_mode_subconnector select_subconnector;
+	enum drm_mode_subconnector subconnector;
 	struct drm_connector_tv_margins margins;
 	unsigned int mode;
 	unsigned int brightness;

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> The subconnector property was created by drm_mode_create_tv_properties(),
> but wasn't exposed to the userspace through the generic
> atomic_get/set_property implementation, and wasn't stored in any generic
> state structure.
> 
> Let's solve this.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

I just realised that this and the select_subconnector property isn't
used by any drivers. Do you plan to use them? Maybe they don't need to
be wired up at all.

Anyways, up to you:

Reviewed-by: Noralf Trønnes <noralf@tronnes.org>

> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index c74c78a28171..c06d0639d552 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -688,6 +688,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>  		return -EINVAL;
>  	} else if (property == config->tv_select_subconnector_property) {
>  		state->tv.select_subconnector = val;
> +	} else if (property == config->tv_subconnector_property) {
> +		state->tv.subconnector = val;
>  	} else if (property == config->tv_left_margin_property) {
>  		state->tv.margins.left = val;
>  	} else if (property == config->tv_right_margin_property) {
> @@ -796,6 +798,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>  			*val = connector->dpms;
>  	} else if (property == config->tv_select_subconnector_property) {
>  		*val = state->tv.select_subconnector;
> +	} else if (property == config->tv_subconnector_property) {
> +		*val = state->tv.subconnector;
>  	} else if (property == config->tv_left_margin_property) {
>  		*val = state->tv.margins.left;
>  	} else if (property == config->tv_right_margin_property) {
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f8091edf9a33..1e9996b33cc8 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -672,6 +672,7 @@ struct drm_connector_tv_margins {
>  /**
>   * struct drm_tv_connector_state - TV connector related states
>   * @select_subconnector: selected subconnector
> + * @subconnector: detected subconnector
>   * @margins: TV margins
>   * @mode: TV mode
>   * @brightness: brightness in percent
> @@ -683,6 +684,7 @@ struct drm_connector_tv_margins {
>   */
>  struct drm_tv_connector_state {
>  	enum drm_mode_subconnector select_subconnector;
> +	enum drm_mode_subconnector subconnector;
>  	struct drm_connector_tv_margins margins;
>  	unsigned int mode;
>  	unsigned int brightness;
> 

Re: [PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property

[Maxime Ripard]

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

Hi Noralf,

Thanks for your review

On Mon, Aug 08, 2022 at 02:30:42PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.34, skrev Maxime Ripard:
> > The subconnector property was created by drm_mode_create_tv_properties(),
> > but wasn't exposed to the userspace through the generic
> > atomic_get/set_property implementation, and wasn't stored in any generic
> > state structure.
> > 
> > Let's solve this.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> I just realised that this and the select_subconnector property isn't
> used by any drivers. Do you plan to use them? Maybe they don't need to
> be wired up at all.

I'm not sure really

It's true that the subconnector and select_subconnector fields in the TV
connector state aren't used by any driver, but the ch7006 and nouveau
will update the property content through a call to
drm_object_property_set_value

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i2c/ch7006_drv.c#L217
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#L185

I think it could still be useful to report it in the connector state, if
only for consistency?

Maxime

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

Re: [PATCH v1 03/35] drm/atomic: Add TV subconnector property to get/set_property

[Noralf Trønnes]

Den 15.08.2022 09.35, skrev Maxime Ripard:
> Hi Noralf,
> 
> Thanks for your review
> 
> On Mon, Aug 08, 2022 at 02:30:42PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> The subconnector property was created by drm_mode_create_tv_properties(),
>>> but wasn't exposed to the userspace through the generic
>>> atomic_get/set_property implementation, and wasn't stored in any generic
>>> state structure.
>>>
>>> Let's solve this.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>
>> I just realised that this and the select_subconnector property isn't
>> used by any drivers. Do you plan to use them? Maybe they don't need to
>> be wired up at all.
> 
> I'm not sure really
> 
> It's true that the subconnector and select_subconnector fields in the TV
> connector state aren't used by any driver, but the ch7006 and nouveau
> will update the property content through a call to
> drm_object_property_set_value
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i2c/ch7006_drv.c#L217
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#L185
> 
> I think it could still be useful to report it in the connector state, if
> only for consistency?
> 

Yeah maybe.

I just realised that I have support in the GUD protocol for these
properties so any future devices that rely on them them will need this
patch, so I'm now suddenly in favor of this :)

Noralf.

[PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
modes in the drivers.

Since those modes are fairly standards, and that we'll need to use them in
more places in the future, let's move the meson definition into the
framework.

The meson one was chosen because vc4's isn't accurate and doesn't amount to
525 and 625 lines.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..a4c1bd688338 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -48,6 +48,24 @@
 
 #include "drm_crtc_internal.h"
 
+const struct drm_display_mode drm_mode_480i = {
+	DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
+		 720, 739, 801, 858, 0,
+		 480, 488, 494, 525, 0,
+		 DRM_MODE_FLAG_INTERLACE),
+	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
+};
+EXPORT_SYMBOL_GPL(drm_mode_480i);
+
+const struct drm_display_mode drm_mode_576i = {
+	DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
+		 720, 732, 795, 864, 0,
+		 576, 580, 586, 625, 0,
+		 DRM_MODE_FLAG_INTERLACE),
+	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
+};
+EXPORT_SYMBOL_GPL(drm_mode_576i);
+
 /**
  * drm_mode_debug_printmodeline - print a mode to dmesg
  * @mode: mode to print
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
index 8110a6e39320..98ec3e563155 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
@@ -45,21 +45,11 @@ struct meson_encoder_cvbs {
 struct meson_cvbs_mode meson_cvbs_modes[MESON_CVBS_MODES_COUNT] = {
 	{ /* PAL */
 		.enci = &meson_cvbs_enci_pal,
-		.mode = {
-			DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
-				 720, 732, 795, 864, 0, 576, 580, 586, 625, 0,
-				 DRM_MODE_FLAG_INTERLACE),
-			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
-		},
+		.mode = &drm_mode_576i,
 	},
 	{ /* NTSC */
 		.enci = &meson_cvbs_enci_ntsc,
-		.mode = {
-			DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
-				720, 739, 801, 858, 0, 480, 488, 494, 525, 0,
-				DRM_MODE_FLAG_INTERLACE),
-			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
-		},
+		.mode = &drm_mode_480i,
 	},
 };
 
@@ -71,7 +61,7 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
 	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
 		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
 
-		if (drm_mode_match(req_mode, &meson_mode->mode,
+		if (drm_mode_match(req_mode, meson_mode->mode,
 				   DRM_MODE_MATCH_TIMINGS |
 				   DRM_MODE_MATCH_CLOCK |
 				   DRM_MODE_MATCH_FLAGS |
@@ -104,7 +94,7 @@ static int meson_encoder_cvbs_get_modes(struct drm_bridge *bridge,
 	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
 		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
 
-		mode = drm_mode_duplicate(priv->drm, &meson_mode->mode);
+		mode = drm_mode_duplicate(priv->drm, meson_mode->mode);
 		if (!mode) {
 			dev_err(priv->dev, "Failed to create a new display mode\n");
 			return 0;
diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.h b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
index 61d9d183ce7f..26cefb202924 100644
--- a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
+++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
@@ -16,7 +16,7 @@
 
 struct meson_cvbs_mode {
 	struct meson_cvbs_enci_mode *enci;
-	struct drm_display_mode mode;
+	const struct drm_display_mode *mode;
 };
 
 #define MESON_CVBS_MODES_COUNT	2
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index a80ae9639e96..b4a440e2688c 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -394,6 +394,9 @@ struct drm_display_mode {
 
 };
 
+extern const struct drm_display_mode drm_mode_480i;
+extern const struct drm_display_mode drm_mode_576i;
+
 /**
  * DRM_MODE_FMT - printf string for &struct drm_display_mode
  */

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Jani Nikula]

On Fri, 29 Jul 2022, Maxime Ripard <maxime@cerno.tech> wrote:
> Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> modes in the drivers.
>
> Since those modes are fairly standards, and that we'll need to use them in
> more places in the future, let's move the meson definition into the
> framework.

I think you should always expose interfaces, not data. Data is not an
interface, and I think this sets a bad example that will be cargo
culted.


BR,
Jani.

>
> The meson one was chosen because vc4's isn't accurate and doesn't amount to
> 525 and 625 lines.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 304004fb80aa..a4c1bd688338 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -48,6 +48,24 @@
>  
>  #include "drm_crtc_internal.h"
>  
> +const struct drm_display_mode drm_mode_480i = {
> +	DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
> +		 720, 739, 801, 858, 0,
> +		 480, 488, 494, 525, 0,
> +		 DRM_MODE_FLAG_INTERLACE),
> +	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_480i);
> +
> +const struct drm_display_mode drm_mode_576i = {
> +	DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
> +		 720, 732, 795, 864, 0,
> +		 576, 580, 586, 625, 0,
> +		 DRM_MODE_FLAG_INTERLACE),
> +	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_576i);
> +
>  /**
>   * drm_mode_debug_printmodeline - print a mode to dmesg
>   * @mode: mode to print
> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> index 8110a6e39320..98ec3e563155 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
> @@ -45,21 +45,11 @@ struct meson_encoder_cvbs {
>  struct meson_cvbs_mode meson_cvbs_modes[MESON_CVBS_MODES_COUNT] = {
>  	{ /* PAL */
>  		.enci = &meson_cvbs_enci_pal,
> -		.mode = {
> -			DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
> -				 720, 732, 795, 864, 0, 576, 580, 586, 625, 0,
> -				 DRM_MODE_FLAG_INTERLACE),
> -			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> -		},
> +		.mode = &drm_mode_576i,
>  	},
>  	{ /* NTSC */
>  		.enci = &meson_cvbs_enci_ntsc,
> -		.mode = {
> -			DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
> -				720, 739, 801, 858, 0, 480, 488, 494, 525, 0,
> -				DRM_MODE_FLAG_INTERLACE),
> -			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> -		},
> +		.mode = &drm_mode_480i,
>  	},
>  };
>  
> @@ -71,7 +61,7 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
>  	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
>  		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
>  
> -		if (drm_mode_match(req_mode, &meson_mode->mode,
> +		if (drm_mode_match(req_mode, meson_mode->mode,
>  				   DRM_MODE_MATCH_TIMINGS |
>  				   DRM_MODE_MATCH_CLOCK |
>  				   DRM_MODE_MATCH_FLAGS |
> @@ -104,7 +94,7 @@ static int meson_encoder_cvbs_get_modes(struct drm_bridge *bridge,
>  	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
>  		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
>  
> -		mode = drm_mode_duplicate(priv->drm, &meson_mode->mode);
> +		mode = drm_mode_duplicate(priv->drm, meson_mode->mode);
>  		if (!mode) {
>  			dev_err(priv->dev, "Failed to create a new display mode\n");
>  			return 0;
> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.h b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> index 61d9d183ce7f..26cefb202924 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
> @@ -16,7 +16,7 @@
>  
>  struct meson_cvbs_mode {
>  	struct meson_cvbs_enci_mode *enci;
> -	struct drm_display_mode mode;
> +	const struct drm_display_mode *mode;
>  };
>  
>  #define MESON_CVBS_MODES_COUNT	2
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index a80ae9639e96..b4a440e2688c 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -394,6 +394,9 @@ struct drm_display_mode {
>  
>  };
>  
> +extern const struct drm_display_mode drm_mode_480i;
> +extern const struct drm_display_mode drm_mode_576i;
> +
>  /**
>   * DRM_MODE_FMT - printf string for &struct drm_display_mode
>   */

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Thomas Zimmermann]

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

Hi

Am 02.08.22 um 15:58 schrieb Jani Nikula:
> On Fri, 29 Jul 2022, Maxime Ripard <maxime@cerno.tech> wrote:
>> Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
>> modes in the drivers.
>>
>> Since those modes are fairly standards, and that we'll need to use them in
>> more places in the future, let's move the meson definition into the
>> framework.
> 
> I think you should always expose interfaces, not data. Data is not an
> interface, and I think this sets a bad example that will be cargo
> culted.

Although I wrote the opposite wrt patch 8, I agree with Jani here when 
it comes to 'official' interfaces. The cases I've seen of exported data 
structures often lead to intransparent code.

Best regards
Thomas

> 
> 
> BR,
> Jani.
> 
>>
>> The meson one was chosen because vc4's isn't accurate and doesn't amount to
>> 525 and 625 lines.
>>
>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 304004fb80aa..a4c1bd688338 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -48,6 +48,24 @@
>>   
>>   #include "drm_crtc_internal.h"
>>   
>> +const struct drm_display_mode drm_mode_480i = {
>> +	DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
>> +		 720, 739, 801, 858, 0,
>> +		 480, 488, 494, 525, 0,
>> +		 DRM_MODE_FLAG_INTERLACE),
>> +	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
>> +};
>> +EXPORT_SYMBOL_GPL(drm_mode_480i);
>> +
>> +const struct drm_display_mode drm_mode_576i = {
>> +	DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
>> +		 720, 732, 795, 864, 0,
>> +		 576, 580, 586, 625, 0,
>> +		 DRM_MODE_FLAG_INTERLACE),
>> +	.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
>> +};
>> +EXPORT_SYMBOL_GPL(drm_mode_576i);
>> +
>>   /**
>>    * drm_mode_debug_printmodeline - print a mode to dmesg
>>    * @mode: mode to print
>> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.c b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
>> index 8110a6e39320..98ec3e563155 100644
>> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.c
>> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.c
>> @@ -45,21 +45,11 @@ struct meson_encoder_cvbs {
>>   struct meson_cvbs_mode meson_cvbs_modes[MESON_CVBS_MODES_COUNT] = {
>>   	{ /* PAL */
>>   		.enci = &meson_cvbs_enci_pal,
>> -		.mode = {
>> -			DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
>> -				 720, 732, 795, 864, 0, 576, 580, 586, 625, 0,
>> -				 DRM_MODE_FLAG_INTERLACE),
>> -			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
>> -		},
>> +		.mode = &drm_mode_576i,
>>   	},
>>   	{ /* NTSC */
>>   		.enci = &meson_cvbs_enci_ntsc,
>> -		.mode = {
>> -			DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
>> -				720, 739, 801, 858, 0, 480, 488, 494, 525, 0,
>> -				DRM_MODE_FLAG_INTERLACE),
>> -			.picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
>> -		},
>> +		.mode = &drm_mode_480i,
>>   	},
>>   };
>>   
>> @@ -71,7 +61,7 @@ meson_cvbs_get_mode(const struct drm_display_mode *req_mode)
>>   	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
>>   		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
>>   
>> -		if (drm_mode_match(req_mode, &meson_mode->mode,
>> +		if (drm_mode_match(req_mode, meson_mode->mode,
>>   				   DRM_MODE_MATCH_TIMINGS |
>>   				   DRM_MODE_MATCH_CLOCK |
>>   				   DRM_MODE_MATCH_FLAGS |
>> @@ -104,7 +94,7 @@ static int meson_encoder_cvbs_get_modes(struct drm_bridge *bridge,
>>   	for (i = 0; i < MESON_CVBS_MODES_COUNT; ++i) {
>>   		struct meson_cvbs_mode *meson_mode = &meson_cvbs_modes[i];
>>   
>> -		mode = drm_mode_duplicate(priv->drm, &meson_mode->mode);
>> +		mode = drm_mode_duplicate(priv->drm, meson_mode->mode);
>>   		if (!mode) {
>>   			dev_err(priv->dev, "Failed to create a new display mode\n");
>>   			return 0;
>> diff --git a/drivers/gpu/drm/meson/meson_encoder_cvbs.h b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
>> index 61d9d183ce7f..26cefb202924 100644
>> --- a/drivers/gpu/drm/meson/meson_encoder_cvbs.h
>> +++ b/drivers/gpu/drm/meson/meson_encoder_cvbs.h
>> @@ -16,7 +16,7 @@
>>   
>>   struct meson_cvbs_mode {
>>   	struct meson_cvbs_enci_mode *enci;
>> -	struct drm_display_mode mode;
>> +	const struct drm_display_mode *mode;
>>   };
>>   
>>   #define MESON_CVBS_MODES_COUNT	2
>> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
>> index a80ae9639e96..b4a440e2688c 100644
>> --- a/include/drm/drm_modes.h
>> +++ b/include/drm/drm_modes.h
>> @@ -394,6 +394,9 @@ struct drm_display_mode {
>>   
>>   };
>>   
>> +extern const struct drm_display_mode drm_mode_480i;
>> +extern const struct drm_display_mode drm_mode_576i;
>> +
>>   /**
>>    * DRM_MODE_FMT - printf string for &struct drm_display_mode
>>    */
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Tue, Aug 02, 2022 at 04:16:29PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 02.08.22 um 15:58 schrieb Jani Nikula:
> > On Fri, 29 Jul 2022, Maxime Ripard <maxime@cerno.tech> wrote:
> > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > modes in the drivers.
> > > 
> > > Since those modes are fairly standards, and that we'll need to use them in
> > > more places in the future, let's move the meson definition into the
> > > framework.
> > 
> > I think you should always expose interfaces, not data. Data is not an
> > interface, and I think this sets a bad example that will be cargo
> > culted.
> 
> Although I wrote the opposite wrt patch 8, I agree with Jani here when it
> comes to 'official' interfaces. The cases I've seen of exported data
> structures often lead to intransparent code.

Ack. The improvement Geert suggested would involve that change anyway,
so this should be fixed for the next iteration.

Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

Thanks for your patch!

On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> modes in the drivers.

Nit: strictly speaking these are not analog modes, but the digital
variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
13.5 MHz sampling frequency for pixels.

In analog modes, the only discrete values are the number of lines, and
the frame/field rate (fixing the horizontal sync rate when combined).

The number of (in)visible pixels per line depends on the available
bandwidth.  In a digital variant (which is anything generated by a
digital computer system), the latter depends on the pixel clock, which
can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).

So I think we probably need some way to generate a PAL/NTSC-compatible
mode based not only on resolution, but also on pixel clock.

>
> Since those modes are fairly standards, and that we'll need to use them in
> more places in the future, let's move the meson definition into the
> framework.
>
> The meson one was chosen because vc4's isn't accurate and doesn't amount to
> 525 and 625 lines.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -48,6 +48,24 @@
>
>  #include "drm_crtc_internal.h"
>
> +const struct drm_display_mode drm_mode_480i = {
> +       DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500,
> +                720, 739, 801, 858, 0,
> +                480, 488, 494, 525, 0,
> +                DRM_MODE_FLAG_INTERLACE),
> +       .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_480i);
> +
> +const struct drm_display_mode drm_mode_576i = {
> +       DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500,
> +                720, 732, 795, 864, 0,
> +                576, 580, 586, 625, 0,
> +                DRM_MODE_FLAG_INTERLACE),
> +       .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3,
> +};
> +EXPORT_SYMBOL_GPL(drm_mode_576i);
> +
>  /**

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

Hi Geert,

On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> Thanks for your patch!
> 
> On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > modes in the drivers.
> 
> Nit: strictly speaking these are not analog modes, but the digital
> variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> 13.5 MHz sampling frequency for pixels.
> 
> In analog modes, the only discrete values are the number of lines, and
> the frame/field rate (fixing the horizontal sync rate when combined).
> 
> The number of (in)visible pixels per line depends on the available
> bandwidth.  In a digital variant (which is anything generated by a
> digital computer system), the latter depends on the pixel clock, which
> can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> 
> So I think we probably need some way to generate a PAL/NTSC-compatible
> mode based not only on resolution, but also on pixel clock.

This would also fix the comments made by Jani and Thomas, so I quite
like the idea of it.

I'm struggling a bit to find how would could implement this though.

From what you were saying, I guess the prototype would be something like

struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
       						unsigned int lines,
						unsigned int frame_rate)

But I have zero idea on what the implementation would be. Do you have
some resources for this you could point me to?

Thanks
Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > modes in the drivers.
> >
> > Nit: strictly speaking these are not analog modes, but the digital
> > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > 13.5 MHz sampling frequency for pixels.
> >
> > In analog modes, the only discrete values are the number of lines, and
> > the frame/field rate (fixing the horizontal sync rate when combined).
> >
> > The number of (in)visible pixels per line depends on the available
> > bandwidth.  In a digital variant (which is anything generated by a
> > digital computer system), the latter depends on the pixel clock, which
> > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> >
> > So I think we probably need some way to generate a PAL/NTSC-compatible
> > mode based not only on resolution, but also on pixel clock.
>
> This would also fix the comments made by Jani and Thomas, so I quite
> like the idea of it.
>
> I'm struggling a bit to find how would could implement this though.
>
> From what you were saying, I guess the prototype would be something like
>
> struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
>                                                 unsigned int lines,
>                                                 unsigned int frame_rate)
>
> But I have zero idea on what the implementation would be. Do you have
> some resources for this you could point me to?

Horizontally, I think you should calculate left/right margins and
hsync length to yield timings that match those for the BT.656 PAL/NTSC
modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
requested, you want to calculate left', right', and hslen' for

| <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
                        @ 14 MHz

so they match the timings for left, right, and hslen for

| <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
                        @ 13.5 MHz

As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
you want to make sure to align the center of the visible part.

Vertically, it's simpler, as the number of lines is discrete.
You do have to take into account interlace and doublescan, and
progressive modes with 262/312 lines.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > > modes in the drivers.
> > >
> > > Nit: strictly speaking these are not analog modes, but the digital
> > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > > 13.5 MHz sampling frequency for pixels.
> > >
> > > In analog modes, the only discrete values are the number of lines, and
> > > the frame/field rate (fixing the horizontal sync rate when combined).
> > >
> > > The number of (in)visible pixels per line depends on the available
> > > bandwidth.  In a digital variant (which is anything generated by a
> > > digital computer system), the latter depends on the pixel clock, which
> > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> > >
> > > So I think we probably need some way to generate a PAL/NTSC-compatible
> > > mode based not only on resolution, but also on pixel clock.
> >
> > This would also fix the comments made by Jani and Thomas, so I quite
> > like the idea of it.
> >
> > I'm struggling a bit to find how would could implement this though.
> >
> > From what you were saying, I guess the prototype would be something like
> >
> > struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
> >                                                 unsigned int lines,
> >                                                 unsigned int frame_rate)
> >
> > But I have zero idea on what the implementation would be. Do you have
> > some resources for this you could point me to?
> 
> Horizontally, I think you should calculate left/right margins and
> hsync length to yield timings that match those for the BT.656 PAL/NTSC
> modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
> requested, you want to calculate left', right', and hslen' for
> 
> | <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
>                         @ 14 MHz
> 
> so they match the timings for left, right, and hslen for
> 
> | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
>                         @ 13.5 MHz
> 
> As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
> you want to make sure to align the center of the visible part.

So I guess in that example if we want to center it, left == right and
left' == right'? What about the sync length?

> Vertically, it's simpler, as the number of lines is discrete.
> You do have to take into account interlace and doublescan, and
> progressive modes with 262/312 lines.

So we only have to deal with 525 and 625 lines total (without taking
interlace and doublescan into account), right?

I guess we still have the same question, we probably want to center it,
so top == bottom, but what about the vsync length?

Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard <maxime@cerno.tech> wrote:
> On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > > > modes in the drivers.
> > > >
> > > > Nit: strictly speaking these are not analog modes, but the digital
> > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > > > 13.5 MHz sampling frequency for pixels.
> > > >
> > > > In analog modes, the only discrete values are the number of lines, and
> > > > the frame/field rate (fixing the horizontal sync rate when combined).
> > > >
> > > > The number of (in)visible pixels per line depends on the available
> > > > bandwidth.  In a digital variant (which is anything generated by a
> > > > digital computer system), the latter depends on the pixel clock, which
> > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> > > >
> > > > So I think we probably need some way to generate a PAL/NTSC-compatible
> > > > mode based not only on resolution, but also on pixel clock.
> > >
> > > This would also fix the comments made by Jani and Thomas, so I quite
> > > like the idea of it.
> > >
> > > I'm struggling a bit to find how would could implement this though.
> > >
> > > From what you were saying, I guess the prototype would be something like
> > >
> > > struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
> > >                                                 unsigned int lines,
> > >                                                 unsigned int frame_rate)
> > >
> > > But I have zero idea on what the implementation would be. Do you have
> > > some resources for this you could point me to?
> >
> > Horizontally, I think you should calculate left/right margins and
> > hsync length to yield timings that match those for the BT.656 PAL/NTSC
> > modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
> > requested, you want to calculate left', right', and hslen' for
> >
> > | <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
> >                         @ 14 MHz
> >
> > so they match the timings for left, right, and hslen for
> >
> > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
> >                         @ 13.5 MHz
> >
> > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
> > you want to make sure to align the center of the visible part.
>
> So I guess in that example if we want to center it, left == right and
> left' == right'? What about the sync length?

No, left and right are asymmetrical, cfr. front and back porch in
https://en.wikipedia.org/wiki/PAL#PAL_signal_details
I.e. if the pixel part is reduced, both the left and right margins
should be increased by the same amount.

From the table linked above, hslen should be ca. 4.7µs (fixed).

> > Vertically, it's simpler, as the number of lines is discrete.
> > You do have to take into account interlace and doublescan, and
> > progressive modes with 262/312 lines.
>
> So we only have to deal with 525 and 625 lines total (without taking
> interlace and doublescan into account), right?

Yes.

> I guess we still have the same question, we probably want to center it,
> so top == bottom, but what about the vsync length?

Unfortunately that table does not mention top and bottom margins.
But according to drivers/video/fbdev/amifb.c (see the "Broadcast
video timings" comment block and the definitions of the "ntsc-lace"
and "pal-lace" video modes), they are asymmetrical, too.

Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't
have that info when I wrote amifb, as I used 4 lines there).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote:
> On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > > > > modes in the drivers.
> > > > >
> > > > > Nit: strictly speaking these are not analog modes, but the digital
> > > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > > > > 13.5 MHz sampling frequency for pixels.
> > > > >
> > > > > In analog modes, the only discrete values are the number of lines, and
> > > > > the frame/field rate (fixing the horizontal sync rate when combined).
> > > > >
> > > > > The number of (in)visible pixels per line depends on the available
> > > > > bandwidth.  In a digital variant (which is anything generated by a
> > > > > digital computer system), the latter depends on the pixel clock, which
> > > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> > > > >
> > > > > So I think we probably need some way to generate a PAL/NTSC-compatible
> > > > > mode based not only on resolution, but also on pixel clock.
> > > >
> > > > This would also fix the comments made by Jani and Thomas, so I quite
> > > > like the idea of it.
> > > >
> > > > I'm struggling a bit to find how would could implement this though.
> > > >
> > > > From what you were saying, I guess the prototype would be something like
> > > >
> > > > struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
> > > >                                                 unsigned int lines,
> > > >                                                 unsigned int frame_rate)
> > > >
> > > > But I have zero idea on what the implementation would be. Do you have
> > > > some resources for this you could point me to?
> > >
> > > Horizontally, I think you should calculate left/right margins and
> > > hsync length to yield timings that match those for the BT.656 PAL/NTSC
> > > modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
> > > requested, you want to calculate left', right', and hslen' for
> > >
> > > | <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
> > >                         @ 14 MHz
> > >
> > > so they match the timings for left, right, and hslen for
> > >
> > > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
> > >                         @ 13.5 MHz
> > >
> > > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
> > > you want to make sure to align the center of the visible part.
> >
> > So I guess in that example if we want to center it, left == right and
> > left' == right'? What about the sync length?
> 
> No, left and right are asymmetrical, cfr. front and back porch in
> https://en.wikipedia.org/wiki/PAL#PAL_signal_details
> I.e. if the pixel part is reduced, both the left and right margins
> should be increased by the same amount.
> 
> From the table linked above, hslen should be ca. 4.7µs (fixed).

each pixel taking 1 / pixel_clock seconds (assuming pixel_clock is in
Hz), and thus hslen (in pixels) = 4.7 * 10 ^ -6 * pixel_clk, right?

> > > Vertically, it's simpler, as the number of lines is discrete.
> > > You do have to take into account interlace and doublescan, and
> > > progressive modes with 262/312 lines.
> >
> > So we only have to deal with 525 and 625 lines total (without taking
> > interlace and doublescan into account), right?
> 
> Yes.
> 
> > I guess we still have the same question, we probably want to center it,
> > so top == bottom, but what about the vsync length?
> 
> Unfortunately that table does not mention top and bottom margins.
> But according to drivers/video/fbdev/amifb.c (see the "Broadcast
> video timings" comment block and the definitions of the "ntsc-lace"
> and "pal-lace" video modes), they are asymmetrical, too.
> 
> Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't
> have that info when I wrote amifb, as I used 4 lines there).

Thanks, that's some great info already.

It's mentioned though that the settings for NTSC are "straightforward",
but it's definitely not for me :)

I've looked around and it looks like the entire blanking area is
supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
it's supposed to be split between the upper and lower margins and the
sync period.

Thanks!
Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 17, 2022 at 3:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> > > > > > > modes in the drivers.
> > > > > >
> > > > > > Nit: strictly speaking these are not analog modes, but the digital
> > > > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a
> > > > > > 13.5 MHz sampling frequency for pixels.
> > > > > >
> > > > > > In analog modes, the only discrete values are the number of lines, and
> > > > > > the frame/field rate (fixing the horizontal sync rate when combined).
> > > > > >
> > > > > > The number of (in)visible pixels per line depends on the available
> > > > > > bandwidth.  In a digital variant (which is anything generated by a
> > > > > > digital computer system), the latter depends on the pixel clock, which
> > > > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g.
> > > > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)).
> > > > > >
> > > > > > So I think we probably need some way to generate a PAL/NTSC-compatible
> > > > > > mode based not only on resolution, but also on pixel clock.
> > > > >
> > > > > This would also fix the comments made by Jani and Thomas, so I quite
> > > > > like the idea of it.
> > > > >
> > > > > I'm struggling a bit to find how would could implement this though.
> > > > >
> > > > > From what you were saying, I guess the prototype would be something like
> > > > >
> > > > > struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock,
> > > > >                                                 unsigned int lines,
> > > > >                                                 unsigned int frame_rate)
> > > > >
> > > > > But I have zero idea on what the implementation would be. Do you have
> > > > > some resources for this you could point me to?
> > > >
> > > > Horizontally, I think you should calculate left/right margins and
> > > > hsync length to yield timings that match those for the BT.656 PAL/NTSC
> > > > modes.  I.e. when a 640x512 mode with a pixel clock of 14 MHz is
> > > > requested, you want to calculate left', right', and hslen' for
> > > >
> > > > | <---- left' ---> | <- 640 pixels -> | <---- right' ---> | <--- hslen' --> |
> > > >                         @ 14 MHz
> > > >
> > > > so they match the timings for left, right, and hslen for
> > > >
> > > > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> |
> > > >                         @ 13.5 MHz
> > > >
> > > > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz,
> > > > you want to make sure to align the center of the visible part.
> > >
> > > So I guess in that example if we want to center it, left == right and
> > > left' == right'? What about the sync length?
> >
> > No, left and right are asymmetrical, cfr. front and back porch in
> > https://en.wikipedia.org/wiki/PAL#PAL_signal_details
> > I.e. if the pixel part is reduced, both the left and right margins
> > should be increased by the same amount.
> >
> > From the table linked above, hslen should be ca. 4.7µs (fixed).
>
> each pixel taking 1 / pixel_clock seconds (assuming pixel_clock is in
> Hz), and thus hslen (in pixels) = 4.7 * 10 ^ -6 * pixel_clk, right?

Exactly.

> > > > Vertically, it's simpler, as the number of lines is discrete.
> > > > You do have to take into account interlace and doublescan, and
> > > > progressive modes with 262/312 lines.
> > >
> > > So we only have to deal with 525 and 625 lines total (without taking
> > > interlace and doublescan into account), right?
> >
> > Yes.
> >
> > > I guess we still have the same question, we probably want to center it,
> > > so top == bottom, but what about the vsync length?
> >
> > Unfortunately that table does not mention top and bottom margins.
> > But according to drivers/video/fbdev/amifb.c (see the "Broadcast
> > video timings" comment block and the definitions of the "ntsc-lace"
> > and "pal-lace" video modes), they are asymmetrical, too.
> >
> > Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't
> > have that info when I wrote amifb, as I used 4 lines there).
>
> Thanks, that's some great info already.
>
> It's mentioned though that the settings for NTSC are "straightforward",
> but it's definitely not for me :)

As in NTSC just uses different pixel clock and horizontal/vertical sync
rate values...

> I've looked around and it looks like the entire blanking area is
> supposed to be 40 pixels in interlaced, but I couldn't find anywhere how

625 lines - 575[*] visible lines = 50 lines.

[*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
     a frame in two fields of equal size.

"visible" is relative, as it includes the overscan region.
Some PAL monitors used with computers had knobs to control width/height
and position of the screen, so you could make use of most or all of
the overscan region, but on a real TV you're limited to ca. 640x512 (on
PAL)  which is what an Amiga used by default (with a 14 MHz pixclock).
> it's supposed to be split between the upper and lower margins and the
> sync period.

"Field Synchronization of PAL System" on http://martin.hinner.info/vga/pal.html
shows the split.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

Hi!

On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > > Vertically, it's simpler, as the number of lines is discrete.
> > > > > You do have to take into account interlace and doublescan, and
> > > > > progressive modes with 262/312 lines.
> > > >
> > > > So we only have to deal with 525 and 625 lines total (without taking
> > > > interlace and doublescan into account), right?
> > >
> > > Yes.
> > >
> > > > I guess we still have the same question, we probably want to center it,
> > > > so top == bottom, but what about the vsync length?
> > >
> > > Unfortunately that table does not mention top and bottom margins.
> > > But according to drivers/video/fbdev/amifb.c (see the "Broadcast
> > > video timings" comment block and the definitions of the "ntsc-lace"
> > > and "pal-lace" video modes), they are asymmetrical, too.
> > >
> > > Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't
> > > have that info when I wrote amifb, as I used 4 lines there).
> >
> > Thanks, that's some great info already.
> >
> > It's mentioned though that the settings for NTSC are "straightforward",
> > but it's definitely not for me :)
> 
> As in NTSC just uses different pixel clock and horizontal/vertical sync
> rate values...

Oh, so the constants differ but the calculation is the same, ack.

> > I've looked around and it looks like the entire blanking area is
> > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> 
> 625 lines - 575[*] visible lines = 50 lines.
> 
> [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
>      a frame in two fields of equal size.
> 
> "visible" is relative, as it includes the overscan region.
> Some PAL monitors used with computers had knobs to control width/height
> and position of the screen, so you could make use of most or all of
> the overscan region

It brings back some memories :)

> but on a real TV you're limited to ca. 640x512 (on PAL) which is what
> an Amiga used by default (with a 14 MHz pixclock).

> > it's supposed to be split between the upper and lower margins and the
> > sync period.
> 
> "Field Synchronization of PAL System" on
> http://martin.hinner.info/vga/pal.html shows the split.

Thanks, that's excellent as well.

I'm mostly done with a function that creates a PAL mode, but I still
have one question.

If I understand well, the blanking period is made up (interlace) of 16
pulses for the first field, 14 for the second, each pulse taking half a
line. That amount to 30 pulses, so 15 lines.

I first assumed that the pre-equalizing pulses would be the back porch,
the long sync pulses the vsync, and the post-equalizing pulses the front
porch. But... we're still missing 35 lines to amount to 625 lines, that
seems to be counted in the field itself (305 lines == (575 + 35) / 2)

So I guess my assumption was wrong to begin with.

You seem to have used a fixed vsync in amifb to 4 lines, and I don't
understand how you come up with the upper and lower margins (or rather,
how they are linked to what's described in that page)

Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > I've looked around and it looks like the entire blanking area is
> > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> >
> > 625 lines - 575[*] visible lines = 50 lines.
> >
> > [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
> >      a frame in two fields of equal size.
> >
> > "visible" is relative, as it includes the overscan region.
> > Some PAL monitors used with computers had knobs to control width/height
> > and position of the screen, so you could make use of most or all of
> > the overscan region
>
> It brings back some memories :)
>
> > but on a real TV you're limited to ca. 640x512 (on PAL) which is what
> > an Amiga used by default (with a 14 MHz pixclock).
>
> > > it's supposed to be split between the upper and lower margins and the
> > > sync period.
> >
> > "Field Synchronization of PAL System" on
> > http://martin.hinner.info/vga/pal.html shows the split.
>
> Thanks, that's excellent as well.
>
> I'm mostly done with a function that creates a PAL mode, but I still
> have one question.
>
> If I understand well, the blanking period is made up (interlace) of 16
> pulses for the first field, 14 for the second, each pulse taking half a
> line. That amount to 30 pulses, so 15 lines.
>
> I first assumed that the pre-equalizing pulses would be the back porch,
> the long sync pulses the vsync, and the post-equalizing pulses the front
> porch. But... we're still missing 35 lines to amount to 625 lines, that
> seems to be counted in the field itself (305 lines == (575 + 35) / 2)
>
> So I guess my assumption was wrong to begin with.

The back porch is the number of lines between the last "visible" line
and the start of the synchronization pulse, i.e. "l" in the "Field
Synchronization of PAL System" drawing.
Virtual sync length is "m".
The front porch is the number of lines between the end of
the synchronization pulse, and the first "visible" line, i.e.
"j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

> You seem to have used a fixed vsync in amifb to 4 lines, and I don't

Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
so "4" is not that much off of 2.5 + 3.

> understand how you come up with the upper and lower margins (or rather,
> how they are linked to what's described in that page)

These margins probably came from the Amiga hardware reference manual,
for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > I've looked around and it looks like the entire blanking area is
> > > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> > >
> > > 625 lines - 575[*] visible lines = 50 lines.
> > >
> > > [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
> > >      a frame in two fields of equal size.
> > >
> > > "visible" is relative, as it includes the overscan region.
> > > Some PAL monitors used with computers had knobs to control width/height
> > > and position of the screen, so you could make use of most or all of
> > > the overscan region
> >
> > It brings back some memories :)
> >
> > > but on a real TV you're limited to ca. 640x512 (on PAL) which is what
> > > an Amiga used by default (with a 14 MHz pixclock).
> >
> > > > it's supposed to be split between the upper and lower margins and the
> > > > sync period.
> > >
> > > "Field Synchronization of PAL System" on
> > > http://martin.hinner.info/vga/pal.html shows the split.
> >
> > Thanks, that's excellent as well.
> >
> > I'm mostly done with a function that creates a PAL mode, but I still
> > have one question.
> >
> > If I understand well, the blanking period is made up (interlace) of 16
> > pulses for the first field, 14 for the second, each pulse taking half a
> > line. That amount to 30 pulses, so 15 lines.
> >
> > I first assumed that the pre-equalizing pulses would be the back porch,
> > the long sync pulses the vsync, and the post-equalizing pulses the front
> > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> >
> > So I guess my assumption was wrong to begin with.
> 
> The back porch is the number of lines between the last "visible" line
> and the start of the synchronization pulse, i.e. "l" in the "Field
> Synchronization of PAL System" drawing.
> Virtual sync length is "m".
> The front porch is the number of lines between the end of
> the synchronization pulse, and the first "visible" line, i.e.
> "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).

Ah, yes, that makes sense

> > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> 
> Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> so "4" is not that much off of 2.5 + 3.

Is it? If I'm reading that drawing well, l before the first field starts
on the second half of line 623 and stops at the end of line 625, so 2.5
line, and on the second field starts at the beginning of line 311, and
stops half-way through 313 so 2.5 line again.

Then, for the first field, m starts at the beginning of line 1, stops
half-way through line 3, so 2.5 line indeed, and then on the second
field starts on the second half of 313 and stops at the end of line 315.
So 2.5 again?

Thus, both should be 5?

> > understand how you come up with the upper and lower margins (or rather,
> > how they are linked to what's described in that page)
> 
> These margins probably came from the Amiga hardware reference manual,
> for the default 640x512 (PAL) and 640x400 (NTSC) modes.

Ok.

I started adding more sanity checks to my code, and I just realised I
don't seem to be able to reach 720 pixels over a single line though. If
I understood it properly, and according to [1] the active part of a line
is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
in the timing section has pretty much the same numbers, so it looks
sane.

At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
pixels

It seems we can go push it to 52350 ns, but that still gives us only 706
pixels.

Similarly, if I just choose to ignore that limit and just take the
active time I need, 720 * 74 = 53280ns

That leaves us 10720ns for the blanking period, and that's not enough to
fit even the minimum of the front porch, hsync and back porch (1.55 +
4.5 + 5.5 = 11.55us).

Are those constraints merely recommendations, or am I missing something?

Thanks!
Maxime

1: https://en.wikipedia.org/wiki/PAL#PAL_signal_details
2: http://martin.hinner.info/vga/pal.html

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > > I've looked around and it looks like the entire blanking area is
> > > > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> > > >
> > > > 625 lines - 575[*] visible lines = 50 lines.
> > > >
> > > > [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
> > > >      a frame in two fields of equal size.
> > > >
> > > > "visible" is relative, as it includes the overscan region.
> > > > Some PAL monitors used with computers had knobs to control width/height
> > > > and position of the screen, so you could make use of most or all of
> > > > the overscan region
> > >
> > > It brings back some memories :)
> > >
> > > > but on a real TV you're limited to ca. 640x512 (on PAL) which is what
> > > > an Amiga used by default (with a 14 MHz pixclock).
> > >
> > > > > it's supposed to be split between the upper and lower margins and the
> > > > > sync period.
> > > >
> > > > "Field Synchronization of PAL System" on
> > > > http://martin.hinner.info/vga/pal.html shows the split.
> > >
> > > Thanks, that's excellent as well.
> > >
> > > I'm mostly done with a function that creates a PAL mode, but I still
> > > have one question.
> > >
> > > If I understand well, the blanking period is made up (interlace) of 16
> > > pulses for the first field, 14 for the second, each pulse taking half a
> > > line. That amount to 30 pulses, so 15 lines.
> > >
> > > I first assumed that the pre-equalizing pulses would be the back porch,
> > > the long sync pulses the vsync, and the post-equalizing pulses the front
> > > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> > >
> > > So I guess my assumption was wrong to begin with.
> >
> > The back porch is the number of lines between the last "visible" line
> > and the start of the synchronization pulse, i.e. "l" in the "Field
> > Synchronization of PAL System" drawing.
> > Virtual sync length is "m".
> > The front porch is the number of lines between the end of
> > the synchronization pulse, and the first "visible" line, i.e.
> > "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).
>
> Ah, yes, that makes sense
>
> > > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> >
> > Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> > so "4" is not that much off of 2.5 + 3.
>
> Is it? If I'm reading that drawing well, l before the first field starts
> on the second half of line 623 and stops at the end of line 625, so 2.5
> line, and on the second field starts at the beginning of line 311, and
> stops half-way through 313 so 2.5 line again.
>
> Then, for the first field, m starts at the beginning of line 1, stops
> half-way through line 3, so 2.5 line indeed, and then on the second
> field starts on the second half of 313 and stops at the end of line 315.
> So 2.5 again?
>
> Thus, both should be 5?

Possibly. Note that this for the official broadcast PAL.

I never looked at these signals with a scope, but I wouldn't be
surprised if some
device on't bother implementing the "half-line-sync", and synchronize
the start and stop of the vertical
sync signal with the start of a horizontal.

> > > understand how you come up with the upper and lower margins (or rather,
> > > how they are linked to what's described in that page)
> >
> > These margins probably came from the Amiga hardware reference manual,
> > for the default 640x512 (PAL) and 640x400 (NTSC) modes.
>
> Ok.
>
> I started adding more sanity checks to my code, and I just realised I
> don't seem to be able to reach 720 pixels over a single line though. If
> I understood it properly, and according to [1] the active part of a line
> is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
> in the timing section has pretty much the same numbers, so it looks
> sane.
>
> At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
> pixels
>
> It seems we can go push it to 52350 ns, but that still gives us only 706
> pixels.
>
> Similarly, if I just choose to ignore that limit and just take the
> active time I need, 720 * 74 = 53280ns
>
> That leaves us 10720ns for the blanking period, and that's not enough to
> fit even the minimum of the front porch, hsync and back porch (1.55 +
> 4.5 + 5.5 = 11.55us).
>
> Are those constraints merely recommendations, or am I missing something?

You are missing that the parts near the borders of the full image are
part of the overscan range, and may or may not be visible, depending
on your actual display.
The full 768x576 image size from BT.656 is not visible on a typical PAL display,
and is more of an "absolute maximum rating", guaranteed to cover more
than analog PAL.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Thu, Aug 18, 2022 at 02:57:55PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 18, 2022 at 2:39 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Wed, Aug 17, 2022 at 04:01:48PM +0200, Geert Uytterhoeven wrote:
> > > > > > I've looked around and it looks like the entire blanking area is
> > > > > > supposed to be 40 pixels in interlaced, but I couldn't find anywhere how
> > > > >
> > > > > 625 lines - 575[*] visible lines = 50 lines.
> > > > >
> > > > > [*] BT.656 uses 576 visible lines as that's a multiple of 2, for splitting
> > > > >      a frame in two fields of equal size.
> > > > >
> > > > > "visible" is relative, as it includes the overscan region.
> > > > > Some PAL monitors used with computers had knobs to control width/height
> > > > > and position of the screen, so you could make use of most or all of
> > > > > the overscan region
> > > >
> > > > It brings back some memories :)
> > > >
> > > > > but on a real TV you're limited to ca. 640x512 (on PAL) which is what
> > > > > an Amiga used by default (with a 14 MHz pixclock).
> > > >
> > > > > > it's supposed to be split between the upper and lower margins and the
> > > > > > sync period.
> > > > >
> > > > > "Field Synchronization of PAL System" on
> > > > > http://martin.hinner.info/vga/pal.html shows the split.
> > > >
> > > > Thanks, that's excellent as well.
> > > >
> > > > I'm mostly done with a function that creates a PAL mode, but I still
> > > > have one question.
> > > >
> > > > If I understand well, the blanking period is made up (interlace) of 16
> > > > pulses for the first field, 14 for the second, each pulse taking half a
> > > > line. That amount to 30 pulses, so 15 lines.
> > > >
> > > > I first assumed that the pre-equalizing pulses would be the back porch,
> > > > the long sync pulses the vsync, and the post-equalizing pulses the front
> > > > porch. But... we're still missing 35 lines to amount to 625 lines, that
> > > > seems to be counted in the field itself (305 lines == (575 + 35) / 2)
> > > >
> > > > So I guess my assumption was wrong to begin with.
> > >
> > > The back porch is the number of lines between the last "visible" line
> > > and the start of the synchronization pulse, i.e. "l" in the "Field
> > > Synchronization of PAL System" drawing.
> > > Virtual sync length is "m".
> > > The front porch is the number of lines between the end of
> > > the synchronization pulse, and the first "visible" line, i.e.
> > > "j - l - m" (I think you used "n", thus missing lines 6-23 and 319-335).
> >
> > Ah, yes, that makes sense
> >
> > > > You seem to have used a fixed vsync in amifb to 4 lines, and I don't
> > >
> > > Actually "m" is 2.5 lines in the first field, and 3 lines in the second field,
> > > so "4" is not that much off of 2.5 + 3.
> >
> > Is it? If I'm reading that drawing well, l before the first field starts
> > on the second half of line 623 and stops at the end of line 625, so 2.5
> > line, and on the second field starts at the beginning of line 311, and
> > stops half-way through 313 so 2.5 line again.
> >
> > Then, for the first field, m starts at the beginning of line 1, stops
> > half-way through line 3, so 2.5 line indeed, and then on the second
> > field starts on the second half of 313 and stops at the end of line 315.
> > So 2.5 again?
> >
> > Thus, both should be 5?
> 
> Possibly. Note that this for the official broadcast PAL.
> 
> I never looked at these signals with a scope, but I wouldn't be
> surprised if some
> device on't bother implementing the "half-line-sync", and synchronize
> the start and stop of the vertical
> sync signal with the start of a horizontal.

Yeah... official PAL looks like a good enough target to me :)

We'll always be able to tweak it if needed later on.

> > > > understand how you come up with the upper and lower margins (or rather,
> > > > how they are linked to what's described in that page)
> > >
> > > These margins probably came from the Amiga hardware reference manual,
> > > for the default 640x512 (PAL) and 640x400 (NTSC) modes.
> >
> > Ok.
> >
> > I started adding more sanity checks to my code, and I just realised I
> > don't seem to be able to reach 720 pixels over a single line though. If
> > I understood it properly, and according to [1] the active part of a line
> > is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
> > in the timing section has pretty much the same numbers, so it looks
> > sane.
> >
> > At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
> > pixels
> >
> > It seems we can go push it to 52350 ns, but that still gives us only 706
> > pixels.
> >
> > Similarly, if I just choose to ignore that limit and just take the
> > active time I need, 720 * 74 = 53280ns
> >
> > That leaves us 10720ns for the blanking period, and that's not enough to
> > fit even the minimum of the front porch, hsync and back porch (1.55 +
> > 4.5 + 5.5 = 11.55us).
> >
> > Are those constraints merely recommendations, or am I missing something?
> 
> You are missing that the parts near the borders of the full image are
> part of the overscan range, and may or may not be visible, depending
> on your actual display.
> The full 768x576 image size from BT.656 is not visible on a typical PAL display,
> and is more of an "absolute maximum rating", guaranteed to cover more
> than analog PAL.

So the overscan range is not part of the active area, unlike what HDMI
is doing for example?

Is there some minimal timings available somewhere to fit those absolute
maximum ratings?

Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Aug 18, 2022 at 5:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > I started adding more sanity checks to my code, and I just realised I
> > > don't seem to be able to reach 720 pixels over a single line though. If
> > > I understood it properly, and according to [1] the active part of a line
> > > is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
> > > in the timing section has pretty much the same numbers, so it looks
> > > sane.
> > >
> > > At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
> > > pixels
> > >
> > > It seems we can go push it to 52350 ns, but that still gives us only 706
> > > pixels.
> > >
> > > Similarly, if I just choose to ignore that limit and just take the
> > > active time I need, 720 * 74 = 53280ns
> > >
> > > That leaves us 10720ns for the blanking period, and that's not enough to
> > > fit even the minimum of the front porch, hsync and back porch (1.55 +
> > > 4.5 + 5.5 = 11.55us).
> > >
> > > Are those constraints merely recommendations, or am I missing something?
> >
> > You are missing that the parts near the borders of the full image are
> > part of the overscan range, and may or may not be visible, depending
> > on your actual display.
> > The full 768x576 image size from BT.656 is not visible on a typical PAL display,
> > and is more of an "absolute maximum rating", guaranteed to cover more
> > than analog PAL.
>
> So the overscan range is not part of the active area, unlike what HDMI
> is doing for example?

Indeed. DVI-D and HDMI etc. are pure digital (let's ignore they are a
digitized variant of old analog VGA ;-), hence there is a one-to-one
match between pixels in the image and pixels on the screen (ignoring
scaling).  But even when using an analog VGA input on a modern
digital display, you have controls to e.g. move the image.

> Is there some minimal timings available somewhere to fit those absolute
> maximum ratings?

I guess they can be found on the Internet...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Mateusz Kwiatkowski]

Hi Maxime,

W dniu 18.08.2022 o 17:56, Geert Uytterhoeven pisze:
> Hi Maxime,
>
> On Thu, Aug 18, 2022 at 5:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
>> On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
>>> On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime@cerno.tech> wrote:
>>>> I started adding more sanity checks to my code, and I just realised I
>>>> don't seem to be able to reach 720 pixels over a single line though. If
>>>> I understood it properly, and according to [1] the active part of a line
>>>> is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
>>>> in the timing section has pretty much the same numbers, so it looks
>>>> sane.
>>>>
>>>> At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
>>>> pixels
>>>>
>>>> It seems we can go push it to 52350 ns, but that still gives us only 706
>>>> pixels.
>>>>
>>>> Similarly, if I just choose to ignore that limit and just take the
>>>> active time I need, 720 * 74 = 53280ns
>>>>
>>>> That leaves us 10720ns for the blanking period, and that's not enough to
>>>> fit even the minimum of the front porch, hsync and back porch (1.55 +
>>>> 4.5 + 5.5 = 11.55us).
>>>>
>>>> Are those constraints merely recommendations, or am I missing something?
>>>
>>> You are missing that the parts near the borders of the full image are
>>> part of the overscan range, and may or may not be visible, depending
>>> on your actual display.
>>> The full 768x576 image size from BT.656 is not visible on a typical PAL display,
>>> and is more of an "absolute maximum rating", guaranteed to cover more
>>> than analog PAL.
>>
>> So the overscan range is not part of the active area, unlike what HDMI
>> is doing for example?
>
> Indeed. DVI-D and HDMI etc. are pure digital (let's ignore they are a
> digitized variant of old analog VGA ;-), hence there is a one-to-one
> match between pixels in the image and pixels on the screen (ignoring
> scaling).  But even when using an analog VGA input on a modern
> digital display, you have controls to e.g. move the image.
>
>> Is there some minimal timings available somewhere to fit those absolute
>> maximum ratings?
>
> I guess they can be found on the Internet...

Here are some references that I personally found useful:

- ITU-R BT.601 <https://www.itu.int/rec/R-REC-BT.601/en>
  This is *the* standard that pretty much every modern device that deals with
  analog-style TV signal follows then converting to and from the digital domain.
  For example in the figures on page 10 (12 in the PDF numbering) you can see
  that the "time datum", i.e. start of horizontal sync pulse is canonically
  supposed to happen on sample 732 for 50 Hz or sample 736 for 59.94 Hz modes.

  BT.601 assumes 13.5 MHz sample rate / pixel clock, but you can proportionally
  scale those for other pixel clocks.

- ITU-R BT.1700 <https://www.itu.int/rec/R-REC-BT.1700/en>
  This is *the* standard in force for actual analog composite video signals.
  The vertical sync specs are discrete, so they don't really change between
  analog and digital domains. For horizontal sync, the values in those specs
  are given in microseconds/nanoseconds, but you can multiply those by the
  sampling rate for equivalent pixel counts.

- Pembers' Ponderings
  <https://web.archive.org/web/20160423225838/http://www.pembers.freeserve.co.uk/>
  An old archived website with a ton of resources about analog TV.
  The "Line Standards" article will probably be most interesting to you.

By the way, please note a couple of things:

- The analog standards are very imprecise for modern digital norms, giving
  considerable leeway for just about every timing. The allowed leeways are
  usually equivalent to a couple of pixels at the standard 13.5 MHz sampling
  rate - and those are meant for the transmitting end. Receivers are usually
  much more forgiving to maximize compatibility.

- The 720-pixel standard of BT.601 is considerably wider than the active width
  specified in the analog standards. AFAIK this is intentional, to ensure that
  no part of the actual image is missed during digitization, and to keep the
  number a nice multiply of 16. The picture width given in the analog standards
  is equivalent to somewhere between 702 and 714 pixels (at 13.5 MHz clock),
  depending on the specific standard. And that includes overscan.

- Same goes for the vertical active area. Original analog standards varied
  wildly from country to country, before finally settling on 575 lines for the
  50 Hz standard and 485 lines for the 59.94 Hz standard. Or 576/486, depending
  on how you count. The topmost line of those 576/486 starts at half the screen,
  and the bottommost line ends at half the screen - so they are often combined
  when counting and given as 575/485. The digital 576i50 standard includes
  those half-lines. In the 59.94 Hz regions, 480 active digial lines ended up
  the norm, because 486 does not have nice dividers, and also some of the
  outermost lines which were always overscanned anyway, ended up used for things
  like closed captioning over the years.

- Speaking of closed captioning... a lot of different stuff were put in the
  blanking interval over the years. Like teletext in Europe. There are projects
  like VBIT2 <https://github.com/peterkvt80/vbit2> which intentionally
  reconfigure the Raspberry Pi composite output to include the blanking interval
  in the framebuffer so that teletext can be output by drawing on the edge of
  the "screen" (from the computer point of view).

- A lot of equipment outside the broadcast industry willingly violated those
  standards, and there are real world use cases for that. Film studios used very
  slightly modified TVs to make them sync with 24fps cameras - in that variant,
  "NTSC" could have e.g. 655 lines so that the TV would refresh at 48 Hz with
  the same line frequency. Home computers and video game consoles output
  progressive 262/312-line modes instead of interlaced 525/625 lines. And often
  changed the line frequency slightly as well, for various reasons. Those
  progressive modes are still favored by retro gaming and emulation enthusiasts,
  because they incur a specific look on CRT displays. Even playing back video
  from a tape (especially home-grade, like VHS) could cause timings to go wildly
  out of spec, because of mechanical imprecisions.

- There were multitude of standards predating the ubiquitous 525/60 and 625/50
  modes. The British 405-line and French 819-line standards are the most
  notorious, having lasted well into the 1980s, but there were also a lot of
  wildly varying pre-WW2 television systems. And there are enthusiasts dedicated
  to preserving those.

My point is that the norms for analog TV are rather loose, and I think we
shouldn't limit the drivers to only accepting the "proper" modes as defined in
the spec. Those should of course be the default, but if non-standard modelines
can be generated - there are legitimate use cases why people might want those.

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Best regards,
Mateusz Kwiatkowski

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

Hi Mateusz

On Wed, Aug 24, 2022 at 06:42:18PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
> 
> W dniu 18.08.2022 o 17:56, Geert Uytterhoeven pisze:
> > Hi Maxime,
> >
> > On Thu, Aug 18, 2022 at 5:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >> On Thu, Aug 18, 2022 at 05:34:30PM +0200, Geert Uytterhoeven wrote:
> >>> On Thu, Aug 18, 2022 at 3:42 PM Maxime Ripard <maxime@cerno.tech> wrote:
> >>>> I started adding more sanity checks to my code, and I just realised I
> >>>> don't seem to be able to reach 720 pixels over a single line though. If
> >>>> I understood it properly, and according to [1] the active part of a line
> >>>> is supposed to be 51.95us, and the blanking period taking 12.05us. [2]
> >>>> in the timing section has pretty much the same numbers, so it looks
> >>>> sane.
> >>>>
> >>>> At 13.5Mhz, a pixel is going to take roughly 74ns, and 51950 / 74 = 702
> >>>> pixels
> >>>>
> >>>> It seems we can go push it to 52350 ns, but that still gives us only 706
> >>>> pixels.
> >>>>
> >>>> Similarly, if I just choose to ignore that limit and just take the
> >>>> active time I need, 720 * 74 = 53280ns
> >>>>
> >>>> That leaves us 10720ns for the blanking period, and that's not enough to
> >>>> fit even the minimum of the front porch, hsync and back porch (1.55 +
> >>>> 4.5 + 5.5 = 11.55us).
> >>>>
> >>>> Are those constraints merely recommendations, or am I missing something?
> >>>
> >>> You are missing that the parts near the borders of the full image are
> >>> part of the overscan range, and may or may not be visible, depending
> >>> on your actual display.
> >>> The full 768x576 image size from BT.656 is not visible on a typical PAL display,
> >>> and is more of an "absolute maximum rating", guaranteed to cover more
> >>> than analog PAL.
> >>
> >> So the overscan range is not part of the active area, unlike what HDMI
> >> is doing for example?
> >
> > Indeed. DVI-D and HDMI etc. are pure digital (let's ignore they are a
> > digitized variant of old analog VGA ;-), hence there is a one-to-one
> > match between pixels in the image and pixels on the screen (ignoring
> > scaling).  But even when using an analog VGA input on a modern
> > digital display, you have controls to e.g. move the image.
> >
> >> Is there some minimal timings available somewhere to fit those absolute
> >> maximum ratings?
> >
> > I guess they can be found on the Internet...
> 
> Here are some references that I personally found useful:
> 
> - ITU-R BT.601 <https://www.itu.int/rec/R-REC-BT.601/en>
>   This is *the* standard that pretty much every modern device that deals with
>   analog-style TV signal follows then converting to and from the digital domain.
>   For example in the figures on page 10 (12 in the PDF numbering) you can see
>   that the "time datum", i.e. start of horizontal sync pulse is canonically
>   supposed to happen on sample 732 for 50 Hz or sample 736 for 59.94 Hz modes.
> 
>   BT.601 assumes 13.5 MHz sample rate / pixel clock, but you can proportionally
>   scale those for other pixel clocks.
> 
> - ITU-R BT.1700 <https://www.itu.int/rec/R-REC-BT.1700/en>
>   This is *the* standard in force for actual analog composite video signals.
>   The vertical sync specs are discrete, so they don't really change between
>   analog and digital domains. For horizontal sync, the values in those specs
>   are given in microseconds/nanoseconds, but you can multiply those by the
>   sampling rate for equivalent pixel counts.
> 
> - Pembers' Ponderings
>   <https://web.archive.org/web/20160423225838/http://www.pembers.freeserve.co.uk/>
>   An old archived website with a ton of resources about analog TV.
>   The "Line Standards" article will probably be most interesting to you.

Thanks so much for all those resources, it's been super helpful :)

> By the way, please note a couple of things:
> 
> - The analog standards are very imprecise for modern digital norms, giving
>   considerable leeway for just about every timing. The allowed leeways are
>   usually equivalent to a couple of pixels at the standard 13.5 MHz sampling
>   rate - and those are meant for the transmitting end. Receivers are usually
>   much more forgiving to maximize compatibility.

Ok

> - The 720-pixel standard of BT.601 is considerably wider than the active width
>   specified in the analog standards. AFAIK this is intentional, to ensure that
>   no part of the actual image is missed during digitization, and to keep the
>   number a nice multiply of 16. The picture width given in the analog standards
>   is equivalent to somewhere between 702 and 714 pixels (at 13.5 MHz clock),
>   depending on the specific standard. And that includes overscan.

Ok. I think it still makes sense to allow it, if only we were using it so far :)

I've done a first implementation in the v2 I just sent that seems to
work ok, please let me know if I did anything stupid :)

In particular, I chose, if we were between 702 and 720 pixels to disable
all duration checks, and take the missing time from the front and back
porch, in equal proportions.

> - Same goes for the vertical active area. Original analog standards varied
>   wildly from country to country, before finally settling on 575 lines for the
>   50 Hz standard and 485 lines for the 59.94 Hz standard. Or 576/486, depending
>   on how you count. The topmost line of those 576/486 starts at half the screen,
>   and the bottommost line ends at half the screen - so they are often combined
>   when counting and given as 575/485. The digital 576i50 standard includes
>   those half-lines. In the 59.94 Hz regions, 480 active digial lines ended up
>   the norm, because 486 does not have nice dividers, and also some of the
>   outermost lines which were always overscanned anyway, ended up used for things
>   like closed captioning over the years.

Ok

> - Speaking of closed captioning... a lot of different stuff were put in the
>   blanking interval over the years. Like teletext in Europe. There are projects
>   like VBIT2 <https://github.com/peterkvt80/vbit2> which intentionally
>   reconfigure the Raspberry Pi composite output to include the blanking interval
>   in the framebuffer so that teletext can be output by drawing on the edge of
>   the "screen" (from the computer point of view).

I'm not sure how we would support this in KMS to be honest. Asking for a
wider mode and the userspace putting whatever it wants in the margins
seems like a good choice.

> - A lot of equipment outside the broadcast industry willingly violated those
>   standards, and there are real world use cases for that. Film studios used very
>   slightly modified TVs to make them sync with 24fps cameras - in that variant,
>   "NTSC" could have e.g. 655 lines so that the TV would refresh at 48 Hz with
>   the same line frequency. Home computers and video game consoles output
>   progressive 262/312-line modes instead of interlaced 525/625 lines. And often
>   changed the line frequency slightly as well, for various reasons. Those
>   progressive modes are still favored by retro gaming and emulation enthusiasts,
>   because they incur a specific look on CRT displays. Even playing back video
>   from a tape (especially home-grade, like VHS) could cause timings to go wildly
>   out of spec, because of mechanical imprecisions.

Ok

> - There were multitude of standards predating the ubiquitous 525/60 and 625/50
>   modes. The British 405-line and French 819-line standards are the most
>   notorious, having lasted well into the 1980s, but there were also a lot of
>   wildly varying pre-WW2 television systems. And there are enthusiasts dedicated
>   to preserving those.
> 
> My point is that the norms for analog TV are rather loose, and I think we
> shouldn't limit the drivers to only accepting the "proper" modes as defined in
> the spec. Those should of course be the default, but if non-standard modelines
> can be generated - there are legitimate use cases why people might want those.

Yep, that part has been dropped. I'm still wondering if we'd need to
still have a bunch of restrictions (like a total number of lines of 625
with NTSC would be obviously invalid), but that can always be added
later on if such a need comes up

Maxime

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

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Geert Uytterhoeven]

Hi Maxime,

On Mon, Aug 29, 2022 at 3:30 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 24, 2022 at 06:42:18PM +0200, Mateusz Kwiatkowski wrote:
> > - Speaking of closed captioning... a lot of different stuff were put in the
> >   blanking interval over the years. Like teletext in Europe. There are projects
> >   like VBIT2 <https://github.com/peterkvt80/vbit2> which intentionally
> >   reconfigure the Raspberry Pi composite output to include the blanking interval
> >   in the framebuffer so that teletext can be output by drawing on the edge of
> >   the "screen" (from the computer point of view).
>
> I'm not sure how we would support this in KMS to be honest. Asking for a
> wider mode and the userspace putting whatever it wants in the margins
> seems like a good choice.

s/wider/higher/

Teletext is transmitted in the "visible" parts of (horizontal) lines, but during
the vertical blank.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes

[Maxime Ripard]

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

On Mon, Aug 29, 2022 at 04:14:54PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Mon, Aug 29, 2022 at 3:30 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 24, 2022 at 06:42:18PM +0200, Mateusz Kwiatkowski wrote:
> > > - Speaking of closed captioning... a lot of different stuff were put in the
> > >   blanking interval over the years. Like teletext in Europe. There are projects
> > >   like VBIT2 <https://github.com/peterkvt80/vbit2> which intentionally
> > >   reconfigure the Raspberry Pi composite output to include the blanking interval
> > >   in the framebuffer so that teletext can be output by drawing on the edge of
> > >   the "screen" (from the computer point of view).
> >
> > I'm not sure how we would support this in KMS to be honest. Asking for a
> > wider mode and the userspace putting whatever it wants in the margins
> > seems like a good choice.
> 
> s/wider/higher/
> 
> Teletext is transmitted in the "visible" parts of (horizontal) lines, but during
> the vertical blank.

Yeah, sorry I meant wider as in larger than the active area, without any
direction in mind. Thanks for the correction :)

Maxime

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

[PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.

Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and user-space.

Let's create a new bitmask tv norm property, that can contain any of the
analog TV standards currently supported by kernel drivers. Each driver can
then pass in a bitmask of the modes it supports.

We'll then be able to phase out the older tv mode property.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..d7ff6c644c2f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		state->tv.margins.bottom = val;
 	} else if (property == config->tv_mode_property) {
 		state->tv.mode = val;
+	} else if (property == config->tv_norm_property) {
+		state->tv.norm = val;
 	} else if (property == config->tv_brightness_property) {
 		state->tv.brightness = val;
 	} else if (property == config->tv_contrast_property) {
@@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->tv.margins.bottom;
 	} else if (property == config->tv_mode_property) {
 		*val = state->tv.mode;
+	} else if (property == config->tv_norm_property) {
+		*val = state->tv.norm;
 	} else if (property == config->tv_brightness_property) {
 		*val = state->tv.brightness;
 	} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..68a4e47f85a9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
 /**
  * drm_mode_create_tv_properties - create TV specific connector properties
  * @dev: DRM device
+ * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
  * @num_modes: number of different TV formats (modes) supported
  * @modes: array of pointers to strings containing name of each format
  *
@@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * 0 on success or a negative error code on failure.
  */
 int drm_mode_create_tv_properties(struct drm_device *dev,
+				  unsigned int supported_tv_norms,
 				  unsigned int num_modes,
 				  const char * const modes[])
 {
+	static const struct drm_prop_enum_list tv_norm_values[] = {
+		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
+		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
+	};
 	struct drm_property *tv_selector;
 	struct drm_property *tv_subconnector;
+	struct drm_property *tv_norm;
 	unsigned int i;
 
 	if (dev->mode_config.tv_select_subconnector_property)
@@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 	if (drm_mode_create_tv_margin_properties(dev))
 		goto nomem;
 
+	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
+					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
+					   supported_tv_norms);
+	if (!tv_norm)
+		goto nomem;
+	dev->mode_config.tv_norm_property = tv_norm;
+
 	dev->mode_config.tv_mode_property =
 		drm_property_create(dev, DRM_MODE_PROP_ENUM,
 				    "mode", num_modes);
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 4a788c1c9058..457529e5d857 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -573,7 +573,9 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
 	struct vc4_vec *vec;
 	int ret;
 
-	ret = drm_mode_create_tv_properties(drm, ARRAY_SIZE(tv_mode_names),
+	ret = drm_mode_create_tv_properties(drm,
+					    0,
+					    ARRAY_SIZE(tv_mode_names),
 					    tv_mode_names);
 	if (ret)
 		return ret;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1e9996b33cc8..78275e68ff66 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -143,6 +143,32 @@ enum subpixel_order {
 
 };
 
+#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
+#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
+#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
+#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
+#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
+#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
+#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
+#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
+#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
+#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
+#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
+#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
+#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
+#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
+#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
+#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
+#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
+#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
+#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
+#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
+#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
+#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
+#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
+#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
+#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
+
 /**
  * struct drm_scrambling: sink's scrambling support.
  */
@@ -687,6 +713,7 @@ struct drm_tv_connector_state {
 	enum drm_mode_subconnector subconnector;
 	struct drm_connector_tv_margins margins;
 	unsigned int mode;
+	unsigned int norm;
 	unsigned int brightness;
 	unsigned int contrast;
 	unsigned int flicker_reduction;
@@ -1779,6 +1806,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
 
 int drm_mode_create_tv_margin_properties(struct drm_device *dev);
 int drm_mode_create_tv_properties(struct drm_device *dev,
+				  unsigned int supported_tv_norms,
 				  unsigned int num_modes,
 				  const char * const modes[]);
 void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6b5e01295348..d9e79def8b92 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -704,6 +704,12 @@ struct drm_mode_config {
 	 */
 	struct drm_property *dp_subconnector_property;
 
+	/**
+	 * @tv_norm_property: Optional TV property to select the TV
+	 * standard output on the connector.
+	 */
+	struct drm_property *tv_norm_property;
+
 	/**
 	 * @tv_subconnector_property: Optional TV property to differentiate
 	 * between different TV connector types.

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
> 
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
> 
> Let's create a new bitmask tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports.
> 
> We'll then be able to phase out the older tv mode property.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

Please also update Documentation/gpu/kms-properties.csv

Requirements for adding a new property is found in
Documentation/gpu/drm-kms.rst

> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..d7ff6c644c2f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>  		state->tv.margins.bottom = val;
>  	} else if (property == config->tv_mode_property) {
>  		state->tv.mode = val;
> +	} else if (property == config->tv_norm_property) {
> +		state->tv.norm = val;
>  	} else if (property == config->tv_brightness_property) {
>  		state->tv.brightness = val;
>  	} else if (property == config->tv_contrast_property) {
> @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>  		*val = state->tv.margins.bottom;
>  	} else if (property == config->tv_mode_property) {
>  		*val = state->tv.mode;
> +	} else if (property == config->tv_norm_property) {
> +		*val = state->tv.norm;
>  	} else if (property == config->tv_brightness_property) {
>  		*val = state->tv.brightness;
>  	} else if (property == config->tv_contrast_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e3142c8142b3..68a4e47f85a9 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>  /**
>   * drm_mode_create_tv_properties - create TV specific connector properties
>   * @dev: DRM device
> + * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
>   * @num_modes: number of different TV formats (modes) supported
>   * @modes: array of pointers to strings containing name of each format
>   *
> @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>   * 0 on success or a negative error code on failure.
>   */
>  int drm_mode_create_tv_properties(struct drm_device *dev,
> +				  unsigned int supported_tv_norms,
>  				  unsigned int num_modes,
>  				  const char * const modes[])
>  {
> +	static const struct drm_prop_enum_list tv_norm_values[] = {
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> +	};
>  	struct drm_property *tv_selector;
>  	struct drm_property *tv_subconnector;
> +	struct drm_property *tv_norm;
>  	unsigned int i;
>  
>  	if (dev->mode_config.tv_select_subconnector_property)
> @@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  	if (drm_mode_create_tv_margin_properties(dev))
>  		goto nomem;
>  
> +	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
> +					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
> +					   supported_tv_norms);

I expected this to be an enum, why a bitmask? Userspace can set multiple
bits in a bitmask.

Noralf.

> +	if (!tv_norm)
> +		goto nomem;
> +	dev->mode_config.tv_norm_property = tv_norm;
> +
>  	dev->mode_config.tv_mode_property =
>  		drm_property_create(dev, DRM_MODE_PROP_ENUM,
>  				    "mode", num_modes);
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index 4a788c1c9058..457529e5d857 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -573,7 +573,9 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
>  	struct vc4_vec *vec;
>  	int ret;
>  
> -	ret = drm_mode_create_tv_properties(drm, ARRAY_SIZE(tv_mode_names),
> +	ret = drm_mode_create_tv_properties(drm,
> +					    0,
> +					    ARRAY_SIZE(tv_mode_names),
>  					    tv_mode_names);
>  	if (ret)
>  		return ret;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1e9996b33cc8..78275e68ff66 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -143,6 +143,32 @@ enum subpixel_order {
>  
>  };
>  
> +#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
> +#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
> +#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
> +#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
> +#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
> +#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
> +#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
> +#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
> +#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
> +#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
> +#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
> +#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
> +#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
> +#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
> +#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
> +#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
> +#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
> +#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
> +#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
> +#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
> +#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
> +#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
> +#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
> +#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
> +#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
> +
>  /**
>   * struct drm_scrambling: sink's scrambling support.
>   */
> @@ -687,6 +713,7 @@ struct drm_tv_connector_state {
>  	enum drm_mode_subconnector subconnector;
>  	struct drm_connector_tv_margins margins;
>  	unsigned int mode;
> +	unsigned int norm;
>  	unsigned int brightness;
>  	unsigned int contrast;
>  	unsigned int flicker_reduction;
> @@ -1779,6 +1806,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
>  
>  int drm_mode_create_tv_margin_properties(struct drm_device *dev);
>  int drm_mode_create_tv_properties(struct drm_device *dev,
> +				  unsigned int supported_tv_norms,
>  				  unsigned int num_modes,
>  				  const char * const modes[]);
>  void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 6b5e01295348..d9e79def8b92 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -704,6 +704,12 @@ struct drm_mode_config {
>  	 */
>  	struct drm_property *dp_subconnector_property;
>  
> +	/**
> +	 * @tv_norm_property: Optional TV property to select the TV
> +	 * standard output on the connector.
> +	 */
> +	struct drm_property *tv_norm_property;
> +
>  	/**
>  	 * @tv_subconnector_property: Optional TV property to differentiate
>  	 * between different TV connector types.
> 

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

Hi,

On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.34, skrev Maxime Ripard:
> > The TV mode property has been around for a while now to select and get the
> > current TV mode output on an analog TV connector.
> > 
> > Despite that property name being generic, its content isn't and has been
> > driver-specific which makes it hard to build any generic behaviour on top
> > of it, both in kernel and user-space.
> > 
> > Let's create a new bitmask tv norm property, that can contain any of the
> > analog TV standards currently supported by kernel drivers. Each driver can
> > then pass in a bitmask of the modes it supports.
> > 
> > We'll then be able to phase out the older tv mode property.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> 
> Please also update Documentation/gpu/kms-properties.csv
> 
> Requirements for adding a new property is found in
> Documentation/gpu/drm-kms.rst

I knew this was going to be raised at some point, so I'm glad it's that
early :)

I really don't know what to do there. If we stick by our usual rules,
then we can't have any of that work merged.

However, I think the status quo is not really satisfactory either.
Indeed, we have a property, that doesn't follow those requirements
either, with a driver-specific content, and that stands in the way of
fixes and further improvements at both the core framework and driver
levels.

So having that new property still seems like a net improvement at the
driver, framework and uAPI levels, even if it's not entirely following
the requirements we have in place.

Even more so since, realistically, those kind of interfaces will never
get any new development on the user-space side of things, it's
considered by everyone as legacy.

This also is something we need to support at some point if we want to
completely deprecate the fbdev drivers and provide decent alternatives
in KMS.

So yeah, strictly speaking, we would not qualify for our requirements
there. I still think we have a strong case for an exception though.

> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> > index c06d0639d552..d7ff6c644c2f 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
> >  		state->tv.margins.bottom = val;
> >  	} else if (property == config->tv_mode_property) {
> >  		state->tv.mode = val;
> > +	} else if (property == config->tv_norm_property) {
> > +		state->tv.norm = val;
> >  	} else if (property == config->tv_brightness_property) {
> >  		state->tv.brightness = val;
> >  	} else if (property == config->tv_contrast_property) {
> > @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
> >  		*val = state->tv.margins.bottom;
> >  	} else if (property == config->tv_mode_property) {
> >  		*val = state->tv.mode;
> > +	} else if (property == config->tv_norm_property) {
> > +		*val = state->tv.norm;
> >  	} else if (property == config->tv_brightness_property) {
> >  		*val = state->tv.brightness;
> >  	} else if (property == config->tv_contrast_property) {
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index e3142c8142b3..68a4e47f85a9 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> >  /**
> >   * drm_mode_create_tv_properties - create TV specific connector properties
> >   * @dev: DRM device
> > + * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
> >   * @num_modes: number of different TV formats (modes) supported
> >   * @modes: array of pointers to strings containing name of each format
> >   *
> > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> >   * 0 on success or a negative error code on failure.
> >   */
> >  int drm_mode_create_tv_properties(struct drm_device *dev,
> > +				  unsigned int supported_tv_norms,
> >  				  unsigned int num_modes,
> >  				  const char * const modes[])
> >  {
> > +	static const struct drm_prop_enum_list tv_norm_values[] = {
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> > +	};
> >  	struct drm_property *tv_selector;
> >  	struct drm_property *tv_subconnector;
> > +	struct drm_property *tv_norm;
> >  	unsigned int i;
> >  
> >  	if (dev->mode_config.tv_select_subconnector_property)
> > @@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
> >  	if (drm_mode_create_tv_margin_properties(dev))
> >  		goto nomem;
> >  
> > +	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
> > +					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
> > +					   supported_tv_norms);
> 
> I expected this to be an enum, why a bitmask? Userspace can set multiple
> bits in a bitmask.

I went for a bitmask since it allowed to report the capabilities of a
driver, but I just realised that you can do that with an enum too, like
we do for color encodings.

I'll switch for an enum, thanks!
Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 16.08.2022 10.26, skrev Maxime Ripard:
> Hi,
> 
> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> The TV mode property has been around for a while now to select and get the
>>> current TV mode output on an analog TV connector.
>>>
>>> Despite that property name being generic, its content isn't and has been
>>> driver-specific which makes it hard to build any generic behaviour on top
>>> of it, both in kernel and user-space.
>>>
>>> Let's create a new bitmask tv norm property, that can contain any of the
>>> analog TV standards currently supported by kernel drivers. Each driver can
>>> then pass in a bitmask of the modes it supports.
>>>
>>> We'll then be able to phase out the older tv mode property.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>
>>
>> Please also update Documentation/gpu/kms-properties.csv
>>
>> Requirements for adding a new property is found in
>> Documentation/gpu/drm-kms.rst
> 
> I knew this was going to be raised at some point, so I'm glad it's that
> early :)
> 
> I really don't know what to do there. If we stick by our usual rules,
> then we can't have any of that work merged.
> 
> However, I think the status quo is not really satisfactory either.
> Indeed, we have a property, that doesn't follow those requirements
> either, with a driver-specific content, and that stands in the way of
> fixes and further improvements at both the core framework and driver
> levels.
> 
> So having that new property still seems like a net improvement at the
> driver, framework and uAPI levels, even if it's not entirely following
> the requirements we have in place.
> 
> Even more so since, realistically, those kind of interfaces will never
> get any new development on the user-space side of things, it's
> considered by everyone as legacy.
> 
> This also is something we need to support at some point if we want to
> completely deprecate the fbdev drivers and provide decent alternatives
> in KMS.
> 
> So yeah, strictly speaking, we would not qualify for our requirements
> there. I still think we have a strong case for an exception though.
> 

Which requirements would that be? The only one I can see is the
documentation and maybe an IGT test.

Noralf.

>>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
>>> index c06d0639d552..d7ff6c644c2f 100644
>>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>>> @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>>>  		state->tv.margins.bottom = val;
>>>  	} else if (property == config->tv_mode_property) {
>>>  		state->tv.mode = val;
>>> +	} else if (property == config->tv_norm_property) {
>>> +		state->tv.norm = val;
>>>  	} else if (property == config->tv_brightness_property) {
>>>  		state->tv.brightness = val;
>>>  	} else if (property == config->tv_contrast_property) {
>>> @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>>>  		*val = state->tv.margins.bottom;
>>>  	} else if (property == config->tv_mode_property) {
>>>  		*val = state->tv.mode;
>>> +	} else if (property == config->tv_norm_property) {
>>> +		*val = state->tv.norm;
>>>  	} else if (property == config->tv_brightness_property) {
>>>  		*val = state->tv.brightness;
>>>  	} else if (property == config->tv_contrast_property) {
>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>> index e3142c8142b3..68a4e47f85a9 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>>>  /**
>>>   * drm_mode_create_tv_properties - create TV specific connector properties
>>>   * @dev: DRM device
>>> + * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
>>>   * @num_modes: number of different TV formats (modes) supported
>>>   * @modes: array of pointers to strings containing name of each format
>>>   *
>>> @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>>>   * 0 on success or a negative error code on failure.
>>>   */
>>>  int drm_mode_create_tv_properties(struct drm_device *dev,
>>> +				  unsigned int supported_tv_norms,
>>>  				  unsigned int num_modes,
>>>  				  const char * const modes[])
>>>  {
>>> +	static const struct drm_prop_enum_list tv_norm_values[] = {
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
>>> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
>>> +	};
>>>  	struct drm_property *tv_selector;
>>>  	struct drm_property *tv_subconnector;
>>> +	struct drm_property *tv_norm;
>>>  	unsigned int i;
>>>  
>>>  	if (dev->mode_config.tv_select_subconnector_property)
>>> @@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>>>  	if (drm_mode_create_tv_margin_properties(dev))
>>>  		goto nomem;
>>>  
>>> +	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
>>> +					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
>>> +					   supported_tv_norms);
>>
>> I expected this to be an enum, why a bitmask? Userspace can set multiple
>> bits in a bitmask.
> 
> I went for a bitmask since it allowed to report the capabilities of a
> driver, but I just realised that you can do that with an enum too, like
> we do for color encodings.
> 
> I'll switch for an enum, thanks!
> Maxime

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> 
> 
> Den 16.08.2022 10.26, skrev Maxime Ripard:
> > Hi,
> > 
> > On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> >> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>> The TV mode property has been around for a while now to select and get the
> >>> current TV mode output on an analog TV connector.
> >>>
> >>> Despite that property name being generic, its content isn't and has been
> >>> driver-specific which makes it hard to build any generic behaviour on top
> >>> of it, both in kernel and user-space.
> >>>
> >>> Let's create a new bitmask tv norm property, that can contain any of the
> >>> analog TV standards currently supported by kernel drivers. Each driver can
> >>> then pass in a bitmask of the modes it supports.
> >>>
> >>> We'll then be able to phase out the older tv mode property.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>
> >>
> >> Please also update Documentation/gpu/kms-properties.csv
> >>
> >> Requirements for adding a new property is found in
> >> Documentation/gpu/drm-kms.rst
> > 
> > I knew this was going to be raised at some point, so I'm glad it's that
> > early :)
> > 
> > I really don't know what to do there. If we stick by our usual rules,
> > then we can't have any of that work merged.
> > 
> > However, I think the status quo is not really satisfactory either.
> > Indeed, we have a property, that doesn't follow those requirements
> > either, with a driver-specific content, and that stands in the way of
> > fixes and further improvements at both the core framework and driver
> > levels.
> > 
> > So having that new property still seems like a net improvement at the
> > driver, framework and uAPI levels, even if it's not entirely following
> > the requirements we have in place.
> > 
> > Even more so since, realistically, those kind of interfaces will never
> > get any new development on the user-space side of things, it's
> > considered by everyone as legacy.
> > 
> > This also is something we need to support at some point if we want to
> > completely deprecate the fbdev drivers and provide decent alternatives
> > in KMS.
> > 
> > So yeah, strictly speaking, we would not qualify for our requirements
> > there. I still think we have a strong case for an exception though.
>
> Which requirements would that be? The only one I can see is the
> documentation and maybe an IGT test.

This is the one I had in mind
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

I overlooked yours obviously, so I'll update my patches to fix it.

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 16.08.2022 11.49, skrev Maxime Ripard:
> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 16.08.2022 10.26, skrev Maxime Ripard:
>>> Hi,
>>>
>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>> The TV mode property has been around for a while now to select and get the
>>>>> current TV mode output on an analog TV connector.
>>>>>
>>>>> Despite that property name being generic, its content isn't and has been
>>>>> driver-specific which makes it hard to build any generic behaviour on top
>>>>> of it, both in kernel and user-space.
>>>>>
>>>>> Let's create a new bitmask tv norm property, that can contain any of the
>>>>> analog TV standards currently supported by kernel drivers. Each driver can
>>>>> then pass in a bitmask of the modes it supports.
>>>>>
>>>>> We'll then be able to phase out the older tv mode property.
>>>>>
>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>
>>>>
>>>> Please also update Documentation/gpu/kms-properties.csv
>>>>
>>>> Requirements for adding a new property is found in
>>>> Documentation/gpu/drm-kms.rst
>>>
>>> I knew this was going to be raised at some point, so I'm glad it's that
>>> early :)
>>>
>>> I really don't know what to do there. If we stick by our usual rules,
>>> then we can't have any of that work merged.
>>>
>>> However, I think the status quo is not really satisfactory either.
>>> Indeed, we have a property, that doesn't follow those requirements
>>> either, with a driver-specific content, and that stands in the way of
>>> fixes and further improvements at both the core framework and driver
>>> levels.
>>>
>>> So having that new property still seems like a net improvement at the
>>> driver, framework and uAPI levels, even if it's not entirely following
>>> the requirements we have in place.
>>>
>>> Even more so since, realistically, those kind of interfaces will never
>>> get any new development on the user-space side of things, it's
>>> considered by everyone as legacy.
>>>
>>> This also is something we need to support at some point if we want to
>>> completely deprecate the fbdev drivers and provide decent alternatives
>>> in KMS.
>>>
>>> So yeah, strictly speaking, we would not qualify for our requirements
>>> there. I still think we have a strong case for an exception though.
>>
>> Which requirements would that be? The only one I can see is the
>> documentation and maybe an IGT test.
> 
> This is the one I had in mind
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> 

Oh right, I had forgotten about that one.

One benefit of having a userspace implementation is that it increases
the chance of widespread adoption having a working implementation to
look at. I don't think the reason tv.mode is not used anywhere (that I
know of) is because the driver picks the enum values resulting in no
standard names. It's a niche thing and way down on the todo list.
nouveau and ch7006 has a tv_norm module parameter which certainly
doesn't help in moving people/projects over to the DRM property
(downstream rpi also has it now).

mpv[1] is a commandline media player that after a quick look might be a
candidate for implementing the property without too much effort.

How do you test the property? I've used modetest but I can only change
to a tv.mode that matches the current display mode. I can't switch from
ntsc to pal for instance.

I have tried changing mode on rpi-5.15 (which I will switch to for the
gud gadget), but I always end up with flip timeouts when changing the value:

$ cat /proc/cpuinfo | grep Model
Model           : Raspberry Pi 4 Model B Rev 1.1
$ uname -a
Linux pi4t 5.15.56-v7l+ #1575 SMP Fri Jul 22 20:29:46 BST 2022 armv7l
GNU/Linux
$ sudo dmesg -C
$ modetest -M vc4 -s 45:720x480i -w 45:mode:1
setting mode 720x480i-29.97Hz on connectors 45, crtc 73
failed to set gamma: Function not implemented

$ dmesg
$ modetest -M vc4 -s 45:720x480i -w 45:mode:0
setting mode 720x480i-29.97Hz on connectors 45, crtc 73
failed to set gamma: Function not implemented

$ dmesg
[   95.193059] [drm:drm_atomic_helper_wait_for_flip_done
[drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out
[  105.433112] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[  105.433519] [drm:drm_atomic_helper_wait_for_dependencies
[drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] commit wait timed out
[  115.673095] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[  115.673498] [drm:drm_atomic_helper_wait_for_dependencies
[drm_kms_helper]] *ERROR* [PLANE:63:plane-1] commit wait timed out
[  125.913106] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[  125.913510] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
[  136.153411] [drm:drm_atomic_helper_wait_for_flip_done
[drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out

I doesn't help to reload vc4, I have to reboot to get it working again.
I get this when reloading:
[  776.799784] vc4_vec fec13000.vec: Unbalanced pm_runtime_enable!

I know this was working in rpi-5.10 on the Pi Zero (Pi4 tvout using vc4
did not work at all when I tried).


Noralf.

[1] https://mpv.io/
    https://github.com/mpv-player/mpv/blob/master/video/out/drm_common.c
    https://github.com/mpv-player/mpv/blob/master/video/out/drm_atomic.c

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
> Den 16.08.2022 11.49, skrev Maxime Ripard:
> > On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> >> Den 16.08.2022 10.26, skrev Maxime Ripard:
> >>> Hi,
> >>>
> >>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> >>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>>>> The TV mode property has been around for a while now to select and get the
> >>>>> current TV mode output on an analog TV connector.
> >>>>>
> >>>>> Despite that property name being generic, its content isn't and has been
> >>>>> driver-specific which makes it hard to build any generic behaviour on top
> >>>>> of it, both in kernel and user-space.
> >>>>>
> >>>>> Let's create a new bitmask tv norm property, that can contain any of the
> >>>>> analog TV standards currently supported by kernel drivers. Each driver can
> >>>>> then pass in a bitmask of the modes it supports.
> >>>>>
> >>>>> We'll then be able to phase out the older tv mode property.
> >>>>>
> >>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>
> >>>>
> >>>> Please also update Documentation/gpu/kms-properties.csv
> >>>>
> >>>> Requirements for adding a new property is found in
> >>>> Documentation/gpu/drm-kms.rst
> >>>
> >>> I knew this was going to be raised at some point, so I'm glad it's that
> >>> early :)
> >>>
> >>> I really don't know what to do there. If we stick by our usual rules,
> >>> then we can't have any of that work merged.
> >>>
> >>> However, I think the status quo is not really satisfactory either.
> >>> Indeed, we have a property, that doesn't follow those requirements
> >>> either, with a driver-specific content, and that stands in the way of
> >>> fixes and further improvements at both the core framework and driver
> >>> levels.
> >>>
> >>> So having that new property still seems like a net improvement at the
> >>> driver, framework and uAPI levels, even if it's not entirely following
> >>> the requirements we have in place.
> >>>
> >>> Even more so since, realistically, those kind of interfaces will never
> >>> get any new development on the user-space side of things, it's
> >>> considered by everyone as legacy.
> >>>
> >>> This also is something we need to support at some point if we want to
> >>> completely deprecate the fbdev drivers and provide decent alternatives
> >>> in KMS.
> >>>
> >>> So yeah, strictly speaking, we would not qualify for our requirements
> >>> there. I still think we have a strong case for an exception though.
> >>
> >> Which requirements would that be? The only one I can see is the
> >> documentation and maybe an IGT test.
> > 
> > This is the one I had in mind
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> > 
> 
> Oh right, I had forgotten about that one.
> 
> One benefit of having a userspace implementation is that it increases
> the chance of widespread adoption having a working implementation to
> look at. I don't think the reason tv.mode is not used anywhere (that I
> know of) is because the driver picks the enum values resulting in no
> standard names.

It probably doesn't help, but it's not what I was implying.

> It's a niche thing and way down on the todo list. nouveau and ch7006
> has a tv_norm module parameter which certainly doesn't help in moving
> people/projects over to the DRM property (downstream rpi also has it
> now).

Yeah, the RPi version is part of the reason I started working on this.
We should also consider the named modes used by vc4 and sun4i. All these
ad-hoc solutions are limited and (I think) come from the fact that we
don't have a solution easy enough to use for drivers (and to discover).

nouveau, ch7006, i915 and vc4 are using the tv.mode property for
example, but sun4i and meson don't.

sun4i relies on named modes to reimplement TV modes, but meson doesn't
at all.

And then nouveau has that extra command line parameter to set it up at
boot time.

It doesn't really make much sense to me, when all drivers have very
similar needs, that none of them behave in the same way. And I think the
non-standard property is partly to blame for this, since without some
generic content we can't share code.

This is what this series is about: every driver having similar
capabilities and as trivially as possible.

> mpv[1] is a commandline media player that after a quick look might be a
> candidate for implementing the property without too much effort.

Kodi might be another one. I can try to hack something around, but I'm
really skeptical about whether a PR would be merged or not.

> How do you test the property? I've used modetest but I can only change
> to a tv.mode that matches the current display mode. I can't switch from
> ntsc to pal for instance.

Yep, if you want to change from PAL to NTSC, it will require a new mode.

> I have tried changing mode on rpi-5.15 (which I will switch to for the
> gud gadget), but I always end up with flip timeouts when changing the value:
> 
> $ cat /proc/cpuinfo | grep Model
> Model           : Raspberry Pi 4 Model B Rev 1.1
> $ uname -a
> Linux pi4t 5.15.56-v7l+ #1575 SMP Fri Jul 22 20:29:46 BST 2022 armv7l
> GNU/Linux
> $ sudo dmesg -C
> $ modetest -M vc4 -s 45:720x480i -w 45:mode:1
> setting mode 720x480i-29.97Hz on connectors 45, crtc 73
> failed to set gamma: Function not implemented
> 
> $ dmesg
> $ modetest -M vc4 -s 45:720x480i -w 45:mode:0
> setting mode 720x480i-29.97Hz on connectors 45, crtc 73
> failed to set gamma: Function not implemented
> 
> $ dmesg
> [   95.193059] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out
> [  105.433112] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> [  105.433519] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] commit wait timed out
> [  115.673095] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> [  115.673498] [drm:drm_atomic_helper_wait_for_dependencies
> [drm_kms_helper]] *ERROR* [PLANE:63:plane-1] commit wait timed out
> [  125.913106] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
> [  125.913510] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
> [  136.153411] [drm:drm_atomic_helper_wait_for_flip_done
> [drm_kms_helper]] *ERROR* [CRTC:73:crtc-1] flip_done timed out

So I haven't tested with 5.15, but I tested it with this series and it
was working well, both with the compat layer and the new property.

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 17.08.2022 13.46, skrev Maxime Ripard:
> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>> Den 16.08.2022 11.49, skrev Maxime Ripard:
>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
>>>>> Hi,
>>>>>
>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>>>> The TV mode property has been around for a while now to select and get the
>>>>>>> current TV mode output on an analog TV connector.
>>>>>>>
>>>>>>> Despite that property name being generic, its content isn't and has been
>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
>>>>>>> of it, both in kernel and user-space.
>>>>>>>
>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
>>>>>>> then pass in a bitmask of the modes it supports.
>>>>>>>
>>>>>>> We'll then be able to phase out the older tv mode property.
>>>>>>>
>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>>>
>>>>>>
>>>>>> Please also update Documentation/gpu/kms-properties.csv
>>>>>>
>>>>>> Requirements for adding a new property is found in
>>>>>> Documentation/gpu/drm-kms.rst
>>>>>
>>>>> I knew this was going to be raised at some point, so I'm glad it's that
>>>>> early :)
>>>>>
>>>>> I really don't know what to do there. If we stick by our usual rules,
>>>>> then we can't have any of that work merged.
>>>>>
>>>>> However, I think the status quo is not really satisfactory either.
>>>>> Indeed, we have a property, that doesn't follow those requirements
>>>>> either, with a driver-specific content, and that stands in the way of
>>>>> fixes and further improvements at both the core framework and driver
>>>>> levels.
>>>>>
>>>>> So having that new property still seems like a net improvement at the
>>>>> driver, framework and uAPI levels, even if it's not entirely following
>>>>> the requirements we have in place.
>>>>>
>>>>> Even more so since, realistically, those kind of interfaces will never
>>>>> get any new development on the user-space side of things, it's
>>>>> considered by everyone as legacy.
>>>>>
>>>>> This also is something we need to support at some point if we want to
>>>>> completely deprecate the fbdev drivers and provide decent alternatives
>>>>> in KMS.
>>>>>
>>>>> So yeah, strictly speaking, we would not qualify for our requirements
>>>>> there. I still think we have a strong case for an exception though.
>>>>
>>>> Which requirements would that be? The only one I can see is the
>>>> documentation and maybe an IGT test.
>>>
>>> This is the one I had in mind
>>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>>
>>
>> Oh right, I had forgotten about that one.
>>
>> One benefit of having a userspace implementation is that it increases
>> the chance of widespread adoption having a working implementation to
>> look at. I don't think the reason tv.mode is not used anywhere (that I
>> know of) is because the driver picks the enum values resulting in no
>> standard names.
> 
> It probably doesn't help, but it's not what I was implying.
> 
>> It's a niche thing and way down on the todo list. nouveau and ch7006
>> has a tv_norm module parameter which certainly doesn't help in moving
>> people/projects over to the DRM property (downstream rpi also has it
>> now).
> 
> Yeah, the RPi version is part of the reason I started working on this.
> We should also consider the named modes used by vc4 and sun4i. All these
> ad-hoc solutions are limited and (I think) come from the fact that we
> don't have a solution easy enough to use for drivers (and to discover).
> 
> nouveau, ch7006, i915 and vc4 are using the tv.mode property for
> example, but sun4i and meson don't.
> 
> sun4i relies on named modes to reimplement TV modes, but meson doesn't
> at all.
> 
> And then nouveau has that extra command line parameter to set it up at
> boot time.
> 
> It doesn't really make much sense to me, when all drivers have very
> similar needs, that none of them behave in the same way. And I think the
> non-standard property is partly to blame for this, since without some
> generic content we can't share code.
> 
> This is what this series is about: every driver having similar
> capabilities and as trivially as possible.
> 
>> mpv[1] is a commandline media player that after a quick look might be a
>> candidate for implementing the property without too much effort.
> 
> Kodi might be another one. I can try to hack something around, but I'm
> really skeptical about whether a PR would be merged or not.
> 

You can ask first before wasting time ofc.

But this baffles me, if you don't think projects like Kodi which is TV
centered want this, what kind of projects do you think want to use this
property?

>> How do you test the property? I've used modetest but I can only change
>> to a tv.mode that matches the current display mode. I can't switch from
>> ntsc to pal for instance.
> 
> Yep, if you want to change from PAL to NTSC, it will require a new mode.
> 

So userspace has to check tv.mode first and then create a display mode
the driver will accept if switching to a different display mode is
necessary? In other words, userspace can't discover from the kernel
which display modes a certain tv.mode/norm provides before it is
selected? If so, maybe libdrm should have some function(s) to deal with
switching between modes that require a different display mode since
knowledge about which display modes a tv.mode supports is needed before
hand.

Noralf.

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 17.08.2022 15.11, skrev Noralf Trønnes:
> 
> 
> Den 17.08.2022 13.46, skrev Maxime Ripard:
>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
>>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
>>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>>>>> The TV mode property has been around for a while now to select and get the
>>>>>>>> current TV mode output on an analog TV connector.
>>>>>>>>
>>>>>>>> Despite that property name being generic, its content isn't and has been
>>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
>>>>>>>> of it, both in kernel and user-space.
>>>>>>>>
>>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
>>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
>>>>>>>> then pass in a bitmask of the modes it supports.
>>>>>>>>
>>>>>>>> We'll then be able to phase out the older tv mode property.
>>>>>>>>
>>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>>>>

>>> How do you test the property? I've used modetest but I can only change
>>> to a tv.mode that matches the current display mode. I can't switch from
>>> ntsc to pal for instance.
>>
>> Yep, if you want to change from PAL to NTSC, it will require a new mode.
>>
> 
> So userspace has to check tv.mode first and then create a display mode
> the driver will accept if switching to a different display mode is
> necessary? In other words, userspace can't discover from the kernel
> which display modes a certain tv.mode/norm provides before it is
> selected? If so, maybe libdrm should have some function(s) to deal with
> switching between modes that require a different display mode since
> knowledge about which display modes a tv.mode supports is needed before
> hand.
> 

I haven't used vc4 on Pi4 in mainline before and have finally gotten it
to work.

I see that the connector reports 2 modes that together fit all tv.norms
so userspace doesn't have to contruct a display mode, but it does need
to know which display mode belongs to a certain tv.norm.

When I try to use modetest I'm unable to set a mode:

pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i
setting mode 720x480i-29.97Hz on connectors 45, crtc 68
failed to set mode: Function not implemented

The errno is misleading, modetest does a drmModeDirtyFB before checking
the error returned by drmModeSetCrtc.

Setting the property succeeds, but the modeset still fails:

pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2
setting mode 720x480i-29.97Hz on connectors 45, crtc 68
failed to set mode: Function not implemented

pi@pi4t:~ $ modetest -M vc4 -c
        37 tv norm:
                flags: bitmask
                values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10
PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000
                value: 2

Here's the log, can you see if there's anything obvious in there:
https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858

Noralf.

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 18.08.2022 01.23, skrev Noralf Trønnes:
> 
> 
> Den 17.08.2022 15.11, skrev Noralf Trønnes:
>>
>>
>> Den 17.08.2022 13.46, skrev Maxime Ripard:
>>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
>>>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
>>>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>>>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>>>>>> The TV mode property has been around for a while now to select and get the
>>>>>>>>> current TV mode output on an analog TV connector.
>>>>>>>>>
>>>>>>>>> Despite that property name being generic, its content isn't and has been
>>>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
>>>>>>>>> of it, both in kernel and user-space.
>>>>>>>>>
>>>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
>>>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
>>>>>>>>> then pass in a bitmask of the modes it supports.
>>>>>>>>>
>>>>>>>>> We'll then be able to phase out the older tv mode property.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>>>>>
> 
>>>> How do you test the property? I've used modetest but I can only change
>>>> to a tv.mode that matches the current display mode. I can't switch from
>>>> ntsc to pal for instance.
>>>
>>> Yep, if you want to change from PAL to NTSC, it will require a new mode.
>>>
>>
>> So userspace has to check tv.mode first and then create a display mode
>> the driver will accept if switching to a different display mode is
>> necessary? In other words, userspace can't discover from the kernel
>> which display modes a certain tv.mode/norm provides before it is
>> selected? If so, maybe libdrm should have some function(s) to deal with
>> switching between modes that require a different display mode since
>> knowledge about which display modes a tv.mode supports is needed before
>> hand.
>>
> 
> I haven't used vc4 on Pi4 in mainline before and have finally gotten it
> to work.
> 
> I see that the connector reports 2 modes that together fit all tv.norms
> so userspace doesn't have to contruct a display mode, but it does need
> to know which display mode belongs to a certain tv.norm.
> 
> When I try to use modetest I'm unable to set a mode:
> 
> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i
> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> failed to set mode: Function not implemented
> 
> The errno is misleading, modetest does a drmModeDirtyFB before checking
> the error returned by drmModeSetCrtc.
> 
> Setting the property succeeds, but the modeset still fails:
> 
> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2
> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> failed to set mode: Function not implemented
> 
> pi@pi4t:~ $ modetest -M vc4 -c
>         37 tv norm:
>                 flags: bitmask
>                 values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10
> PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000
>                 value: 2
> 
> Here's the log, can you see if there's anything obvious in there:
> https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858
> 

I'm one step closer as I now have fbcon working, I had forgotten to add
enable_tvout=1 and I had disable_fw_kms_setup=1 which disables the
video= mode on the kernel commandline.

modetest still fails though, after alot of printk sprinkling, I've
tracked it down to the drm_mode_equal test in
drm_atomic_helper_connector_tv_check(). The aspect ratios differ:

[   61.336295] drm_atomic_helper_connector_tv_check:
mode->picture_aspect_ratio=1
[   61.336301] drm_atomic_helper_connector_tv_check:
&crtc_state->mode->picture_aspect_ratio=0

Noralf.

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Thu, Aug 18, 2022 at 05:01:38PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 18.08.2022 01.23, skrev Noralf Trønnes:
> > 
> > 
> > Den 17.08.2022 15.11, skrev Noralf Trønnes:
> >>
> >>
> >> Den 17.08.2022 13.46, skrev Maxime Ripard:
> >>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
> >>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
> >>>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> >>>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> >>>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>>>>>>>> The TV mode property has been around for a while now to select and get the
> >>>>>>>>> current TV mode output on an analog TV connector.
> >>>>>>>>>
> >>>>>>>>> Despite that property name being generic, its content isn't and has been
> >>>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
> >>>>>>>>> of it, both in kernel and user-space.
> >>>>>>>>>
> >>>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
> >>>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
> >>>>>>>>> then pass in a bitmask of the modes it supports.
> >>>>>>>>>
> >>>>>>>>> We'll then be able to phase out the older tv mode property.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>>>>>
> > 
> >>>> How do you test the property? I've used modetest but I can only change
> >>>> to a tv.mode that matches the current display mode. I can't switch from
> >>>> ntsc to pal for instance.
> >>>
> >>> Yep, if you want to change from PAL to NTSC, it will require a new mode.
> >>>
> >>
> >> So userspace has to check tv.mode first and then create a display mode
> >> the driver will accept if switching to a different display mode is
> >> necessary? In other words, userspace can't discover from the kernel
> >> which display modes a certain tv.mode/norm provides before it is
> >> selected? If so, maybe libdrm should have some function(s) to deal with
> >> switching between modes that require a different display mode since
> >> knowledge about which display modes a tv.mode supports is needed before
> >> hand.
> >>
> > 
> > I haven't used vc4 on Pi4 in mainline before and have finally gotten it
> > to work.
> > 
> > I see that the connector reports 2 modes that together fit all tv.norms
> > so userspace doesn't have to contruct a display mode, but it does need
> > to know which display mode belongs to a certain tv.norm.
> > 
> > When I try to use modetest I'm unable to set a mode:
> > 
> > pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i
> > setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> > failed to set mode: Function not implemented
> > 
> > The errno is misleading, modetest does a drmModeDirtyFB before checking
> > the error returned by drmModeSetCrtc.
> > 
> > Setting the property succeeds, but the modeset still fails:
> > 
> > pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2
> > setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> > failed to set mode: Function not implemented
> > 
> > pi@pi4t:~ $ modetest -M vc4 -c
> >         37 tv norm:
> >                 flags: bitmask
> >                 values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10
> > PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000
> >                 value: 2
> > 
> > Here's the log, can you see if there's anything obvious in there:
> > https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858
> > 
> 
> I'm one step closer as I now have fbcon working, I had forgotten to add
> enable_tvout=1 and I had disable_fw_kms_setup=1 which disables the
> video= mode on the kernel commandline.
> 
> modetest still fails though, after alot of printk sprinkling, I've
> tracked it down to the drm_mode_equal test in
> drm_atomic_helper_connector_tv_check(). The aspect ratios differ:
> 
> [   61.336295] drm_atomic_helper_connector_tv_check:
> mode->picture_aspect_ratio=1
> [   61.336301] drm_atomic_helper_connector_tv_check:
> &crtc_state->mode->picture_aspect_ratio=0

I haven't seen this when testing, but I'll have a look, thanks!
Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 18.08.2022 17.31, skrev Maxime Ripard:
> On Thu, Aug 18, 2022 at 05:01:38PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 18.08.2022 01.23, skrev Noralf Trønnes:
>>>
>>>
>>> Den 17.08.2022 15.11, skrev Noralf Trønnes:
>>>>
>>>>
>>>> Den 17.08.2022 13.46, skrev Maxime Ripard:
>>>>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
>>>>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
>>>>>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
>>>>>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
>>>>>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>>>>>>>> The TV mode property has been around for a while now to select and get the
>>>>>>>>>>> current TV mode output on an analog TV connector.
>>>>>>>>>>>
>>>>>>>>>>> Despite that property name being generic, its content isn't and has been
>>>>>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
>>>>>>>>>>> of it, both in kernel and user-space.
>>>>>>>>>>>
>>>>>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
>>>>>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
>>>>>>>>>>> then pass in a bitmask of the modes it supports.
>>>>>>>>>>>
>>>>>>>>>>> We'll then be able to phase out the older tv mode property.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>>>>>>>
>>>
>>>>>> How do you test the property? I've used modetest but I can only change
>>>>>> to a tv.mode that matches the current display mode. I can't switch from
>>>>>> ntsc to pal for instance.
>>>>>
>>>>> Yep, if you want to change from PAL to NTSC, it will require a new mode.
>>>>>
>>>>
>>>> So userspace has to check tv.mode first and then create a display mode
>>>> the driver will accept if switching to a different display mode is
>>>> necessary? In other words, userspace can't discover from the kernel
>>>> which display modes a certain tv.mode/norm provides before it is
>>>> selected? If so, maybe libdrm should have some function(s) to deal with
>>>> switching between modes that require a different display mode since
>>>> knowledge about which display modes a tv.mode supports is needed before
>>>> hand.
>>>>
>>>
>>> I haven't used vc4 on Pi4 in mainline before and have finally gotten it
>>> to work.
>>>
>>> I see that the connector reports 2 modes that together fit all tv.norms
>>> so userspace doesn't have to contruct a display mode, but it does need
>>> to know which display mode belongs to a certain tv.norm.
>>>
>>> When I try to use modetest I'm unable to set a mode:
>>>
>>> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i
>>> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
>>> failed to set mode: Function not implemented
>>>
>>> The errno is misleading, modetest does a drmModeDirtyFB before checking
>>> the error returned by drmModeSetCrtc.
>>>
>>> Setting the property succeeds, but the modeset still fails:
>>>
>>> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2
>>> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
>>> failed to set mode: Function not implemented
>>>
>>> pi@pi4t:~ $ modetest -M vc4 -c
>>>         37 tv norm:
>>>                 flags: bitmask
>>>                 values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10
>>> PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000
>>>                 value: 2
>>>
>>> Here's the log, can you see if there's anything obvious in there:
>>> https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858
>>>
>>
>> I'm one step closer as I now have fbcon working, I had forgotten to add
>> enable_tvout=1 and I had disable_fw_kms_setup=1 which disables the
>> video= mode on the kernel commandline.
>>
>> modetest still fails though, after alot of printk sprinkling, I've
>> tracked it down to the drm_mode_equal test in
>> drm_atomic_helper_connector_tv_check(). The aspect ratios differ:
>>
>> [   61.336295] drm_atomic_helper_connector_tv_check:
>> mode->picture_aspect_ratio=1
>> [   61.336301] drm_atomic_helper_connector_tv_check:
>> &crtc_state->mode->picture_aspect_ratio=0
> 
> I haven't seen this when testing, but I'll have a look, thanks!

I have found the cause, the kernel strips off the aspect ratio in
drm_mode_getconnector() if drm_file->aspect_ratio_allowed is false. So I
think the drm_mode_equal() test needs to be relaxed for
legacy/non-atomic userspace to work.

If I use modetest with atomic commit (-a) it works as is, having the
drm_mode_equal() test:

$ modetest -M vc4 -a -P 61@68:720x480 -s 45:720x480i

I have a problem because the board hangs, either right away or after I
press <enter> to quit modetest.

I often get this, sometimes after 10s of seconds:

[  136.822963] Unhandled fault: asynchronous external abort (0x1211) at
0x00000000
...
[  137.248496]  bcm2711_get_temp [bcm2711_thermal] from
thermal_zone_get_temp+0x54/0x74

Unloading bcm2711_thermal didn't help, in that case I got nothing, so
the problem lies elsewhere.
I have even tried with a fresh SD image and a fresh kernel, but it
didn't help.

I can switch from NTSC to PAL like this (but it still crashes):

$ modetest -M vc4 -a -w 45:"tv norm":16 -P 61@68:720x576 -s 45:720x576i

I had to patch modetest for that to work:

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 8ff6c80d..accd2166 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -2188,12 +2187,13 @@ int main(int argc, char **argv)
 	dump_resource(&dev, planes);
 	dump_resource(&dev, framebuffers);

+	if (dev.use_atomic)
+		dev.req = drmModeAtomicAlloc();
+
 	for (i = 0; i < prop_count; ++i)
 		set_property(&dev, &prop_args[i]);

 	if (dev.use_atomic) {
-		dev.req = drmModeAtomicAlloc();
-
 		if (set_preferred || (count && plane_count)) {
 			uint64_t cap = 0;


I use a composite to USB adapter to see the output:
https://www.adafruit.com/product/4715

Noralf.

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Sun, Aug 21, 2022 at 01:43:40PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 18.08.2022 17.31, skrev Maxime Ripard:
> > On Thu, Aug 18, 2022 at 05:01:38PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 18.08.2022 01.23, skrev Noralf Trønnes:
> >>>
> >>>
> >>> Den 17.08.2022 15.11, skrev Noralf Trønnes:
> >>>>
> >>>>
> >>>> Den 17.08.2022 13.46, skrev Maxime Ripard:
> >>>>> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
> >>>>>> Den 16.08.2022 11.49, skrev Maxime Ripard:
> >>>>>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> >>>>>>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> >>>>>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>>>>>>>>>> The TV mode property has been around for a while now to select and get the
> >>>>>>>>>>> current TV mode output on an analog TV connector.
> >>>>>>>>>>>
> >>>>>>>>>>> Despite that property name being generic, its content isn't and has been
> >>>>>>>>>>> driver-specific which makes it hard to build any generic behaviour on top
> >>>>>>>>>>> of it, both in kernel and user-space.
> >>>>>>>>>>>
> >>>>>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
> >>>>>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
> >>>>>>>>>>> then pass in a bitmask of the modes it supports.
> >>>>>>>>>>>
> >>>>>>>>>>> We'll then be able to phase out the older tv mode property.
> >>>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>>>>>>>
> >>>
> >>>>>> How do you test the property? I've used modetest but I can only change
> >>>>>> to a tv.mode that matches the current display mode. I can't switch from
> >>>>>> ntsc to pal for instance.
> >>>>>
> >>>>> Yep, if you want to change from PAL to NTSC, it will require a new mode.
> >>>>>
> >>>>
> >>>> So userspace has to check tv.mode first and then create a display mode
> >>>> the driver will accept if switching to a different display mode is
> >>>> necessary? In other words, userspace can't discover from the kernel
> >>>> which display modes a certain tv.mode/norm provides before it is
> >>>> selected? If so, maybe libdrm should have some function(s) to deal with
> >>>> switching between modes that require a different display mode since
> >>>> knowledge about which display modes a tv.mode supports is needed before
> >>>> hand.
> >>>>
> >>>
> >>> I haven't used vc4 on Pi4 in mainline before and have finally gotten it
> >>> to work.
> >>>
> >>> I see that the connector reports 2 modes that together fit all tv.norms
> >>> so userspace doesn't have to contruct a display mode, but it does need
> >>> to know which display mode belongs to a certain tv.norm.
> >>>
> >>> When I try to use modetest I'm unable to set a mode:
> >>>
> >>> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i
> >>> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> >>> failed to set mode: Function not implemented
> >>>
> >>> The errno is misleading, modetest does a drmModeDirtyFB before checking
> >>> the error returned by drmModeSetCrtc.
> >>>
> >>> Setting the property succeeds, but the modeset still fails:
> >>>
> >>> pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2
> >>> setting mode 720x480i-29.97Hz on connectors 45, crtc 68
> >>> failed to set mode: Function not implemented
> >>>
> >>> pi@pi4t:~ $ modetest -M vc4 -c
> >>>         37 tv norm:
> >>>                 flags: bitmask
> >>>                 values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10
> >>> PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000
> >>>                 value: 2
> >>>
> >>> Here's the log, can you see if there's anything obvious in there:
> >>> https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858
> >>>
> >>
> >> I'm one step closer as I now have fbcon working, I had forgotten to add
> >> enable_tvout=1 and I had disable_fw_kms_setup=1 which disables the
> >> video= mode on the kernel commandline.
> >>
> >> modetest still fails though, after alot of printk sprinkling, I've
> >> tracked it down to the drm_mode_equal test in
> >> drm_atomic_helper_connector_tv_check(). The aspect ratios differ:
> >>
> >> [   61.336295] drm_atomic_helper_connector_tv_check:
> >> mode->picture_aspect_ratio=1
> >> [   61.336301] drm_atomic_helper_connector_tv_check:
> >> &crtc_state->mode->picture_aspect_ratio=0
> > 
> > I haven't seen this when testing, but I'll have a look, thanks!
> 
> I have found the cause, the kernel strips off the aspect ratio in
> drm_mode_getconnector() if drm_file->aspect_ratio_allowed is false. So I
> think the drm_mode_equal() test needs to be relaxed for
> legacy/non-atomic userspace to work.

Geert suggested I removed it too, so this check is gone now.

> If I use modetest with atomic commit (-a) it works as is, having the
> drm_mode_equal() test:
> 
> $ modetest -M vc4 -a -P 61@68:720x480 -s 45:720x480i
> 
> I have a problem because the board hangs, either right away or after I
> press <enter> to quit modetest.
> 
> I often get this, sometimes after 10s of seconds:
> 
> [  136.822963] Unhandled fault: asynchronous external abort (0x1211) at
> 0x00000000
> ...
> [  137.248496]  bcm2711_get_temp [bcm2711_thermal] from
> thermal_zone_get_temp+0x54/0x74
> 
> Unloading bcm2711_thermal didn't help, in that case I got nothing, so
> the problem lies elsewhere.
> I have even tried with a fresh SD image and a fresh kernel, but it
> didn't help.

I got this too when working from current next (next-20220825) but it
doesn't seem to happen on drm-misc-next-2022-08-20-1, so it's probably
something unrelated?

> I can switch from NTSC to PAL like this (but it still crashes):
> 
> $ modetest -M vc4 -a -w 45:"tv norm":16 -P 61@68:720x576 -s 45:720x576i

I've tested with my current branch, and it work fine with modetest, I'll
put my commands in my next iteration so that you can compare?

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 03:11:56PM +0200, Noralf Trønnes wrote:
> Den 17.08.2022 13.46, skrev Maxime Ripard:
> > On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote:
> >> Den 16.08.2022 11.49, skrev Maxime Ripard:
> >>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote:
> >>>> Den 16.08.2022 10.26, skrev Maxime Ripard:
> >>>>> Hi,
> >>>>>
> >>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote:
> >>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>>>>>> The TV mode property has been around for a while now to select and get the
> >>>>>>> current TV mode output on an analog TV connector.
> >>>>>>>
> >>>>>>> Despite that property name being generic, its content isn't and has been
> >>>>>>> driver-specific which makes it hard to build any generic behaviour on top
> >>>>>>> of it, both in kernel and user-space.
> >>>>>>>
> >>>>>>> Let's create a new bitmask tv norm property, that can contain any of the
> >>>>>>> analog TV standards currently supported by kernel drivers. Each driver can
> >>>>>>> then pass in a bitmask of the modes it supports.
> >>>>>>>
> >>>>>>> We'll then be able to phase out the older tv mode property.
> >>>>>>>
> >>>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>>>>>
> >>>>>>
> >>>>>> Please also update Documentation/gpu/kms-properties.csv
> >>>>>>
> >>>>>> Requirements for adding a new property is found in
> >>>>>> Documentation/gpu/drm-kms.rst
> >>>>>
> >>>>> I knew this was going to be raised at some point, so I'm glad it's that
> >>>>> early :)
> >>>>>
> >>>>> I really don't know what to do there. If we stick by our usual rules,
> >>>>> then we can't have any of that work merged.
> >>>>>
> >>>>> However, I think the status quo is not really satisfactory either.
> >>>>> Indeed, we have a property, that doesn't follow those requirements
> >>>>> either, with a driver-specific content, and that stands in the way of
> >>>>> fixes and further improvements at both the core framework and driver
> >>>>> levels.
> >>>>>
> >>>>> So having that new property still seems like a net improvement at the
> >>>>> driver, framework and uAPI levels, even if it's not entirely following
> >>>>> the requirements we have in place.
> >>>>>
> >>>>> Even more so since, realistically, those kind of interfaces will never
> >>>>> get any new development on the user-space side of things, it's
> >>>>> considered by everyone as legacy.
> >>>>>
> >>>>> This also is something we need to support at some point if we want to
> >>>>> completely deprecate the fbdev drivers and provide decent alternatives
> >>>>> in KMS.
> >>>>>
> >>>>> So yeah, strictly speaking, we would not qualify for our requirements
> >>>>> there. I still think we have a strong case for an exception though.
> >>>>
> >>>> Which requirements would that be? The only one I can see is the
> >>>> documentation and maybe an IGT test.
> >>>
> >>> This is the one I had in mind
> >>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >>>
> >>
> >> Oh right, I had forgotten about that one.
> >>
> >> One benefit of having a userspace implementation is that it increases
> >> the chance of widespread adoption having a working implementation to
> >> look at. I don't think the reason tv.mode is not used anywhere (that I
> >> know of) is because the driver picks the enum values resulting in no
> >> standard names.
> > 
> > It probably doesn't help, but it's not what I was implying.
> > 
> >> It's a niche thing and way down on the todo list. nouveau and ch7006
> >> has a tv_norm module parameter which certainly doesn't help in moving
> >> people/projects over to the DRM property (downstream rpi also has it
> >> now).
> > 
> > Yeah, the RPi version is part of the reason I started working on this.
> > We should also consider the named modes used by vc4 and sun4i. All these
> > ad-hoc solutions are limited and (I think) come from the fact that we
> > don't have a solution easy enough to use for drivers (and to discover).
> > 
> > nouveau, ch7006, i915 and vc4 are using the tv.mode property for
> > example, but sun4i and meson don't.
> > 
> > sun4i relies on named modes to reimplement TV modes, but meson doesn't
> > at all.
> > 
> > And then nouveau has that extra command line parameter to set it up at
> > boot time.
> > 
> > It doesn't really make much sense to me, when all drivers have very
> > similar needs, that none of them behave in the same way. And I think the
> > non-standard property is partly to blame for this, since without some
> > generic content we can't share code.
> > 
> > This is what this series is about: every driver having similar
> > capabilities and as trivially as possible.
> > 
> >> mpv[1] is a commandline media player that after a quick look might be a
> >> candidate for implementing the property without too much effort.
> > 
> > Kodi might be another one. I can try to hack something around, but I'm
> > really skeptical about whether a PR would be merged or not.
> > 
> 
> You can ask first before wasting time ofc.

Yep, will do.

> But this baffles me, if you don't think projects like Kodi which is TV
> centered want this, what kind of projects do you think want to use this
> property?

I mean, at this point it's really a consolidation of stuff we have
scattered around the kernel tree, in order to clean up that mess, and
not add more hacks.

And it allows the current effort to move the remaining fbdev drivers
into KMS.

As far as userspace is concerned, I don't know who is still using it
or cares today.

I still believe that refactoring is beneficial though, if only to make
one more nail in fbdev's coffin.

> >> How do you test the property? I've used modetest but I can only change
> >> to a tv.mode that matches the current display mode. I can't switch from
> >> ntsc to pal for instance.
> > 
> > Yep, if you want to change from PAL to NTSC, it will require a new mode.
>
> So userspace has to check tv.mode first and then create a display mode
> the driver will accept if switching to a different display mode is
> necessary?

I'd expect drivers to expose both 576i and 480i (that's what vc4 and
sun4i are doing), so the userspace can pick them up.

> In other words, userspace can't discover from the kernel which display
> modes a certain tv.mode/norm provides before it is selected?

It's kind of the other way around in my mind, but the userspace would
have to figure out what display mode can use what tv mode, yes.

Even more so since Geert and I are discussing to allow continuous modes,
so we would allow to have modes with the same (active) resolution but a
different tv mode.

> If so, maybe libdrm should have some function(s) to deal with
> switching between modes that require a different display mode since
> knowledge about which display modes a tv.mode supports is needed
> before hand.

I'm not sure what you mean here, sorry. It's fairly easy to update a
property and the mode with atomic?

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
>
> Let's create a new bitmask tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports.
>
> We'll then be able to phase out the older tv mode property.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Thanks for your patch!

> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>   * 0 on success or a negative error code on failure.
>   */
>  int drm_mode_create_tv_properties(struct drm_device *dev,
> +                                 unsigned int supported_tv_norms,
>                                   unsigned int num_modes,
>                                   const char * const modes[])
>  {
> +       static const struct drm_prop_enum_list tv_norm_values[] = {
> +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },

The above are analog standards, with a variable horizontal resolution.

> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> +               { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },

The above are digital standards, with a fixed resolution.

You seem to have missed "hd1080p"?

In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
handle them through "@<refresh>".  The latter would impact "[PATCH v1
09/35] drm/modes: Move named modes parsing to a separate function", as
currently a named mode and a refresh rate can't be specified both.

As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
command-line option" uses a separate "tv_mode" option, and not the main
mode name, I think you want to add them here.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

Hi Geert,

On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> >   * 0 on success or a negative error code on failure.
> >   */
> >  int drm_mode_create_tv_properties(struct drm_device *dev,
> > +                                 unsigned int supported_tv_norms,
> >                                   unsigned int num_modes,
> >                                   const char * const modes[])
> >  {
> > +       static const struct drm_prop_enum_list tv_norm_values[] = {
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> 
> The above are analog standards, with a variable horizontal resolution.
> 
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> 
> The above are digital standards, with a fixed resolution.

Are they?

It's not clear to me from looking at nouveau, but I was under the
impression that they were modes for a component output, so CEA 770.3. I
don't have the spec though, so I can't check.

> You seem to have missed "hd1080p"?

Nobody is using it. If we ever have a driver that uses it I think we can
add it.

> In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.

It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
50Hz, 720p at 60Hz, 1080i at 30Hz.

> Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> handle them through "@<refresh>".  The latter would impact "[PATCH v1
> 09/35] drm/modes: Move named modes parsing to a separate function", as
> currently a named mode and a refresh rate can't be specified both.

I think the former would make more sense. It simplifies a bit the
parser, and we're going to use a named mode anyway.

> As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> command-line option" uses a separate "tv_mode" option, and not the main
> mode name, I think you want to add them here.

It's a separate story I think, we could have a named mode hd720p50,
which would be equivalent to 1280x720,tv_mode=hd720p

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > >   * 0 on success or a negative error code on failure.
> > >   */
> > >  int drm_mode_create_tv_properties(struct drm_device *dev,
> > > +                                 unsigned int supported_tv_norms,
> > >                                   unsigned int num_modes,
> > >                                   const char * const modes[])
> > >  {
> > > +       static const struct drm_prop_enum_list tv_norm_values[] = {
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> >
> > The above are analog standards, with a variable horizontal resolution.
> >
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> >
> > The above are digital standards, with a fixed resolution.
>
> Are they?
>
> It's not clear to me from looking at nouveau, but I was under the
> impression that they were modes for a component output, so CEA 770.3. I
> don't have the spec though, so I can't check.

Oh right, I forgot about analog HD over component, where you can use
other pixel clocks than in the digital standard.

> > You seem to have missed "hd1080p"?
>
> Nobody is using it. If we ever have a driver that uses it I think we can
> add it.

The PS3 supports 1080p over component
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html

> > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
>
> It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> 50Hz, 720p at 60Hz, 1080i at 30Hz.

PS3 supports both 50 and 60 Hz (same link above).

> > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > currently a named mode and a refresh rate can't be specified both.
>
> I think the former would make more sense. It simplifies a bit the
> parser, and we're going to use a named mode anyway.
>
> > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > command-line option" uses a separate "tv_mode" option, and not the main
> > mode name, I think you want to add them here.
>
> It's a separate story I think, we could have a named mode hd720p50,
> which would be equivalent to 1280x720,tv_mode=hd720p

So where's the field rate in "1280x720,tv_mode=hd720p"?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Tue, Aug 16, 2022 at 03:29:07PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > > >   * 0 on success or a negative error code on failure.
> > > >   */
> > > >  int drm_mode_create_tv_properties(struct drm_device *dev,
> > > > +                                 unsigned int supported_tv_norms,
> > > >                                   unsigned int num_modes,
> > > >                                   const char * const modes[])
> > > >  {
> > > > +       static const struct drm_prop_enum_list tv_norm_values[] = {
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> > >
> > > The above are analog standards, with a variable horizontal resolution.
> > >
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> > >
> > > The above are digital standards, with a fixed resolution.
> >
> > Are they?
> >
> > It's not clear to me from looking at nouveau, but I was under the
> > impression that they were modes for a component output, so CEA 770.3. I
> > don't have the spec though, so I can't check.
> 
> Oh right, I forgot about analog HD over component, where you can use
> other pixel clocks than in the digital standard.
> 
> > > You seem to have missed "hd1080p"?
> >
> > Nobody is using it. If we ever have a driver that uses it I think we can
> > add it.
> 
> The PS3 supports 1080p over component
> https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html

Yeah, and iirc the Xbox360 did too, but what I meant by nobody is using
it is that there's no driver using it currently.

> > > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
> >
> > It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> > 50Hz, 720p at 60Hz, 1080i at 30Hz.
> 
> PS3 supports both 50 and 60 Hz (same link above).

I'm probably wary on this, but I'd rather stay at feature parity for
this series. There's already plenty of occasion to screw up something
that I'd rather not introduce new stuff I haven't been able to test :)

Provided we can easily extend it to support these additional features of
course :)

> > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > currently a named mode and a refresh rate can't be specified both.
> >
> > I think the former would make more sense. It simplifies a bit the
> > parser, and we're going to use a named mode anyway.
> >
> > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > command-line option" uses a separate "tv_mode" option, and not the main
> > > mode name, I think you want to add them here.
> >
> > It's a separate story I think, we could have a named mode hd720p50,
> > which would be equivalent to 1280x720,tv_mode=hd720p
> 
> So where's the field rate in "1280x720,tv_mode=hd720p"?

Yeah, sorry I meant 1280x720@50,tv_mode=hd720p

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Tue, Aug 16, 2022 at 4:11 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Tue, Aug 16, 2022 at 03:29:07PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 3:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Fri, Aug 12, 2022 at 03:25:18PM +0200, Geert Uytterhoeven wrote:
> > > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > > @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
> > > > >   * 0 on success or a negative error code on failure.
> > > > >   */
> > > > >  int drm_mode_create_tv_properties(struct drm_device *dev,
> > > > > +                                 unsigned int supported_tv_norms,
> > > > >                                   unsigned int num_modes,
> > > > >                                   const char * const modes[])
> > > > >  {
> > > > > +       static const struct drm_prop_enum_list tv_norm_values[] = {
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> > > >
> > > > The above are analog standards, with a variable horizontal resolution.
> > > >
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> > > > > +               { __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> > > >
> > > > The above are digital standards, with a fixed resolution.
> > >
> > > Are they?
> > >
> > > It's not clear to me from looking at nouveau, but I was under the
> > > impression that they were modes for a component output, so CEA 770.3. I
> > > don't have the spec though, so I can't check.
> >
> > Oh right, I forgot about analog HD over component, where you can use
> > other pixel clocks than in the digital standard.
> >
> > > > You seem to have missed "hd1080p"?
> > >
> > > Nobody is using it. If we ever have a driver that uses it I think we can
> > > add it.
> >
> > The PS3 supports 1080p over component
> > https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
>
> Yeah, and iirc the Xbox360 did too, but what I meant by nobody is using
> it is that there's no driver using it currently.

OK, it can be added later.

> > > > In addition, "hd720p", "hd080i", and "hd1080p" are available in both 50
> > > > and 60 (actually 59.94) Hz, while "hd1080p" can also use 24 or 25 Hz.
> > >
> > > It looks like nouveau only exposes modes for 480p at 59.94Hz, 576p at
> > > 50Hz, 720p at 60Hz, 1080i at 30Hz.
> >
> > PS3 supports both 50 and 60 Hz (same link above).
>
> I'm probably wary on this, but I'd rather stay at feature parity for
> this series. There's already plenty of occasion to screw up something
> that I'd rather not introduce new stuff I haven't been able to test :)
>
> Provided we can easily extend it to support these additional features of
> course :)
>
> > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > currently a named mode and a refresh rate can't be specified both.
> > >
> > > I think the former would make more sense. It simplifies a bit the
> > > parser, and we're going to use a named mode anyway.
> > >
> > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > mode name, I think you want to add them here.
> > >
> > > It's a separate story I think, we could have a named mode hd720p50,
> > > which would be equivalent to 1280x720,tv_mode=hd720p
> >
> > So where's the field rate in "1280x720,tv_mode=hd720p"?
>
> Yeah, sorry I meant 1280x720@50,tv_mode=hd720p

Above you said "I think the former would make more sense", so that
should be "1280x720,tv_mode=hd720p50"?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > currently a named mode and a refresh rate can't be specified both.
> > > >
> > > > I think the former would make more sense. It simplifies a bit the
> > > > parser, and we're going to use a named mode anyway.
> > > >
> > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > mode name, I think you want to add them here.
> > > >
> > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > >
> > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> >
> > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> 
> Above you said "I think the former would make more sense", so that
> should be "1280x720,tv_mode=hd720p50"?

No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > >
> > > > > I think the former would make more sense. It simplifies a bit the
> > > > > parser, and we're going to use a named mode anyway.
> > > > >
> > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > mode name, I think you want to add them here.
> > > > >
> > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > >
> > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > >
> > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> >
> > Above you said "I think the former would make more sense", so that
> > should be "1280x720,tv_mode=hd720p50"?
>
> No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p

I disagree: hd720p50 and hd720p60 are different TV modes.
Treating them the same would be similar to treating unmodulated (e.g.
component) PAL-N (25 frames/s) and PAL-M (30 frames/s) the same.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

On Wed, Aug 17, 2022 at 9:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > >
> > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > parser, and we're going to use a named mode anyway.
> > > > > >
> > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > mode name, I think you want to add them here.
> > > > > >
> > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > >
> > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > >
> > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > >
> > > Above you said "I think the former would make more sense", so that
> > > should be "1280x720,tv_mode=hd720p50"?
> >
> > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
>
> I disagree: hd720p50 and hd720p60 are different TV modes.
> Treating them the same would be similar to treating unmodulated (e.g.
> component) PAL-N (25 frames/s) and PAL-M (30 frames/s) the same.

IIRC from my PS3 -Linux days, not all HD(-Ready) TVs supported both
hd720p50 and hd720p60.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > >
> > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > parser, and we're going to use a named mode anyway.
> > > > > >
> > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > mode name, I think you want to add them here.
> > > > > >
> > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > >
> > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > >
> > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > >
> > > Above you said "I think the former would make more sense", so that
> > > should be "1280x720,tv_mode=hd720p50"?
> >
> > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> 
> I disagree: hd720p50 and hd720p60 are different TV modes.

I agree, and I don't see how that command-line doesn't express that?

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > >
> > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > >
> > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > mode name, I think you want to add them here.
> > > > > > >
> > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > >
> > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > >
> > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > >
> > > > Above you said "I think the former would make more sense", so that
> > > > should be "1280x720,tv_mode=hd720p50"?
> > >
> > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> >
> > I disagree: hd720p50 and hd720p60 are different TV modes.
>
> I agree, and I don't see how that command-line doesn't express that?

Oh, I see what you mean: yes, it expresses that.
But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
where the TV mode specifies both number of lines and frame rate.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > >
> > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > >
> > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > mode name, I think you want to add them here.
> > > > > > > >
> > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > >
> > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > >
> > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > >
> > > > > Above you said "I think the former would make more sense", so that
> > > > > should be "1280x720,tv_mode=hd720p50"?
> > > >
> > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > >
> > > I disagree: hd720p50 and hd720p60 are different TV modes.
> >
> > I agree, and I don't see how that command-line doesn't express that?
> 
> Oh, I see what you mean: yes, it expresses that.
> But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> where the TV mode specifies both number of lines and frame rate.

Only if we're using a named mode, and naming is hard :)

Honestly, I'd be inclined to drop the hd* for now from this series. I
don't have a hardware to test it with, for some we don't even have
drivers that could implement these modes, we don't have a spec to work
from, it looks like a recipe for failure :)

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > >
> > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > >
> > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > >
> > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > >
> > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > >
> > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > >
> > > > > > Above you said "I think the former would make more sense", so that
> > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > >
> > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > >
> > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > >
> > > I agree, and I don't see how that command-line doesn't express that?
> >
> > Oh, I see what you mean: yes, it expresses that.
> > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > where the TV mode specifies both number of lines and frame rate.
>
> Only if we're using a named mode, and naming is hard :)

That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
mode with 525 lines and 30 frames/s.

> Honestly, I'd be inclined to drop the hd* for now from this series. I
> don't have a hardware to test it with, for some we don't even have
> drivers that could implement these modes, we don't have a spec to work
> from, it looks like a recipe for failure :)

OK.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > >
> > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > >
> > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > >
> > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > >
> > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > >
> > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > >
> > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > >
> > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > >
> > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > >
> > > > I agree, and I don't see how that command-line doesn't express that?
> > >
> > > Oh, I see what you mean: yes, it expresses that.
> > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > where the TV mode specifies both number of lines and frame rate.
> >
> > Only if we're using a named mode, and naming is hard :)
> 
> That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> mode with 525 lines and 30 frames/s.

In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:

https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > >
> > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > >
> > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > >
> > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > >
> > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > >
> > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > >
> > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > >
> > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > >
> > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > >
> > > > > I agree, and I don't see how that command-line doesn't express that?
> > > >
> > > > Oh, I see what you mean: yes, it expresses that.
> > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > where the TV mode specifies both number of lines and frame rate.
> > >
> > > Only if we're using a named mode, and naming is hard :)
> >
> > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > mode with 525 lines and 30 frames/s.
>
> In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
>
> https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/

It would become supported once the ideas from thread "[PATCH v1 04/35]
drm/modes: Introduce 480i and 576i modes" are implemented...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > > >
> > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > > >
> > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > > >
> > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > > >
> > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > > >
> > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > > >
> > > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > > >
> > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > > >
> > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > > >
> > > > > > I agree, and I don't see how that command-line doesn't express that?
> > > > >
> > > > > Oh, I see what you mean: yes, it expresses that.
> > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > > where the TV mode specifies both number of lines and frame rate.
> > > >
> > > > Only if we're using a named mode, and naming is hard :)
> > >
> > > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > > mode with 525 lines and 30 frames/s.
> >
> > In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
> >
> > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/
> 
> It would become supported once the ideas from thread "[PATCH v1 04/35]
> drm/modes: Introduce 480i and 576i modes" are implemented...

Indeed, but I'm still not sure what your concern is here.
"640x480,tv_mode=PAL-N" and "640x480,tv_mode=PAL-M" are both fairly
obvious.

You were initially saying that you had concern over the inconsistency of
NTSC/PAL/SECAM where the TV mode would specify a number of lines and
frame rate, but hd720p50 also specifies a number of line and frame rate?

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > > > >
> > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > > > >
> > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > > > >
> > > > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > > > >
> > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > > > >
> > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > > > >
> > > > > > > I agree, and I don't see how that command-line doesn't express that?
> > > > > >
> > > > > > Oh, I see what you mean: yes, it expresses that.
> > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > > > where the TV mode specifies both number of lines and frame rate.
> > > > >
> > > > > Only if we're using a named mode, and naming is hard :)
> > > >
> > > > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > > > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > > > mode with 525 lines and 30 frames/s.
> > >
> > > In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
> > >
> > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/
> >
> > It would become supported once the ideas from thread "[PATCH v1 04/35]
> > drm/modes: Introduce 480i and 576i modes" are implemented...
>
> Indeed, but I'm still not sure what your concern is here.
> "640x480,tv_mode=PAL-N" and "640x480,tv_mode=PAL-M" are both fairly
> obvious.
>
> You were initially saying that you had concern over the inconsistency of
> NTSC/PAL/SECAM where the TV mode would specify a number of lines and
> frame rate, but hd720p50 also specifies a number of line and frame rate?

My concern is that you want to call the TV mode "hd720p", which
does not dictate the frame rate.
I would like to have both "720p50" and "720p60", as they do dictate
the frame rate, like all the non-hd modes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > > > > >
> > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > > > > >
> > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > > > > >
> > > > > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > > > > >
> > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > > > > >
> > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > > > > >
> > > > > > > > I agree, and I don't see how that command-line doesn't express that?
> > > > > > >
> > > > > > > Oh, I see what you mean: yes, it expresses that.
> > > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > > > > where the TV mode specifies both number of lines and frame rate.
> > > > > >
> > > > > > Only if we're using a named mode, and naming is hard :)
> > > > >
> > > > > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > > > > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > > > > mode with 525 lines and 30 frames/s.
> > > >
> > > > In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
> > > >
> > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/
> > >
> > > It would become supported once the ideas from thread "[PATCH v1 04/35]
> > > drm/modes: Introduce 480i and 576i modes" are implemented...
> >
> > Indeed, but I'm still not sure what your concern is here.
> > "640x480,tv_mode=PAL-N" and "640x480,tv_mode=PAL-M" are both fairly
> > obvious.
> >
> > You were initially saying that you had concern over the inconsistency of
> > NTSC/PAL/SECAM where the TV mode would specify a number of lines and
> > frame rate, but hd720p50 also specifies a number of line and frame rate?
> 
> My concern is that you want to call the TV mode "hd720p", which
> does not dictate the frame rate.
> I would like to have both "720p50" and "720p60", as they do dictate
> the frame rate, like all the non-hd modes.

But they don't?

The refresh rate is part of the drm_display_mode, whereas that property
is metadata and entirely separate from the display mode.

You can even change it without changing the mode at all

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Aug 18, 2022 at 5:34 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > > > > > >
> > > > > > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > > > > > >
> > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > > > > > >
> > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > > > > > >
> > > > > > > > > I agree, and I don't see how that command-line doesn't express that?
> > > > > > > >
> > > > > > > > Oh, I see what you mean: yes, it expresses that.
> > > > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > > > > > where the TV mode specifies both number of lines and frame rate.
> > > > > > >
> > > > > > > Only if we're using a named mode, and naming is hard :)
> > > > > >
> > > > > > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > > > > > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > > > > > mode with 525 lines and 30 frames/s.
> > > > >
> > > > > In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
> > > > >
> > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/
> > > >
> > > > It would become supported once the ideas from thread "[PATCH v1 04/35]
> > > > drm/modes: Introduce 480i and 576i modes" are implemented...
> > >
> > > Indeed, but I'm still not sure what your concern is here.
> > > "640x480,tv_mode=PAL-N" and "640x480,tv_mode=PAL-M" are both fairly
> > > obvious.
> > >
> > > You were initially saying that you had concern over the inconsistency of
> > > NTSC/PAL/SECAM where the TV mode would specify a number of lines and
> > > frame rate, but hd720p50 also specifies a number of line and frame rate?
> >
> > My concern is that you want to call the TV mode "hd720p", which
> > does not dictate the frame rate.
> > I would like to have both "720p50" and "720p60", as they do dictate
> > the frame rate, like all the non-hd modes.
>
> But they don't?
>
> The refresh rate is part of the drm_display_mode, whereas that property
> is metadata and entirely separate from the display mode.
>
> You can even change it without changing the mode at all

Yes, the refresh rate is part of drm_display_mode.  Vdisplay also
is, but that doesn't mean you can set it to e.g. 700 when using
"tv_mode=PAL-B". Some (combination of) parameters in drm_display_mode
are dictated by the tv_mode.

Perhaps the meaning of "tv_mode" should be clarified? What does it
really mean, and what parameters does it (not) constrain?

For e.g. "PAL-B", I know it's a mode with 625 lines and 30 frames/s
(60 fields/s).
For "hd720p" I know it is an analog mode with 750 lines, but it's still
ambiguous, as I don't know if it is the variant with 60 or 50 frames/s.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

Hi,

On Fri, Aug 19, 2022 at 11:35:42AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 18, 2022 at 5:34 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > On Thu, Aug 18, 2022 at 05:20:42PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 18, 2022 at 4:54 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > On Wed, Aug 17, 2022 at 04:04:24PM +0200, Geert Uytterhoeven wrote:
> > > > > On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > > > > > > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"), or
> > > > > > > > > > > > > > > > > handle them through "@<refresh>".  The latter would impact "[PATCH v1
> > > > > > > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate function", as
> > > > > > > > > > > > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > > > > > > > > > > > > command-line option" uses a separate "tv_mode" option, and not the main
> > > > > > > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > > > > > > >
> > > > > > > > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > > > > > > >
> > > > > > > > > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > > > > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > > > > > > >
> > > > > > > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > > > > > > >
> > > > > > > > > > I agree, and I don't see how that command-line doesn't express that?
> > > > > > > > >
> > > > > > > > > Oh, I see what you mean: yes, it expresses that.
> > > > > > > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > > > > > > where the TV mode specifies both number of lines and frame rate.
> > > > > > > >
> > > > > > > > Only if we're using a named mode, and naming is hard :)
> > > > > > >
> > > > > > > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > > > > > > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > > > > > > mode with 525 lines and 30 frames/s.
> > > > > >
> > > > > > In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
> > > > > >
> > > > > > https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722097@cerno.tech/
> > > > >
> > > > > It would become supported once the ideas from thread "[PATCH v1 04/35]
> > > > > drm/modes: Introduce 480i and 576i modes" are implemented...
> > > >
> > > > Indeed, but I'm still not sure what your concern is here.
> > > > "640x480,tv_mode=PAL-N" and "640x480,tv_mode=PAL-M" are both fairly
> > > > obvious.
> > > >
> > > > You were initially saying that you had concern over the inconsistency of
> > > > NTSC/PAL/SECAM where the TV mode would specify a number of lines and
> > > > frame rate, but hd720p50 also specifies a number of line and frame rate?
> > >
> > > My concern is that you want to call the TV mode "hd720p", which
> > > does not dictate the frame rate.
> > > I would like to have both "720p50" and "720p60", as they do dictate
> > > the frame rate, like all the non-hd modes.
> >
> > But they don't?
> >
> > The refresh rate is part of the drm_display_mode, whereas that property
> > is metadata and entirely separate from the display mode.
> >
> > You can even change it without changing the mode at all
> 
> Yes, the refresh rate is part of drm_display_mode.  Vdisplay also
> is, but that doesn't mean you can set it to e.g. 700 when using
> "tv_mode=PAL-B". Some (combination of) parameters in drm_display_mode
> are dictated by the tv_mode.

But the opposite is also true: PAL-B and SECAM-B would be two different
TV mode, but (could) have the same display mode.

There's no equivalence or implication in that relationship, except for a
smaller set of those parameters. But it's the entire display mode that
we should compare.

> Perhaps the meaning of "tv_mode" should be clarified? What does it
> really mean, and what parameters does it (not) constrain?

As far as I'm concerned, it's only about the encoding. We can check
after the fact that, say, you don't try to use a mode line with than 525
lines and some NTSC variant, but the mode has precedence over the
property.

> For e.g. "PAL-B", I know it's a mode with 625 lines and 30 frames/s
> (60 fields/s).
> For "hd720p" I know it is an analog mode with 750 lines, but it's still
> ambiguous, as I don't know if it is the variant with 60 or 50 frames/s.

As far as the TV mode property is concerned, it doesn't encode neither
whether it has 750 lines, nor the refresh rate.

If you're talking about a named mode, then yeah, it's basically an alias
for a mode + a property, so it does, but we can choose names that aren't
ambiguous.

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
> 
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
> 
> Let's create a new bitmask tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports.
> 
> We'll then be able to phase out the older tv mode property.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..d7ff6c644c2f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
>  		state->tv.margins.bottom = val;
>  	} else if (property == config->tv_mode_property) {
>  		state->tv.mode = val;
> +	} else if (property == config->tv_norm_property) {
> +		state->tv.norm = val;
>  	} else if (property == config->tv_brightness_property) {
>  		state->tv.brightness = val;
>  	} else if (property == config->tv_contrast_property) {
> @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
>  		*val = state->tv.margins.bottom;
>  	} else if (property == config->tv_mode_property) {
>  		*val = state->tv.mode;
> +	} else if (property == config->tv_norm_property) {
> +		*val = state->tv.norm;
>  	} else if (property == config->tv_brightness_property) {
>  		*val = state->tv.brightness;
>  	} else if (property == config->tv_contrast_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index e3142c8142b3..68a4e47f85a9 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1637,6 +1637,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>  /**
>   * drm_mode_create_tv_properties - create TV specific connector properties
>   * @dev: DRM device
> + * @supported_tv_norms: Bitmask of TV norms supported (See DRM_MODE_TV_NORM_*)
>   * @num_modes: number of different TV formats (modes) supported
>   * @modes: array of pointers to strings containing name of each format
>   *
> @@ -1649,11 +1650,40 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
>   * 0 on success or a negative error code on failure.
>   */
>  int drm_mode_create_tv_properties(struct drm_device *dev,
> +				  unsigned int supported_tv_norms,
>  				  unsigned int num_modes,
>  				  const char * const modes[])
>  {
> +	static const struct drm_prop_enum_list tv_norm_values[] = {
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_J) - 1, "NTSC-J" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_M) - 1, "NTSC-M" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_60) - 1, "PAL-60" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_B) - 1, "PAL-B" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_D) - 1, "PAL-D" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_G) - 1, "PAL-G" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_H) - 1, "PAL-H" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_I) - 1, "PAL-I" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_M) - 1, "PAL-M" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_N) - 1, "PAL-N" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_PAL_NC) - 1, "PAL-Nc" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_60) - 1, "SECAM-60" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_B) - 1, "SECAM-B" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_D) - 1, "SECAM-D" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_G) - 1, "SECAM-G" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K) - 1, "SECAM-K" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_K1) - 1, "SECAM-K1" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_SECAM_L) - 1, "SECAM-L" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480I) - 1, "hd480i" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD480P) - 1, "hd480p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576I) - 1, "hd576i" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD576P) - 1, "hd576p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD720P) - 1, "hd720p" },
> +		{ __builtin_ffs(DRM_MODE_TV_NORM_HD1080I) - 1, "hd1080i" },
> +	};
>  	struct drm_property *tv_selector;
>  	struct drm_property *tv_subconnector;
> +	struct drm_property *tv_norm;
>  	unsigned int i;
>  
>  	if (dev->mode_config.tv_select_subconnector_property)
> @@ -1686,6 +1716,13 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  	if (drm_mode_create_tv_margin_properties(dev))
>  		goto nomem;
>  
> +	tv_norm = drm_property_create_bitmask(dev, 0, "tv norm",
> +					   tv_norm_values, ARRAY_SIZE(tv_norm_values),
> +					   supported_tv_norms);
> +	if (!tv_norm)
> +		goto nomem;
> +	dev->mode_config.tv_norm_property = tv_norm;
> +
>  	dev->mode_config.tv_mode_property =
>  		drm_property_create(dev, DRM_MODE_PROP_ENUM,
>  				    "mode", num_modes);
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index 4a788c1c9058..457529e5d857 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -573,7 +573,9 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
>  	struct vc4_vec *vec;
>  	int ret;
>  
> -	ret = drm_mode_create_tv_properties(drm, ARRAY_SIZE(tv_mode_names),
> +	ret = drm_mode_create_tv_properties(drm,
> +					    0,
> +					    ARRAY_SIZE(tv_mode_names),
>  					    tv_mode_names);
>  	if (ret)
>  		return ret;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1e9996b33cc8..78275e68ff66 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -143,6 +143,32 @@ enum subpixel_order {
>  
>  };
>  
> +#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
> +#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
> +#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
> +#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
> +#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
> +#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
> +#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
> +#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
> +#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
> +#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
> +#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
> +#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
> +#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
> +#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
> +#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
> +#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
> +#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
> +#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
> +#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
> +#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
> +#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
> +#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
> +#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
> +#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
> +#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
> +

This is an area where DRM overlaps with v4l2, see:
- include/dt-bindings/display/sdtv-standards.h
- v4l2_norm_to_name()

Maybe we should follow suit, but if we do our own thing please mention
why in the commit message.

Noralf.

>  /**
>   * struct drm_scrambling: sink's scrambling support.
>   */
> @@ -687,6 +713,7 @@ struct drm_tv_connector_state {
>  	enum drm_mode_subconnector subconnector;
>  	struct drm_connector_tv_margins margins;
>  	unsigned int mode;
> +	unsigned int norm;
>  	unsigned int brightness;
>  	unsigned int contrast;
>  	unsigned int flicker_reduction;
> @@ -1779,6 +1806,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
>  
>  int drm_mode_create_tv_margin_properties(struct drm_device *dev);
>  int drm_mode_create_tv_properties(struct drm_device *dev,
> +				  unsigned int supported_tv_norms,
>  				  unsigned int num_modes,
>  				  const char * const modes[]);
>  void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 6b5e01295348..d9e79def8b92 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -704,6 +704,12 @@ struct drm_mode_config {
>  	 */
>  	struct drm_property *dp_subconnector_property;
>  
> +	/**
> +	 * @tv_norm_property: Optional TV property to select the TV
> +	 * standard output on the connector.
> +	 */
> +	struct drm_property *tv_norm_property;
> +
>  	/**
>  	 * @tv_subconnector_property: Optional TV property to differentiate
>  	 * between different TV connector types.
> 

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

Hi,

On Sat, Aug 20, 2022 at 10:12:46PM +0200, Noralf Trønnes wrote:
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 1e9996b33cc8..78275e68ff66 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -143,6 +143,32 @@ enum subpixel_order {
> >  
> >  };
> >  
> > +#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
> > +#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
> > +#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
> > +#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
> > +#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
> > +#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
> > +#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
> > +#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
> > +#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
> > +#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
> > +#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
> > +#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
> > +#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
> > +#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
> > +#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
> > +#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
> > +#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
> > +#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
> > +#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
> > +#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
> > +#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
> > +#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
> > +#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
> > +#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
> > +#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
> > +
> 
> This is an area where DRM overlaps with v4l2, see:
> - include/dt-bindings/display/sdtv-standards.h
> - v4l2_norm_to_name()
> 
> Maybe we should follow suit, but if we do our own thing please mention
> why in the commit message.

Are you suggesting that we'd share that definition with v4l2?

I've tried to share some code in the past between v4l2 and DRM, and it
got completely shut down so it's not something I'd like to try again, if
possible.

Maxime

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

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Noralf Trønnes]

Den 25.08.2022 15.44, skrev Maxime Ripard:
> Hi,
> 
> On Sat, Aug 20, 2022 at 10:12:46PM +0200, Noralf Trønnes wrote:
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index 1e9996b33cc8..78275e68ff66 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/include/drm/drm_connector.h
>>> @@ -143,6 +143,32 @@ enum subpixel_order {
>>>  
>>>  };
>>>  
>>> +#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
>>> +#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
>>> +#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
>>> +#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
>>> +#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
>>> +#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
>>> +#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
>>> +#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
>>> +#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
>>> +#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
>>> +#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
>>> +#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
>>> +#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
>>> +#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
>>> +#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
>>> +#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
>>> +#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
>>> +#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
>>> +#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
>>> +#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
>>> +#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
>>> +#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
>>> +#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
>>> +#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
>>> +#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
>>> +
>>
>> This is an area where DRM overlaps with v4l2, see:
>> - include/dt-bindings/display/sdtv-standards.h
>> - v4l2_norm_to_name()
>>
>> Maybe we should follow suit, but if we do our own thing please mention
>> why in the commit message.
> 
> Are you suggesting that we'd share that definition with v4l2?
> 

If possible, yes.

> I've tried to share some code in the past between v4l2 and DRM, and it
> got completely shut down so it's not something I'd like to try again, if
> possible.
> 

But that is a good enough reason not to do so. I just got the impression
from some of Laurent's emails a while back that there was some
cooperativ atmosphere, but I might be mistaken in my reading/understanding.

It is ofc possible to just copy the values from sdtv-standards.h, but I
see that hd* is missing from that list, so not sure if there's much
point if it has to be extended without changing the source.

We can at least use the names from v4l2_norm_to_name(), but from a quick
look it seems you already do so.

Noralf.

Re: [PATCH v1 05/35] drm/connector: Add TV standard property

[Maxime Ripard]

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

On Thu, Aug 25, 2022 at 05:13:29PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 25.08.2022 15.44, skrev Maxime Ripard:
> > Hi,
> > 
> > On Sat, Aug 20, 2022 at 10:12:46PM +0200, Noralf Trønnes wrote:
> >>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> >>> index 1e9996b33cc8..78275e68ff66 100644
> >>> --- a/include/drm/drm_connector.h
> >>> +++ b/include/drm/drm_connector.h
> >>> @@ -143,6 +143,32 @@ enum subpixel_order {
> >>>  
> >>>  };
> >>>  
> >>> +#define DRM_MODE_TV_NORM_NTSC_443	(1 << 0)
> >>> +#define DRM_MODE_TV_NORM_NTSC_J		(1 << 1)
> >>> +#define DRM_MODE_TV_NORM_NTSC_M		(1 << 2)
> >>> +#define DRM_MODE_TV_NORM_PAL_60		(1 << 3)
> >>> +#define DRM_MODE_TV_NORM_PAL_B		(1 << 4)
> >>> +#define DRM_MODE_TV_NORM_PAL_D		(1 << 5)
> >>> +#define DRM_MODE_TV_NORM_PAL_G		(1 << 6)
> >>> +#define DRM_MODE_TV_NORM_PAL_H		(1 << 7)
> >>> +#define DRM_MODE_TV_NORM_PAL_I		(1 << 8)
> >>> +#define DRM_MODE_TV_NORM_PAL_M		(1 << 9)
> >>> +#define DRM_MODE_TV_NORM_PAL_N		(1 << 10)
> >>> +#define DRM_MODE_TV_NORM_PAL_NC		(1 << 11)
> >>> +#define DRM_MODE_TV_NORM_SECAM_60	(1 << 12)
> >>> +#define DRM_MODE_TV_NORM_SECAM_B	(1 << 13)
> >>> +#define DRM_MODE_TV_NORM_SECAM_D	(1 << 14)
> >>> +#define DRM_MODE_TV_NORM_SECAM_G	(1 << 15)
> >>> +#define DRM_MODE_TV_NORM_SECAM_K	(1 << 16)
> >>> +#define DRM_MODE_TV_NORM_SECAM_K1	(1 << 17)
> >>> +#define DRM_MODE_TV_NORM_SECAM_L	(1 << 18)
> >>> +#define DRM_MODE_TV_NORM_HD480I		(1 << 19)
> >>> +#define DRM_MODE_TV_NORM_HD480P		(1 << 20)
> >>> +#define DRM_MODE_TV_NORM_HD576I		(1 << 21)
> >>> +#define DRM_MODE_TV_NORM_HD576P		(1 << 22)
> >>> +#define DRM_MODE_TV_NORM_HD720P		(1 << 23)
> >>> +#define DRM_MODE_TV_NORM_HD1080I	(1 << 24)
> >>> +
> >>
> >> This is an area where DRM overlaps with v4l2, see:
> >> - include/dt-bindings/display/sdtv-standards.h
> >> - v4l2_norm_to_name()
> >>
> >> Maybe we should follow suit, but if we do our own thing please mention
> >> why in the commit message.
> > 
> > Are you suggesting that we'd share that definition with v4l2?
> > 
> 
> If possible, yes.
> 
> > I've tried to share some code in the past between v4l2 and DRM, and it
> > got completely shut down so it's not something I'd like to try again, if
> > possible.
> > 
> 
> But that is a good enough reason not to do so. I just got the impression
> from some of Laurent's emails a while back that there was some
> cooperativ atmosphere, but I might be mistaken in my reading/understanding.

Here's the original thread:
https://lore.kernel.org/lkml/cover.8ec406bf8f4f097e9dc909d5aac466556822f592.1555487650.git-series.maxime.ripard@bootlin.com/

It ended up stalling completely, without any will from either DRM or
v4l2 to get this through. So I will not work on anything like that until
both maintainership teams have expressed that it's something they
actually want.

> It is ofc possible to just copy the values from sdtv-standards.h, but I
> see that hd* is missing from that list, so not sure if there's much
> point if it has to be extended without changing the source.

HD formats were dropped, so it's not a big deal. However, we are missing
a few formats, but that were never used by either nouveau, i915 or any
other driver. I'm not sure it's worth adding at that point, and we can
always extend it later.

Maxime

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

[PATCH v1 06/35] drm/connector: Only register TV mode property if present

[Maxime Ripard]

The drm_create_tv_properties() will create the TV mode property
unconditionally.

However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 68a4e47f85a9..d73a68764b6e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1684,7 +1684,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 	struct drm_property *tv_selector;
 	struct drm_property *tv_subconnector;
 	struct drm_property *tv_norm;
-	unsigned int i;
 
 	if (dev->mode_config.tv_select_subconnector_property)
 		return 0;
@@ -1723,15 +1722,19 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 		goto nomem;
 	dev->mode_config.tv_norm_property = tv_norm;
 
-	dev->mode_config.tv_mode_property =
-		drm_property_create(dev, DRM_MODE_PROP_ENUM,
-				    "mode", num_modes);
-	if (!dev->mode_config.tv_mode_property)
-		goto nomem;
+	if (num_modes) {
+		unsigned int i;
 
-	for (i = 0; i < num_modes; i++)
-		drm_property_add_enum(dev->mode_config.tv_mode_property,
-				      i, modes[i]);
+		dev->mode_config.tv_mode_property =
+			drm_property_create(dev, DRM_MODE_PROP_ENUM,
+					    "mode", num_modes);
+		if (!dev->mode_config.tv_mode_property)
+			goto nomem;
+
+		for (i = 0; i < num_modes; i++)
+			drm_property_add_enum(dev->mode_config.tv_mode_property,
+					      i, modes[i]);
+	}
 
 	dev->mode_config.tv_brightness_property =
 		drm_property_create_range(dev, 0, "brightness", 0, 100);

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 06/35] drm/connector: Only register TV mode property if present

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> The drm_create_tv_properties() will create the TV mode property
> unconditionally.
> 
> However, since we'll gradually phase it out, let's register it only if we
> have a list passed as an argument. This will make the transition easier.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

I don't understand why this makes the transition easier, but if you
think so:

Acked-by: Noralf Trønnes <noralf@tronnes.org>

> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 68a4e47f85a9..d73a68764b6e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1684,7 +1684,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  	struct drm_property *tv_selector;
>  	struct drm_property *tv_subconnector;
>  	struct drm_property *tv_norm;
> -	unsigned int i;
>  
>  	if (dev->mode_config.tv_select_subconnector_property)
>  		return 0;
> @@ -1723,15 +1722,19 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
>  		goto nomem;
>  	dev->mode_config.tv_norm_property = tv_norm;
>  
> -	dev->mode_config.tv_mode_property =
> -		drm_property_create(dev, DRM_MODE_PROP_ENUM,
> -				    "mode", num_modes);
> -	if (!dev->mode_config.tv_mode_property)
> -		goto nomem;
> +	if (num_modes) {
> +		unsigned int i;
>  
> -	for (i = 0; i < num_modes; i++)
> -		drm_property_add_enum(dev->mode_config.tv_mode_property,
> -				      i, modes[i]);
> +		dev->mode_config.tv_mode_property =
> +			drm_property_create(dev, DRM_MODE_PROP_ENUM,
> +					    "mode", num_modes);
> +		if (!dev->mode_config.tv_mode_property)
> +			goto nomem;
> +
> +		for (i = 0; i < num_modes; i++)
> +			drm_property_add_enum(dev->mode_config.tv_mode_property,
> +					      i, modes[i]);
> +	}
>  
>  	dev->mode_config.tv_brightness_property =
>  		drm_property_create_range(dev, 0, "brightness", 0, 100);
> 

Re: [PATCH v1 06/35] drm/connector: Only register TV mode property if present

[Maxime Ripard]

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

Hi,

On Mon, Aug 08, 2022 at 02:49:08PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.34, skrev Maxime Ripard:
> > The drm_create_tv_properties() will create the TV mode property
> > unconditionally.
> > 
> > However, since we'll gradually phase it out, let's register it only if we
> > have a list passed as an argument. This will make the transition easier.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> 
> I don't understand why this makes the transition easier, but if you
> think so:

So the basic idea behind this series was to introduce the new property,
gradually convert the old drivers to the new one, and finally remove the
old one.

In order to keep the backward compatibility, we need to add to the
drivers some custom get/set_property hook to expose the old property and
fill the new one if needed.

That means that each driver would have to create the old property, which
will conflict with that code

Maxime

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

Re: [PATCH v1 06/35] drm/connector: Only register TV mode property if present

[Noralf Trønnes]

Den 15.08.2022 12.40, skrev Maxime Ripard:
> Hi,
> 
> On Mon, Aug 08, 2022 at 02:49:08PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> The drm_create_tv_properties() will create the TV mode property
>>> unconditionally.
>>>
>>> However, since we'll gradually phase it out, let's register it only if we
>>> have a list passed as an argument. This will make the transition easier.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>
>>
>> I don't understand why this makes the transition easier, but if you
>> think so:
> 
> So the basic idea behind this series was to introduce the new property,
> gradually convert the old drivers to the new one, and finally remove the
> old one.
> 
> In order to keep the backward compatibility, we need to add to the
> drivers some custom get/set_property hook to expose the old property and
> fill the new one if needed.
> 
> That means that each driver would have to create the old property, which
> will conflict with that code
> 

Got it.

Noralf.

[PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options

[Maxime Ripard]

Some video= options might have a value that contains a dash. However, the
command line parsing mode considers all dashes as the separator between the
mode and the bpp count.

Let's rework the parsing code a bit to only consider a dash as the bpp
separator if it before a comma, the options separator.

A follow-up patch will add a unit-test for this once such an option is
introduced.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a4c1bd688338..06a006e0b2e3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1819,20 +1819,22 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
 
 	name = mode_option;
 
+	/* Locate the start of named options */
+	options_ptr = strchr(name, ',');
+	if (options_ptr)
+		options_off = options_ptr - name;
+	else
+		options_off = strlen(name);
+
 	/* Try to locate the bpp and refresh specifiers, if any */
-	bpp_ptr = strchr(name, '-');
+	bpp_ptr = strnchr(name, options_off, '-');
 	if (bpp_ptr)
 		bpp_off = bpp_ptr - name;
 
-	refresh_ptr = strchr(name, '@');
+	refresh_ptr = strnchr(name, options_off, '@');
 	if (refresh_ptr)
 		refresh_off = refresh_ptr - name;
 
-	/* Locate the start of named options */
-	options_ptr = strchr(name, ',');
-	if (options_ptr)
-		options_off = options_ptr - name;
-
 	/* Locate the end of the name / resolution, and parse it */
 	if (bpp_ptr) {
 		mode_end = bpp_off;

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options

[Geert Uytterhoeven]

Hi Maxime,

On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> Some video= options might have a value that contains a dash. However, the
> command line parsing mode considers all dashes as the separator between the
> mode and the bpp count.
>
> Let's rework the parsing code a bit to only consider a dash as the bpp
> separator if it before a comma, the options separator.
>
> A follow-up patch will add a unit-test for this once such an option is
> introduced.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>

> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1819,20 +1819,22 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
>
>         name = mode_option;
>
> +       /* Locate the start of named options */
> +       options_ptr = strchr(name, ',');
> +       if (options_ptr)
> +               options_off = options_ptr - name;
> +       else
> +               options_off = strlen(name);
> +
>         /* Try to locate the bpp and refresh specifiers, if any */
> -       bpp_ptr = strchr(name, '-');
> +       bpp_ptr = strnchr(name, options_off, '-');

Probably you still want to add a check that the next character
is actually a digit, cfr. my "[PATCH v2 5/5] drm/modes:
parse_cmdline: Add support for named modes containing dashes"
(https://lore.kernel.org/dri-devel/2eb205da88c3cb19ddf04d167ece4e16a330948b.1657788997.git.geert@linux-m68k.org)?

>         if (bpp_ptr)
>                 bpp_off = bpp_ptr - name;
>
> -       refresh_ptr = strchr(name, '@');
> +       refresh_ptr = strnchr(name, options_off, '@');
>         if (refresh_ptr)
>                 refresh_off = refresh_ptr - name;
>
> -       /* Locate the start of named options */
> -       options_ptr = strchr(name, ',');
> -       if (options_ptr)
> -               options_off = options_ptr - name;
> -
>         /* Locate the end of the name / resolution, and parse it */
>         if (bpp_ptr) {
>                 mode_end = bpp_off;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 07/35] drm/modes: Only consider bpp and refresh before options

[Maxime Ripard]

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

Hi Geert,

Thanks for your review

On Fri, Aug 12, 2022 at 03:25:39PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > Some video= options might have a value that contains a dash. However, the
> > command line parsing mode considers all dashes as the separator between the
> > mode and the bpp count.
> >
> > Let's rework the parsing code a bit to only consider a dash as the bpp
> > separator if it before a comma, the options separator.
> >
> > A follow-up patch will add a unit-test for this once such an option is
> > introduced.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> Thanks for your patch!
> 
> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
> 
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1819,20 +1819,22 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> >
> >         name = mode_option;
> >
> > +       /* Locate the start of named options */
> > +       options_ptr = strchr(name, ',');
> > +       if (options_ptr)
> > +               options_off = options_ptr - name;
> > +       else
> > +               options_off = strlen(name);
> > +
> >         /* Try to locate the bpp and refresh specifiers, if any */
> > -       bpp_ptr = strchr(name, '-');
> > +       bpp_ptr = strnchr(name, options_off, '-');
> 
> Probably you still want to add a check that the next character
> is actually a digit, cfr. my "[PATCH v2 5/5] drm/modes:
> parse_cmdline: Add support for named modes containing dashes"
> (https://lore.kernel.org/dri-devel/2eb205da88c3cb19ddf04d167ece4e16a330948b.1657788997.git.geert@linux-m68k.org)?

I think your patch is orthogonal, and we should merge it anyway.

As a matter of fact, I initially wanted to do something similar but
bailed out to deal with PAL-M and so on. If there's such modes already,
then we should totally support it

Maxime

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

[PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

[Maxime Ripard]

drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.

Let's add some unit tests to make sure we're not getting any regressions
there.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..ee6b8f193c24 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev *client, int mode)
 	return ret;
 }
 EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_mode_test.c"
+#endif
diff --git a/drivers/gpu/drm/tests/drm_mode_test.c b/drivers/gpu/drm/tests/drm_mode_test.c
new file mode 100644
index 000000000000..0f71519788a7
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_mode_test.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard <mripard@kernel.org>
+ */
+
+#include <drm/drm_mode.h>
+#include <kunit/test.h>
+
+#include <drm/drm_connector.h>
+#include <drm/drm_edid.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_modeset_helper_vtables.h>
+#include <drm/drm_probe_helper.h>
+
+struct drm_mode_test_priv {
+	struct device *dev;
+	struct drm_device *drm;
+	struct drm_connector connector;
+};
+
+static const struct drm_mode_config_funcs drm_mode_config_funcs = {
+};
+
+static const struct drm_driver drm_mode_driver = {
+};
+
+static int drm_mode_connector_get_modes(struct drm_connector *connector)
+{
+	struct drm_display_mode *mode;
+	int ret;
+
+	ret = drm_add_modes_noedid(connector, 1920, 1200);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct drm_connector_helper_funcs drm_mode_connector_helper_funcs = {
+	.get_modes = drm_mode_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_mode_connector_funcs = {
+};
+
+static int drm_mode_test_init(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv;
+	int ret;
+
+	priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+	test->priv = priv;
+
+	priv->dev = root_device_register("drm-mode-test");
+	if (IS_ERR(priv->dev))
+		return PTR_ERR(priv->dev);
+
+	priv->drm = drm_dev_alloc(&drm_mode_driver, priv->dev);
+	if (IS_ERR(priv->drm))
+		return PTR_ERR(priv->drm);
+	priv->drm->mode_config.funcs = &drm_mode_config_funcs;
+
+	ret = drmm_mode_config_init(priv->drm);
+	if (ret)
+		return ret;
+
+	ret = drmm_connector_init(priv->drm, &priv->connector,
+				  &drm_mode_connector_funcs,
+				  DRM_MODE_CONNECTOR_Unknown,
+				  NULL);
+	if (ret)
+		return ret;
+	drm_connector_helper_add(&priv->connector, &drm_mode_connector_helper_funcs);
+
+	return 0;
+}
+
+static void drm_mode_test_exit(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+
+	drm_dev_put(priv->drm);
+	root_device_unregister(priv->dev);
+}
+
+static void drm_mode_res_1920_1080_60(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+	struct drm_device *drm = priv->drm;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+	struct drm_display_mode *expected_mode, *mode;
+	const char *cmdline = "1920x1080@60";
+	int ret;
+
+	expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+	KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+	KUNIT_ASSERT_TRUE(test,
+			  drm_mode_parse_command_line_for_connector(cmdline,
+								    connector,
+								    cmdline_mode));
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	mode = drm_connector_pick_cmdline_mode(connector);
+	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_mode_tests[] = {
+	KUNIT_CASE(drm_mode_res_1920_1080_60),
+	{}
+};
+
+static struct kunit_suite drm_mode_test_suite = {
+	.name = "drm_mode",
+	.init = drm_mode_test_init,
+	.exit = drm_mode_test_exit,
+	.test_cases = drm_mode_tests
+};
+
+kunit_test_suite(drm_mode_test_suite);
+MODULE_AUTHOR("Maxime Ripard <mripard@kernel.org>");
+MODULE_LICENSE("GPL");

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

[Thomas Zimmermann]

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

Hi Maxime

Am 29.07.22 um 18:34 schrieb Maxime Ripard:
> drm_connector_pick_cmdline_mode() is in charge of finding a proper
> drm_display_mode from the definition we got in the video= command line
> argument.
> 
> Let's add some unit tests to make sure we're not getting any regressions
> there.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c
> index bbc535cc50dd..ee6b8f193c24 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev *client, int mode)
>   	return ret;
>   }
>   EXPORT_SYMBOL(drm_client_modeset_dpms);
> +
> +#ifdef CONFIG_DRM_KUNIT_TEST
> +#include "tests/drm_mode_test.c"
> +#endif

Including source files is somewhat ugly, prolongs compile times and 
could even interfere with the actual source code. Can we do this in some 
other way?

I suggest to add the tests here and export them for use in the test 
case. Something like

#ifdef CONFIG_DRM_KUNIT_TEST
static drm_mode_res_1920_1080_60()
{
   ...
}

struct kunit_case drm_mode_tests[] = {
   drm_mode_res_1920_1080_60
};
EXPORT_SYMBOL(drm_mode_tests);
#endif

This would add the tests next to the tested code, but leave the test 
driver in drm_mode_test.c.

Best regards
Thomas

> diff --git a/drivers/gpu/drm/tests/drm_mode_test.c b/drivers/gpu/drm/tests/drm_mode_test.c
> new file mode 100644
> index 000000000000..0f71519788a7
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_mode_test.c
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 Maxime Ripard <mripard@kernel.org>
> + */
> +
> +#include <drm/drm_mode.h>
> +#include <kunit/test.h>
> +
> +#include <drm/drm_connector.h>
> +#include <drm/drm_edid.h>
> +#include <drm/drm_drv.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_modeset_helper_vtables.h>
> +#include <drm/drm_probe_helper.h>
> +
> +struct drm_mode_test_priv {
> +	struct device *dev;
> +	struct drm_device *drm;
> +	struct drm_connector connector;
> +};
> +
> +static const struct drm_mode_config_funcs drm_mode_config_funcs = {
> +};
> +
> +static const struct drm_driver drm_mode_driver = {
> +};
> +
> +static int drm_mode_connector_get_modes(struct drm_connector *connector)
> +{
> +	struct drm_display_mode *mode;
> +	int ret;
> +
> +	ret = drm_add_modes_noedid(connector, 1920, 1200);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
> +static const struct drm_connector_helper_funcs drm_mode_connector_helper_funcs = {
> +	.get_modes = drm_mode_connector_get_modes,
> +};
> +
> +static const struct drm_connector_funcs drm_mode_connector_funcs = {
> +};
> +
> +static int drm_mode_test_init(struct kunit *test)
> +{
> +	struct drm_mode_test_priv *priv;
> +	int ret;
> +
> +	priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +	test->priv = priv;
> +
> +	priv->dev = root_device_register("drm-mode-test");
> +	if (IS_ERR(priv->dev))
> +		return PTR_ERR(priv->dev);
> +
> +	priv->drm = drm_dev_alloc(&drm_mode_driver, priv->dev);
> +	if (IS_ERR(priv->drm))
> +		return PTR_ERR(priv->drm);
> +	priv->drm->mode_config.funcs = &drm_mode_config_funcs;
> +
> +	ret = drmm_mode_config_init(priv->drm);
> +	if (ret)
> +		return ret;
> +
> +	ret = drmm_connector_init(priv->drm, &priv->connector,
> +				  &drm_mode_connector_funcs,
> +				  DRM_MODE_CONNECTOR_Unknown,
> +				  NULL);
> +	if (ret)
> +		return ret;
> +	drm_connector_helper_add(&priv->connector, &drm_mode_connector_helper_funcs);
> +
> +	return 0;
> +}
> +
> +static void drm_mode_test_exit(struct kunit *test)
> +{
> +	struct drm_mode_test_priv *priv = test->priv;
> +
> +	drm_dev_put(priv->drm);
> +	root_device_unregister(priv->dev);
> +}
> +
> +static void drm_mode_res_1920_1080_60(struct kunit *test)
> +{
> +	struct drm_mode_test_priv *priv = test->priv;
> +	struct drm_device *drm = priv->drm;
> +	struct drm_connector *connector = &priv->connector;
> +	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
> +	struct drm_display_mode *expected_mode, *mode;
> +	const char *cmdline = "1920x1080@60";
> +	int ret;
> +
> +	expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
> +	KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
> +
> +	KUNIT_ASSERT_TRUE(test,
> +			  drm_mode_parse_command_line_for_connector(cmdline,
> +								    connector,
> +								    cmdline_mode));
> +
> +	mutex_lock(&drm->mode_config.mutex);
> +	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> +	mutex_unlock(&drm->mode_config.mutex);
> +	KUNIT_ASSERT_GT(test, ret, 0);
> +
> +	mode = drm_connector_pick_cmdline_mode(connector);
> +	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
> +
> +	KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
> +}
> +
> +static struct kunit_case drm_mode_tests[] = {
> +	KUNIT_CASE(drm_mode_res_1920_1080_60),
> +	{}
> +};
> +
> +static struct kunit_suite drm_mode_test_suite = {
> +	.name = "drm_mode",
> +	.init = drm_mode_test_init,
> +	.exit = drm_mode_test_exit,
> +	.test_cases = drm_mode_tests
> +};
> +
> +kunit_test_suite(drm_mode_test_suite);
> +MODULE_AUTHOR("Maxime Ripard <mripard@kernel.org>");
> +MODULE_LICENSE("GPL");
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [PATCH v1 08/35] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

[Maxime Ripard]

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

Hi Thomas,

On Tue, Aug 02, 2022 at 12:14:29PM +0200, Thomas Zimmermann wrote:
> Am 29.07.22 um 18:34 schrieb Maxime Ripard:
> > drm_connector_pick_cmdline_mode() is in charge of finding a proper
> > drm_display_mode from the definition we got in the video= command line
> > argument.
> > 
> > Let's add some unit tests to make sure we're not getting any regressions
> > there.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c
> > index bbc535cc50dd..ee6b8f193c24 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev *client, int mode)
> >   	return ret;
> >   }
> >   EXPORT_SYMBOL(drm_client_modeset_dpms);
> > +
> > +#ifdef CONFIG_DRM_KUNIT_TEST
> > +#include "tests/drm_mode_test.c"
> > +#endif
> 
> Including source files is somewhat ugly, prolongs compile times and could
> even interfere with the actual source code. Can we do this in some other
> way?

Yeah, this irks me a bit as well, but it's the preferred way of doing it
according to the kunit doc:
https://www.kernel.org/doc/html/latest/dev-tools/kunit/usage.html#testing-static-functions

> I suggest to add the tests here and export them for use in the test case.
> Something like
> 
> #ifdef CONFIG_DRM_KUNIT_TEST
> static drm_mode_res_1920_1080_60()
> {
>   ...
> }
> 
> struct kunit_case drm_mode_tests[] = {
>   drm_mode_res_1920_1080_60
> };
> EXPORT_SYMBOL(drm_mode_tests);
> #endif
> 
> This would add the tests next to the tested code, but leave the test driver
> in drm_mode_test.c.

The test suite is fairly small for now, but if we end up with dozens of
tests like what is there for the command line parser (which could happen
for that kind of functions), I'm very afraid that the original source
file will become unreadable, while this has the advantage to keep the
original file readability.

Maxime

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

[PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function

[Maxime Ripard]

The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 06a006e0b2e3..e85099df0326 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1773,6 +1773,28 @@ static const char * const drm_named_modes_whitelist[] = {
 	"PAL",
 };
 
+static bool drm_mode_parse_cmdline_named_mode(const char *name,
+					      unsigned int name_end,
+					      struct drm_cmdline_mode *cmdline_mode)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+		int ret;
+
+		ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+		if (ret != name_end)
+			continue;
+
+		strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+		cmdline_mode->specified = true;
+
+		return true;
+	}
+
+	return false;
+}
+
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for connector
  * @mode_option: optional per connector mode option
@@ -1809,7 +1831,7 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
 	const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
 	const char *options_ptr = NULL;
 	char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
-	int i, len, ret;
+	int len, ret;
 
 	memset(mode, 0, sizeof(*mode));
 	mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -1848,18 +1870,14 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
 		parse_extras = true;
 	}
 
-	/* First check for a named mode */
-	for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
-		ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
-		if (ret == mode_end) {
-			if (refresh_ptr)
-				return false; /* named + refresh is invalid */
+	/*
+	 * Having a mode that starts by a letter (and thus is named) and
+	 * an at-sign (used to specify a refresh rate) is disallowed.
+	 */
+	if (!isdigit(name[0]) && refresh_ptr)
+		return false;
 
-			strcpy(mode->name, drm_named_modes_whitelist[i]);
-			mode->specified = true;
-			break;
-		}
-	}
+	drm_mode_parse_cmdline_named_mode(name, mode_end, mode);
 
 	/* No named mode? Check for a normal mode argument, e.g. 1024x768 */
 	if (!mode->specified && isdigit(name[0])) {

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function

[Geert Uytterhoeven]

Hi Maxime,

On Fri, Jul 29, 2022 at 6:36 PM Maxime Ripard <maxime@cerno.tech> wrote:
> The current construction of the named mode parsing doesn't allow to extend
> it easily. Let's move it to a separate function so we can add more
> parameters and modes.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Thanks for your patch, which looks similar to my "[PATCH v2 2/5]
drm/modes: Extract drm_mode_parse_cmdline_named_mode()"
(https://lore.kernel.org/dri-devel/1371554419ae63cb54c2a377db0c1016fcf200bb.1657788997.git.geert@linux-m68k.org
;-)

> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1773,6 +1773,28 @@ static const char * const drm_named_modes_whitelist[] = {
>         "PAL",
>  };
>
> +static bool drm_mode_parse_cmdline_named_mode(const char *name,
> +                                             unsigned int name_end,
> +                                             struct drm_cmdline_mode *cmdline_mode)
> +{
> +       unsigned int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> +               int ret;
> +
> +               ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> +               if (ret != name_end)
> +                       continue;
> +
> +               strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> +               cmdline_mode->specified = true;
> +
> +               return true;
> +       }
> +
> +       return false;

What's the point in returning a value, if it is never checked?
Just make this function return void?

> +}
> +
>  /**
>   * drm_mode_parse_command_line_for_connector - parse command line modeline for connector
>   * @mode_option: optional per connector mode option
> @@ -1848,18 +1870,14 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
>                 parse_extras = true;
>         }
>
> -       /* First check for a named mode */
> -       for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> -               ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> -               if (ret == mode_end) {
> -                       if (refresh_ptr)
> -                               return false; /* named + refresh is invalid */
> +       /*
> +        * Having a mode that starts by a letter (and thus is named) and
> +        * an at-sign (used to specify a refresh rate) is disallowed.
> +        */
> +       if (!isdigit(name[0]) && refresh_ptr)

This condition may have to be relaxed, if we want to support e.g.
"hd720p@50", cfr. my comments on "[PATCH v1 05/35] drm/connector:
Add TV standard property".

> +               return false;
>
> -                       strcpy(mode->name, drm_named_modes_whitelist[i]);
> -                       mode->specified = true;
> -                       break;
> -               }
> -       }
> +       drm_mode_parse_cmdline_named_mode(name, mode_end, mode);

This call needs to be conditional on mode_end being non-zero, cfr. my
patch "[PATCH v2 1/5] drm/modes: parse_cmdline: Handle empty mode name
part" (https://lore.kernel.org/dri-devel/302d0737539daa2053134e8f24fdf37e3d939e1e.1657788997.git.geert@linux-m68k.org).

>
>         /* No named mode? Check for a normal mode argument, e.g. 1024x768 */
>         if (!mode->specified && isdigit(name[0])) {


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function

[Maxime Ripard]

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

On Fri, Aug 12, 2022 at 03:27:17PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Fri, Jul 29, 2022 at 6:36 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > The current construction of the named mode parsing doesn't allow to extend
> > it easily. Let's move it to a separate function so we can add more
> > parameters and modes.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> Thanks for your patch, which looks similar to my "[PATCH v2 2/5]
> drm/modes: Extract drm_mode_parse_cmdline_named_mode()"
> (https://lore.kernel.org/dri-devel/1371554419ae63cb54c2a377db0c1016fcf200bb.1657788997.git.geert@linux-m68k.org
> ;-)

Indeed, I forgot about that one, sorry :/

I think I'd still prefer to have the check for refresh + named mode
outside of the function, since I see them as an "integration" issue, not
a parsing one.

It's not the named mode parsing that fails, but the fact that we both
have a valid refresh and a valid named mode.

> 
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1773,6 +1773,28 @@ static const char * const drm_named_modes_whitelist[] = {
> >         "PAL",
> >  };
> >
> > +static bool drm_mode_parse_cmdline_named_mode(const char *name,
> > +                                             unsigned int name_end,
> > +                                             struct drm_cmdline_mode *cmdline_mode)
> > +{
> > +       unsigned int i;
> > +
> > +       for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > +               int ret;
> > +
> > +               ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > +               if (ret != name_end)
> > +                       continue;
> > +
> > +               strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > +               cmdline_mode->specified = true;
> > +
> > +               return true;
> > +       }
> > +
> > +       return false;
> 
> What's the point in returning a value, if it is never checked?
> Just make this function return void?

Yeah, it's something I went back and forth to between the dev, and it's
an artifact.

I'll drop that patch, take your version and move the refresh check to
drm_mode_parse_command_line_for_connector if that's alright for you?

Maxime

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

Re: [PATCH v1 09/35] drm/modes: Move named modes parsing to a separate function

[Geert Uytterhoeven]

Hi Maxime,

On Tue, Aug 16, 2022 at 3:46 PM Maxime Ripard <maxime@cerno.tech> wrote:
> On Fri, Aug 12, 2022 at 03:27:17PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Jul 29, 2022 at 6:36 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > The current construction of the named mode parsing doesn't allow to extend
> > > it easily. Let's move it to a separate function so we can add more
> > > parameters and modes.
> > >
> > > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >
> > Thanks for your patch, which looks similar to my "[PATCH v2 2/5]
> > drm/modes: Extract drm_mode_parse_cmdline_named_mode()"
> > (https://lore.kernel.org/dri-devel/1371554419ae63cb54c2a377db0c1016fcf200bb.1657788997.git.geert@linux-m68k.org
> > ;-)
>
> Indeed, I forgot about that one, sorry :/
>
> I think I'd still prefer to have the check for refresh + named mode
> outside of the function, since I see them as an "integration" issue, not
> a parsing one.
>
> It's not the named mode parsing that fails, but the fact that we both
> have a valid refresh and a valid named mode.
>
> >
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1773,6 +1773,28 @@ static const char * const drm_named_modes_whitelist[] = {
> > >         "PAL",
> > >  };
> > >
> > > +static bool drm_mode_parse_cmdline_named_mode(const char *name,
> > > +                                             unsigned int name_end,
> > > +                                             struct drm_cmdline_mode *cmdline_mode)
> > > +{
> > > +       unsigned int i;
> > > +
> > > +       for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> > > +               int ret;
> > > +
> > > +               ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> > > +               if (ret != name_end)
> > > +                       continue;
> > > +
> > > +               strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> > > +               cmdline_mode->specified = true;
> > > +
> > > +               return true;
> > > +       }
> > > +
> > > +       return false;
> >
> > What's the point in returning a value, if it is never checked?
> > Just make this function return void?
>
> Yeah, it's something I went back and forth to between the dev, and it's
> an artifact.
>
> I'll drop that patch, take your version and move the refresh check to
> drm_mode_parse_command_line_for_connector if that's alright for you?

Fine for me.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v1 10/35] drm/modes: Switch to named mode descriptors

[Maxime Ripard]

The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.

Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e85099df0326..1421e5da49e0 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1768,9 +1768,13 @@ static int drm_mode_parse_cmdline_options(const char *str,
 	return 0;
 }
 
-static const char * const drm_named_modes_whitelist[] = {
-	"NTSC",
-	"PAL",
+struct drm_named_mode {
+	const char *name;
+};
+
+static const struct drm_named_mode drm_named_modes[] = {
+	{ "NTSC", },
+	{ "PAL", },
 };
 
 static bool drm_mode_parse_cmdline_named_mode(const char *name,
@@ -1779,14 +1783,15 @@ static bool drm_mode_parse_cmdline_named_mode(const char *name,
 {
 	unsigned int i;
 
-	for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+	for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+		const struct drm_named_mode *mode = &drm_named_modes[i];
 		int ret;
 
-		ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+		ret = str_has_prefix(name, mode->name);
 		if (ret != name_end)
 			continue;
 
-		strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+		strcpy(cmdline_mode->name, mode->name);
 		cmdline_mode->specified = true;
 
 		return true;

-- 
b4 0.10.0-dev-49460

[PATCH v1 11/35] drm/modes: Fill drm_cmdline mode from named modes

[Maxime Ripard]

The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.

The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and properties. Let's
start by properly filling drm_cmdline_mode from a named mode.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1421e5da49e0..78ea520f2822 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1770,11 +1770,12 @@ static int drm_mode_parse_cmdline_options(const char *str,
 
 struct drm_named_mode {
 	const char *name;
+	const struct drm_display_mode *mode;
 };
 
 static const struct drm_named_mode drm_named_modes[] = {
-	{ "NTSC", },
-	{ "PAL", },
+	{ "NTSC", &drm_mode_480i, },
+	{ "PAL", &drm_mode_576i, },
 };
 
 static bool drm_mode_parse_cmdline_named_mode(const char *name,
@@ -1792,6 +1793,9 @@ static bool drm_mode_parse_cmdline_named_mode(const char *name,
 			continue;
 
 		strcpy(cmdline_mode->name, mode->name);
+		cmdline_mode->xres = mode->mode->hdisplay;
+		cmdline_mode->yres = mode->mode->vdisplay;
+		cmdline_mode->interlace = !!(mode->mode->flags & DRM_MODE_FLAG_INTERLACE);
 		cmdline_mode->specified = true;
 
 		return true;

-- 
b4 0.10.0-dev-49460

[PATCH v1 12/35] drmi/modes: Properly generate a drm_display_mode from a named mode

[Maxime Ripard]

The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().

The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.

In the case of the named modes though, there's no real code to make that
translation and we rely on the drivers to guess which actual display mode
we meant.

Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
drm_display_mode we mean when passing a named mode.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 78ea520f2822..ecb2e83cf860 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1967,6 +1967,28 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
 }
 EXPORT_SYMBOL(drm_mode_parse_command_line_for_connector);
 
+static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
+					       struct drm_cmdline_mode *cmd)
+{
+	struct drm_display_mode *mode;
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+		const struct drm_named_mode *named_mode = &drm_named_modes[i];
+
+		if (strcmp(cmd->name, named_mode->name))
+			continue;
+
+		mode = drm_mode_duplicate(dev, named_mode->mode);
+		if (!mode)
+			return NULL;
+
+		return mode;
+	}
+
+	return NULL;
+}
+
 /**
  * drm_mode_create_from_cmdline_mode - convert a command line modeline into a DRM display mode
  * @dev: DRM device to create the new mode for
@@ -1984,7 +2006,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 	if (cmd->xres == 0 || cmd->yres == 0)
 		return NULL;
 
-	if (cmd->cvt)
+	if (strlen(cmd->name))
+		mode = drm_named_mode(dev, cmd);
+	else if (cmd->cvt)
 		mode = drm_cvt_mode(dev,
 				    cmd->xres, cmd->yres,
 				    cmd->refresh_specified ? cmd->refresh : 60,
diff --git a/drivers/gpu/drm/tests/drm_mode_test.c b/drivers/gpu/drm/tests/drm_mode_test.c
index 0f71519788a7..006b73a61fd4 100644
--- a/drivers/gpu/drm/tests/drm_mode_test.c
+++ b/drivers/gpu/drm/tests/drm_mode_test.c
@@ -34,6 +34,18 @@ static int drm_mode_connector_get_modes(struct drm_connector *connector)
 	if (ret)
 		return ret;
 
+	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
+	if (!mode)
+		return -ENOMEM;
+
+	drm_mode_probed_add(connector, mode);
+
+	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
+	if (!mode)
+		return -ENOMEM;
+
+	drm_mode_probed_add(connector, mode);
+
 	return 0;
 }
 
@@ -75,6 +87,9 @@ static int drm_mode_test_init(struct kunit *test)
 		return ret;
 	drm_connector_helper_add(&priv->connector, &drm_mode_connector_helper_funcs);
 
+	priv->connector.interlace_allowed = true;
+	priv->connector.doublescan_allowed = true;
+
 	return 0;
 }
 
@@ -115,8 +130,62 @@ static void drm_mode_res_1920_1080_60(struct kunit *test)
 	KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
 }
 
+static void drm_mode_named_ntsc(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+	struct drm_device *drm = priv->drm;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+	struct drm_display_mode *mode;
+	const char *cmdline = "NTSC";
+	int ret;
+
+	KUNIT_ASSERT_TRUE(test,
+			  drm_mode_parse_command_line_for_connector(cmdline,
+								    connector,
+								    cmdline_mode));
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	mode = drm_connector_pick_cmdline_mode(connector);
+	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
+}
+
+static void drm_mode_named_pal(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+	struct drm_device *drm = priv->drm;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+	struct drm_display_mode *mode;
+	const char *cmdline = "PAL";
+	int ret;
+
+	KUNIT_ASSERT_TRUE(test,
+			  drm_mode_parse_command_line_for_connector(cmdline,
+								    connector,
+								    cmdline_mode));
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	mode = drm_connector_pick_cmdline_mode(connector);
+	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_576i, mode));
+}
+
 static struct kunit_case drm_mode_tests[] = {
 	KUNIT_CASE(drm_mode_res_1920_1080_60),
+	KUNIT_CASE(drm_mode_named_ntsc),
+	KUNIT_CASE(drm_mode_named_pal),
 	{}
 };
 

-- 
b4 0.10.0-dev-49460

[PATCH v1 13/35] drm/atomic-helper: Add a TV properties reset helper

[Maxime Ripard]

The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.

Let's create a helper that will take care of it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfb57217253b..6d14cb0c64b1 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -481,6 +481,77 @@ void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connecto
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
+/**
+ * drm_atomic_helper_connector_tv_reset - Resets Analog TV connector properties
+ * @connector: DRM connector
+ *
+ * Resets the analog TV properties attached to a connector
+ */
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+{
+	struct drm_device *dev = connector->dev;
+	struct drm_connector_state *state = connector->state;
+	struct drm_property *prop;
+	uint64_t val;
+
+	prop = dev->mode_config.tv_norm_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.norm = val;
+
+	prop = dev->mode_config.tv_select_subconnector_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.select_subconnector = val;
+
+	prop = dev->mode_config.tv_subconnector_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.subconnector = val;
+
+	prop = dev->mode_config.tv_brightness_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.brightness = val;
+
+	prop = dev->mode_config.tv_contrast_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.contrast = val;
+
+	prop = dev->mode_config.tv_flicker_reduction_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.flicker_reduction = val;
+
+	prop = dev->mode_config.tv_overscan_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.overscan = val;
+
+	prop = dev->mode_config.tv_saturation_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.saturation = val;
+
+	prop = dev->mode_config.tv_hue_property;
+	if (prop)
+		if (!drm_object_property_get_default_value(&connector->base,
+							   prop, &val))
+			state->tv.hue = val;
+
+	drm_atomic_helper_connector_tv_margins_reset(connector);
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 192766656b88..c8fbce795ee7 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,6 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 					 struct drm_connector_state *conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,

-- 
b4 0.10.0-dev-49460

[PATCH v1 14/35] drm/atomic-helper: Add an analog TV atomic_check implementation

[Maxime Ripard]

The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created a bunch of new constraints that needs to
be shared across drivers too.

Let's create an atomic_check helper for those use cases.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 6d14cb0c64b1..fce5569bd66a 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -552,6 +552,93 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 
+/**
+ * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Checks the state object to see if the requested state is valid for an
+ * analog TV connector.
+ *
+ * Returns:
+ * Zero for success, a negative error code on error.
+ */
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+					 struct drm_atomic_state *state)
+{
+	struct drm_connector_state *old_conn_state =
+		drm_atomic_get_old_connector_state(state, connector);
+	struct drm_connector_state *new_conn_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	const struct drm_display_mode *mode;
+	struct drm_crtc_state *crtc_state;
+	struct drm_crtc *crtc;
+
+	crtc = new_conn_state->crtc;
+	if (!crtc)
+		return 0;
+
+	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+	if (!crtc_state)
+		return -EINVAL;
+
+	switch (new_conn_state->tv.norm) {
+	case DRM_MODE_TV_NORM_NTSC_443:
+		fallthrough;
+	case DRM_MODE_TV_NORM_NTSC_J:
+		fallthrough;
+	case DRM_MODE_TV_NORM_NTSC_M:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_M:
+		mode = &drm_mode_480i;
+		break;
+
+	case DRM_MODE_TV_NORM_PAL_60:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_B:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_D:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_G:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_H:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_I:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_N:
+		fallthrough;
+	case DRM_MODE_TV_NORM_PAL_NC:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_60:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_B:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_D:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_G:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_K:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_K1:
+		fallthrough;
+	case DRM_MODE_TV_NORM_SECAM_L:
+		mode = &drm_mode_576i;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (!drm_mode_equal(mode, &crtc_state->mode))
+		return -EINVAL;
+
+	if (old_conn_state->tv.norm != new_conn_state->tv.norm)
+		crtc_state->mode_changed = true;
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index c8fbce795ee7..b9740edb2658 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -26,6 +26,7 @@
 
 #include <linux/types.h>
 
+struct drm_atomic_state;
 struct drm_bridge;
 struct drm_bridge_state;
 struct drm_crtc;
@@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 					 struct drm_connector_state *conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+					 struct drm_atomic_state *state);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 14/35] drm/atomic-helper: Add an analog TV atomic_check implementation

[Mateusz Kwiatkowski]

Hi Maxime,

I'm pretty sure that PAL-60 and SECAM-60 should be tied to the 480i 
mode. Those are non-standard "norms" that use 60 Hz sync (which is 
largely synonymous with 480i in the analog TV world) with PAL/SECAM 
color encoding.

Best regards,
Mateusz Kwiatkowski

W dniu 29.07.2022 o 18:34, Maxime Ripard pisze:
> The analog TV connector drivers share some atomic_check logic, and the new
> TV standard property have created a bunch of new constraints that needs to
> be shared across drivers too.
>
> Let's create an atomic_check helper for those use cases.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 6d14cb0c64b1..fce5569bd66a 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -552,6 +552,93 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
>   }
>   EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
>   
> +/**
> + * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
> + * @connector: DRM Connector
> + * @state: the DRM State object
> + *
> + * Checks the state object to see if the requested state is valid for an
> + * analog TV connector.
> + *
> + * Returns:
> + * Zero for success, a negative error code on error.
> + */
> +int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
> +					 struct drm_atomic_state *state)
> +{
> +	struct drm_connector_state *old_conn_state =
> +		drm_atomic_get_old_connector_state(state, connector);
> +	struct drm_connector_state *new_conn_state =
> +		drm_atomic_get_new_connector_state(state, connector);
> +	const struct drm_display_mode *mode;
> +	struct drm_crtc_state *crtc_state;
> +	struct drm_crtc *crtc;
> +
> +	crtc = new_conn_state->crtc;
> +	if (!crtc)
> +		return 0;
> +
> +	crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +	if (!crtc_state)
> +		return -EINVAL;
> +
> +	switch (new_conn_state->tv.norm) {
> +	case DRM_MODE_TV_NORM_NTSC_443:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_NTSC_J:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_NTSC_M:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_M:
> +		mode = &drm_mode_480i;
> +		break;
> +
> +	case DRM_MODE_TV_NORM_PAL_60:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_B:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_D:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_G:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_H:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_I:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_N:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_PAL_NC:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_60:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_B:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_D:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_G:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_K:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_K1:
> +		fallthrough;
> +	case DRM_MODE_TV_NORM_SECAM_L:
> +		mode = &drm_mode_576i;
> +		break;
> +
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	if (!drm_mode_equal(mode, &crtc_state->mode))
> +		return -EINVAL;
> +
> +	if (old_conn_state->tv.norm != new_conn_state->tv.norm)
> +		crtc_state->mode_changed = true;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
> +
>   /**
>    * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
>    * @connector: connector object
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index c8fbce795ee7..b9740edb2658 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -26,6 +26,7 @@
>   
>   #include <linux/types.h>
>   
> +struct drm_atomic_state;
>   struct drm_bridge;
>   struct drm_bridge_state;
>   struct drm_crtc;
> @@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
>   					 struct drm_connector_state *conn_state);
>   void drm_atomic_helper_connector_reset(struct drm_connector *connector);
>   void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
> +int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
> +					 struct drm_atomic_state *state);
>   void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
>   void
>   __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
>

Re: [PATCH v1 14/35] drm/atomic-helper: Add an analog TV atomic_check implementation

[Maxime Ripard]

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

Hi,

On Fri, Jul 29, 2022 at 07:16:31PM +0200, Mateusz Kwiatkowski wrote:
> I'm pretty sure that PAL-60 and SECAM-60 should be tied to the 480i mode.
> Those are non-standard "norms" that use 60 Hz sync (which is largely
> synonymous with 480i in the analog TV world) with PAL/SECAM color encoding.

Understood, I've changed it.

Maxime

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

[PATCH v1 15/35] drm/vc4: vec: Remove empty mode_fixup

[Maxime Ripard]

The mode_fixup hooks are deprecated, and the behaviour we implement is the
default one anyway. Let's remove it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 457529e5d857..17a6afac61cd 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -483,14 +483,6 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder)
 	drm_dev_exit(idx);
 }
 
-
-static bool vc4_vec_encoder_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void vc4_vec_encoder_atomic_mode_set(struct drm_encoder *encoder,
 					struct drm_crtc_state *crtc_state,
 					struct drm_connector_state *conn_state)
@@ -518,7 +510,6 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
 static const struct drm_encoder_helper_funcs vc4_vec_encoder_helper_funcs = {
 	.disable = vc4_vec_encoder_disable,
 	.enable = vc4_vec_encoder_enable,
-	.mode_fixup = vc4_vec_encoder_mode_fixup,
 	.atomic_check = vc4_vec_encoder_atomic_check,
 	.atomic_mode_set = vc4_vec_encoder_atomic_mode_set,
 };

-- 
b4 0.10.0-dev-49460

[PATCH v1 16/35] drm/vc4: vec: Convert to atomic helpers

[Maxime Ripard]

The VC4 VEC driver still uses legacy enable and disable hook
implementation. Let's convert to the atomic variants.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 17a6afac61cd..ba0a81250d08 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -375,7 +375,8 @@ static int vc4_vec_connector_init(struct drm_device *dev, struct vc4_vec *vec)
 	return 0;
 }
 
-static void vc4_vec_encoder_disable(struct drm_encoder *encoder)
+static void vc4_vec_encoder_disable(struct drm_encoder *encoder,
+				    struct drm_atomic_state *state)
 {
 	struct drm_device *drm = encoder->dev;
 	struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
@@ -406,7 +407,8 @@ static void vc4_vec_encoder_disable(struct drm_encoder *encoder)
 	drm_dev_exit(idx);
 }
 
-static void vc4_vec_encoder_enable(struct drm_encoder *encoder)
+static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
+				   struct drm_atomic_state *state)
 {
 	struct drm_device *drm = encoder->dev;
 	struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
@@ -508,9 +510,9 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
 }
 
 static const struct drm_encoder_helper_funcs vc4_vec_encoder_helper_funcs = {
-	.disable = vc4_vec_encoder_disable,
-	.enable = vc4_vec_encoder_enable,
 	.atomic_check = vc4_vec_encoder_atomic_check,
+	.atomic_disable = vc4_vec_encoder_disable,
+	.atomic_enable = vc4_vec_encoder_enable,
 	.atomic_mode_set = vc4_vec_encoder_atomic_mode_set,
 };
 

-- 
b4 0.10.0-dev-49460

[PATCH v1 17/35] drm/vc4: vec: Refactor VEC TV mode setting

[Maxime Ripard]

From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

Change the mode_set function pointer logic to declarative config0,
config1 and custom_freq fields, to make TV mode setting logic more
concise and uniform.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index ba0a81250d08..02cef4134f2f 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -194,7 +194,9 @@ enum vc4_vec_tv_mode_id {
 
 struct vc4_vec_tv_mode {
 	const struct drm_display_mode *mode;
-	void (*mode_set)(struct vc4_vec *vec);
+	u32 config0;
+	u32 config1;
+	u32 custom_freq;
 };
 
 static const struct debugfs_reg32 vec_regs[] = {
@@ -224,34 +226,6 @@ static const struct debugfs_reg32 vec_regs[] = {
 	VC4_REG32(VEC_DAC_MISC),
 };
 
-static void vc4_vec_ntsc_mode_set(struct vc4_vec *vec)
-{
-	struct drm_device *drm = vec->connector.dev;
-	int idx;
-
-	if (!drm_dev_enter(drm, &idx))
-		return;
-
-	VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN);
-	VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
-
-	drm_dev_exit(idx);
-}
-
-static void vc4_vec_ntsc_j_mode_set(struct vc4_vec *vec)
-{
-	struct drm_device *drm = vec->connector.dev;
-	int idx;
-
-	if (!drm_dev_enter(drm, &idx))
-		return;
-
-	VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_NTSC_STD);
-	VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
-
-	drm_dev_exit(idx);
-}
-
 static const struct drm_display_mode ntsc_mode = {
 	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
 		 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
@@ -259,37 +233,6 @@ static const struct drm_display_mode ntsc_mode = {
 		 DRM_MODE_FLAG_INTERLACE)
 };
 
-static void vc4_vec_pal_mode_set(struct vc4_vec *vec)
-{
-	struct drm_device *drm = vec->connector.dev;
-	int idx;
-
-	if (!drm_dev_enter(drm, &idx))
-		return;
-
-	VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_PAL_BDGHI_STD);
-	VEC_WRITE(VEC_CONFIG1, VEC_CONFIG1_C_CVBS_CVBS);
-
-	drm_dev_exit(idx);
-}
-
-static void vc4_vec_pal_m_mode_set(struct vc4_vec *vec)
-{
-	struct drm_device *drm = vec->connector.dev;
-	int idx;
-
-	if (!drm_dev_enter(drm, &idx))
-		return;
-
-	VEC_WRITE(VEC_CONFIG0, VEC_CONFIG0_PAL_BDGHI_STD);
-	VEC_WRITE(VEC_CONFIG1,
-		  VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ);
-	VEC_WRITE(VEC_FREQ3_2, 0x223b);
-	VEC_WRITE(VEC_FREQ1_0, 0x61d1);
-
-	drm_dev_exit(idx);
-}
-
 static const struct drm_display_mode pal_mode = {
 	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
 		 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
@@ -300,19 +243,24 @@ static const struct drm_display_mode pal_mode = {
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
 	[VC4_VEC_TV_MODE_NTSC] = {
 		.mode = &ntsc_mode,
-		.mode_set = vc4_vec_ntsc_mode_set,
+		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_NTSC_J] = {
 		.mode = &ntsc_mode,
-		.mode_set = vc4_vec_ntsc_j_mode_set,
+		.config0 = VEC_CONFIG0_NTSC_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_PAL] = {
 		.mode = &pal_mode,
-		.mode_set = vc4_vec_pal_mode_set,
+		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_PAL_M] = {
 		.mode = &pal_mode,
-		.mode_set = vc4_vec_pal_m_mode_set,
+		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+		.custom_freq = 0x223b61d1,
 	},
 };
 
@@ -470,7 +418,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 	/* Mask all interrupts. */
 	VEC_WRITE(VEC_MASK0, 0);
 
-	vec->tv_mode->mode_set(vec);
+	VEC_WRITE(VEC_CONFIG0, vec->tv_mode->config0);
+	VEC_WRITE(VEC_CONFIG1, vec->tv_mode->config1);
+
+	if (vec->tv_mode->custom_freq != 0) {
+		VEC_WRITE(VEC_FREQ3_2,
+			  (vec->tv_mode->custom_freq >> 16) &
+			  0xffff);
+		VEC_WRITE(VEC_FREQ1_0,
+			  vec->tv_mode->custom_freq & 0xffff);
+	}
 
 	VEC_WRITE(VEC_DAC_MISC,
 		  VEC_DAC_MISC_VID_ACT | VEC_DAC_MISC_DAC_RST_N);

-- 
b4 0.10.0-dev-49460

[PATCH v1 18/35] drm/vc4: vec: Remove redundant atomic_mode_set

[Maxime Ripard]

From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

Let's remove the superfluous tv_mode field, which was redundant with the
mode field in struct drm_tv_connector_state.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 02cef4134f2f..a9fefd92f0f1 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -171,8 +171,6 @@ struct vc4_vec {
 
 	struct clk *clock;
 
-	const struct vc4_vec_tv_mode *tv_mode;
-
 	struct debugfs_regset32 regset;
 };
 
@@ -316,7 +314,6 @@ static int vc4_vec_connector_init(struct drm_device *dev, struct vc4_vec *vec)
 	drm_object_attach_property(&connector->base,
 				   dev->mode_config.tv_mode_property,
 				   VC4_VEC_TV_MODE_NTSC);
-	vec->tv_mode = &vc4_vec_tv_modes[VC4_VEC_TV_MODE_NTSC];
 
 	drm_connector_attach_encoder(connector, &vec->encoder.base);
 
@@ -360,6 +357,11 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 {
 	struct drm_device *drm = encoder->dev;
 	struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
+	struct drm_connector *connector = &vec->connector;
+	struct drm_connector_state *conn_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	const struct vc4_vec_tv_mode *tv_mode =
+		&vc4_vec_tv_modes[conn_state->tv.mode];
 	int idx, ret;
 
 	if (!drm_dev_enter(drm, &idx))
@@ -418,15 +420,14 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 	/* Mask all interrupts. */
 	VEC_WRITE(VEC_MASK0, 0);
 
-	VEC_WRITE(VEC_CONFIG0, vec->tv_mode->config0);
-	VEC_WRITE(VEC_CONFIG1, vec->tv_mode->config1);
+	VEC_WRITE(VEC_CONFIG0, tv_mode->config0);
+	VEC_WRITE(VEC_CONFIG1, tv_mode->config1);
 
-	if (vec->tv_mode->custom_freq != 0) {
+	if (tv_mode->custom_freq != 0) {
 		VEC_WRITE(VEC_FREQ3_2,
-			  (vec->tv_mode->custom_freq >> 16) &
-			  0xffff);
+			  (tv_mode->custom_freq >> 16) & 0xffff);
 		VEC_WRITE(VEC_FREQ1_0,
-			  vec->tv_mode->custom_freq & 0xffff);
+			  tv_mode->custom_freq & 0xffff);
 	}
 
 	VEC_WRITE(VEC_DAC_MISC,
@@ -442,15 +443,6 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 	drm_dev_exit(idx);
 }
 
-static void vc4_vec_encoder_atomic_mode_set(struct drm_encoder *encoder,
-					struct drm_crtc_state *crtc_state,
-					struct drm_connector_state *conn_state)
-{
-	struct vc4_vec *vec = encoder_to_vc4_vec(encoder);
-
-	vec->tv_mode = &vc4_vec_tv_modes[conn_state->tv.mode];
-}
-
 static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
 					struct drm_crtc_state *crtc_state,
 					struct drm_connector_state *conn_state)
@@ -470,7 +462,6 @@ static const struct drm_encoder_helper_funcs vc4_vec_encoder_helper_funcs = {
 	.atomic_check = vc4_vec_encoder_atomic_check,
 	.atomic_disable = vc4_vec_encoder_disable,
 	.atomic_enable = vc4_vec_encoder_enable,
-	.atomic_mode_set = vc4_vec_encoder_atomic_mode_set,
 };
 
 static int vc4_vec_late_register(struct drm_encoder *encoder)

-- 
b4 0.10.0-dev-49460

[PATCH v1 19/35] drm/vc4: vec: Fix timings for VEC modes

[Maxime Ripard]

From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

This commit fixes vertical timings of the VEC (composite output) modes
to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R
standards.

Previous timings were actually defined as 502 and 601 lines, resulting
in non-standard 62.69 Hz and 52 Hz signals being generated,
respectively.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index a9fefd92f0f1..8f30a530b2d5 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -227,14 +227,14 @@ static const struct debugfs_reg32 vec_regs[] = {
 static const struct drm_display_mode ntsc_mode = {
 	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
 		 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
-		 480, 480 + 3, 480 + 3 + 3, 480 + 3 + 3 + 16, 0,
+		 480, 480 + 7, 480 + 7 + 6, 525, 0,
 		 DRM_MODE_FLAG_INTERLACE)
 };
 
 static const struct drm_display_mode pal_mode = {
 	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
 		 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
-		 576, 576 + 2, 576 + 2 + 3, 576 + 2 + 3 + 20, 0,
+		 576, 576 + 4, 576 + 4 + 6, 625, 0,
 		 DRM_MODE_FLAG_INTERLACE)
 };
 

-- 
b4 0.10.0-dev-49460

[PATCH v1 20/35] drm/vc4: vec: Switch for common modes

[Maxime Ripard]

Now that the core has a definition for the 525 and 625 lines analog TV
modes, let's switch to it for vc4.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 8f30a530b2d5..255bba563fce 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -224,38 +224,24 @@ static const struct debugfs_reg32 vec_regs[] = {
 	VC4_REG32(VEC_DAC_MISC),
 };
 
-static const struct drm_display_mode ntsc_mode = {
-	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
-		 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
-		 480, 480 + 7, 480 + 7 + 6, 525, 0,
-		 DRM_MODE_FLAG_INTERLACE)
-};
-
-static const struct drm_display_mode pal_mode = {
-	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
-		 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
-		 576, 576 + 4, 576 + 4 + 6, 625, 0,
-		 DRM_MODE_FLAG_INTERLACE)
-};
-
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
 	[VC4_VEC_TV_MODE_NTSC] = {
-		.mode = &ntsc_mode,
+		.mode = &drm_mode_480i,
 		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_NTSC_J] = {
-		.mode = &ntsc_mode,
+		.mode = &drm_mode_480i,
 		.config0 = VEC_CONFIG0_NTSC_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_PAL] = {
-		.mode = &pal_mode,
+		.mode = &drm_mode_576i,
 		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_PAL_M] = {
-		.mode = &pal_mode,
+		.mode = &drm_mode_576i,
 		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
 		.custom_freq = 0x223b61d1,

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 20/35] drm/vc4: vec: Switch for common modes

[Mateusz Kwiatkowski]

Hi Maxime,

I'm just noting that the modelines you defined in drm_modes.c are 
different to the ones you're removing here.

The horizontal sync differences probably doesn't matter too much, VC4 
uses those only as a hint anyway and generates sync autonomously, so the 
slight differences will only cause the image to slightly shift horizontally.

But you're also changing the 480i vertical sync (vsync_start is now 488 
instead of 487, etc.). Are you sure that this won't break anything? This 
will probably shift the image by 1 line (which for the 480i might 
actually mean going out of spec), and I _think_ it might control the odd 
vs. even field first modes on some drivers. I won't be able to test this 
before Monday, but I'm just pointing out the potential issue.

BTW, I've seen a similar thing in the sun4i driver changes (patch 32/35) 
and the differences in vertical sync are even more dramatic. It's 
entirely possible that the current timings in sun4i are broken and the 
new ones are correct (the new ones certainly look saner to me), but I'd 
double-check if that driver does not have any quirks that would 
_require_ such weird settings.

Best regards,
Mateusz Kwiatkowski

W dniu 29.07.2022 o 18:35, Maxime Ripard pisze:
> Now that the core has a definition for the 525 and 625 lines analog TV
> modes, let's switch to it for vc4.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index 8f30a530b2d5..255bba563fce 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -224,38 +224,24 @@ static const struct debugfs_reg32 vec_regs[] = {
>   	VC4_REG32(VEC_DAC_MISC),
>   };
>   
> -static const struct drm_display_mode ntsc_mode = {
> -	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
> -		 720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
> -		 480, 480 + 7, 480 + 7 + 6, 525, 0,
> -		 DRM_MODE_FLAG_INTERLACE)
> -};
> -
> -static const struct drm_display_mode pal_mode = {
> -	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
> -		 720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
> -		 576, 576 + 4, 576 + 4 + 6, 625, 0,
> -		 DRM_MODE_FLAG_INTERLACE)
> -};
> -
>   static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>   	[VC4_VEC_TV_MODE_NTSC] = {
> -		.mode = &ntsc_mode,
> +		.mode = &drm_mode_480i,
>   		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
>   	},
>   	[VC4_VEC_TV_MODE_NTSC_J] = {
> -		.mode = &ntsc_mode,
> +		.mode = &drm_mode_480i,
>   		.config0 = VEC_CONFIG0_NTSC_STD,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
>   	},
>   	[VC4_VEC_TV_MODE_PAL] = {
> -		.mode = &pal_mode,
> +		.mode = &drm_mode_576i,
>   		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
>   	},
>   	[VC4_VEC_TV_MODE_PAL_M] = {
> -		.mode = &pal_mode,
> +		.mode = &drm_mode_576i,
>   		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
>   		.custom_freq = 0x223b61d1,
>

Re: [PATCH v1 20/35] drm/vc4: vec: Switch for common modes

[Maxime Ripard]

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

Hi,

On Fri, Jul 29, 2022 at 08:12:07PM +0200, Mateusz Kwiatkowski wrote:
> I'm just noting that the modelines you defined in drm_modes.c are different
> to the ones you're removing here.
> 
> The horizontal sync differences probably doesn't matter too much, VC4 uses
> those only as a hint anyway and generates sync autonomously, so the slight
> differences will only cause the image to slightly shift horizontally.
> 
> But you're also changing the 480i vertical sync (vsync_start is now 488
> instead of 487, etc.). Are you sure that this won't break anything? This
> will probably shift the image by 1 line (which for the 480i might actually
> mean going out of spec), and I _think_ it might control the odd vs. even
> field first modes on some drivers. I won't be able to test this before
> Monday, but I'm just pointing out the potential issue.

I didn't see any difference on both vc4 and sun4i, but you might be
right about this.

I didn't have much confidence in the vc4 modes since they were broken
before your patches, but maybe I should have used yours still.

> BTW, I've seen a similar thing in the sun4i driver changes (patch 32/35) and
> the differences in vertical sync are even more dramatic. It's entirely
> possible that the current timings in sun4i are broken and the new ones are
> correct (the new ones certainly look saner to me), but I'd double-check if
> that driver does not have any quirks that would _require_ such weird
> settings.

The only thing sun4i requires from the new mode is the line number
anyway, which stays the same.

Maxime

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

[PATCH v1 21/35] drm/vc4: vec: Fix definition of PAL-M mode

[Maxime Ripard]

From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma
subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings.
This commit makes the driver actually use the proper VEC preset for this
mode instead of just changing PAL subcarrier frequency.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 255bba563fce..fba15a14787e 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -69,6 +69,7 @@
 #define VEC_CONFIG0_STD_MASK		GENMASK(1, 0)
 #define VEC_CONFIG0_NTSC_STD		0
 #define VEC_CONFIG0_PAL_BDGHI_STD	1
+#define VEC_CONFIG0_PAL_M_STD		2
 #define VEC_CONFIG0_PAL_N_STD		3
 
 #define VEC_SCHPH			0x108
@@ -241,10 +242,9 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 	[VC4_VEC_TV_MODE_PAL_M] = {
-		.mode = &drm_mode_576i,
-		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
-		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
-		.custom_freq = 0x223b61d1,
+		.mode = &drm_mode_480i,
+		.config0 = VEC_CONFIG0_PAL_M_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 };
 

-- 
b4 0.10.0-dev-49460

[PATCH v1 22/35] drm/vc4: vec: Use TV Reset implementation

[Maxime Ripard]

The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index fba15a14787e..6f4536bf537f 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -254,6 +254,12 @@ vc4_vec_connector_detect(struct drm_connector *connector, bool force)
 	return connector_status_unknown;
 }
 
+void vc4_vec_connector_reset(struct drm_connector *connector)
+{
+	drm_atomic_helper_connector_reset(connector);
+	drm_atomic_helper_connector_tv_reset(connector);
+}
+
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
 	struct drm_connector_state *state = connector->state;
@@ -274,7 +280,7 @@ static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 static const struct drm_connector_funcs vc4_vec_connector_funcs = {
 	.detect = vc4_vec_connector_detect,
 	.fill_modes = drm_helper_probe_single_connector_modes,
-	.reset = drm_atomic_helper_connector_reset,
+	.reset = vc4_vec_connector_reset,
 	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 22/35] drm/vc4: vec: Use TV Reset implementation

[kernel test robot]

Hi Maxime,

I love your patch! Perhaps something to improve:

[auto build test WARNING on 37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
base:   37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9
config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20220730/202207301024.h3rifgQO-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/2f380bf85052b89ae0ffc6cfdf2dc91cdcde5a75
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
        git checkout 2f380bf85052b89ae0ffc6cfdf2dc91cdcde5a75
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/drm/vc4/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/vc4/vc4_vec.c:257:6: warning: no previous prototype for 'vc4_vec_connector_reset' [-Wmissing-prototypes]
     257 | void vc4_vec_connector_reset(struct drm_connector *connector)
         |      ^~~~~~~~~~~~~~~~~~~~~~~


vim +/vc4_vec_connector_reset +257 drivers/gpu/drm/vc4/vc4_vec.c

   256	
 > 257	void vc4_vec_connector_reset(struct drm_connector *connector)
   258	{
   259		drm_atomic_helper_connector_reset(connector);
   260		drm_atomic_helper_connector_tv_reset(connector);
   261	}
   262	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property

[Maxime Ripard]

Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.

We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 6f4536bf537f..e40b55de1b3c 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -172,6 +172,8 @@ struct vc4_vec {
 
 	struct clk *clock;
 
+	struct drm_property *tv_mode_property;
+
 	struct debugfs_regset32 regset;
 };
 
@@ -184,6 +186,12 @@ encoder_to_vc4_vec(struct drm_encoder *encoder)
 	return container_of(encoder, struct vc4_vec, encoder.base);
 }
 
+static inline struct vc4_vec *
+connector_to_vc4_vec(struct drm_connector *connector)
+{
+	return container_of(connector, struct vc4_vec, connector);
+}
+
 enum vc4_vec_tv_mode_id {
 	VC4_VEC_TV_MODE_NTSC,
 	VC4_VEC_TV_MODE_NTSC_J,
@@ -192,7 +200,7 @@ enum vc4_vec_tv_mode_id {
 };
 
 struct vc4_vec_tv_mode {
-	const struct drm_display_mode *mode;
+	unsigned int mode;
 	u32 config0;
 	u32 config1;
 	u32 custom_freq;
@@ -226,28 +234,50 @@ static const struct debugfs_reg32 vec_regs[] = {
 };
 
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
-	[VC4_VEC_TV_MODE_NTSC] = {
-		.mode = &drm_mode_480i,
+	{
+		.mode = DRM_MODE_TV_NORM_NTSC_M,
 		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
-	[VC4_VEC_TV_MODE_NTSC_J] = {
-		.mode = &drm_mode_480i,
+	{
+		.mode = DRM_MODE_TV_NORM_NTSC_J,
 		.config0 = VEC_CONFIG0_NTSC_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
-	[VC4_VEC_TV_MODE_PAL] = {
-		.mode = &drm_mode_576i,
+	{
+		.mode = DRM_MODE_TV_NORM_PAL_B,
 		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
-	[VC4_VEC_TV_MODE_PAL_M] = {
-		.mode = &drm_mode_480i,
+	{
+		.mode = DRM_MODE_TV_NORM_PAL_M,
 		.config0 = VEC_CONFIG0_PAL_M_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
 };
 
+static inline const struct vc4_vec_tv_mode *
+vc4_vec_tv_mode_lookup(unsigned int mode)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
+		const struct vc4_vec_tv_mode *tv_mode = &vc4_vec_tv_modes[i];
+
+		if (tv_mode->mode == mode)
+			return tv_mode;
+	}
+
+	return NULL;
+}
+
+static const struct drm_prop_enum_list tv_mode_names[] = {
+	{ VC4_VEC_TV_MODE_NTSC, "NTSC", },
+	{ VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
+	{ VC4_VEC_TV_MODE_PAL, "PAL", },
+	{ VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
+};
+
 static enum drm_connector_status
 vc4_vec_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -262,11 +292,17 @@ void vc4_vec_connector_reset(struct drm_connector *connector)
 
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
-	struct drm_connector_state *state = connector->state;
 	struct drm_display_mode *mode;
 
-	mode = drm_mode_duplicate(connector->dev,
-				  vc4_vec_tv_modes[state->tv.mode].mode);
+	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
+	if (!mode) {
+		DRM_ERROR("Failed to create a new display mode\n");
+		return -ENOMEM;
+	}
+
+	drm_mode_probed_add(connector, mode);
+
+	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
 	if (!mode) {
 		DRM_ERROR("Failed to create a new display mode\n");
 		return -ENOMEM;
@@ -277,21 +313,95 @@ static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 	return 1;
 }
 
+static int
+vc4_vec_connector_set_property(struct drm_connector *connector,
+			       struct drm_connector_state *state,
+			       struct drm_property *property,
+			       uint64_t val)
+{
+	struct vc4_vec *vec = connector_to_vc4_vec(connector);
+
+	if (property != vec->tv_mode_property)
+		return -EINVAL;
+
+	switch (val) {
+	case VC4_VEC_TV_MODE_NTSC:
+		state->tv.norm = DRM_MODE_TV_NORM_NTSC_M;
+		break;
+
+	case VC4_VEC_TV_MODE_NTSC_J:
+		state->tv.norm = DRM_MODE_TV_NORM_NTSC_J;
+		break;
+
+	case VC4_VEC_TV_MODE_PAL:
+		state->tv.norm = DRM_MODE_TV_NORM_PAL_B;
+		break;
+
+	case VC4_VEC_TV_MODE_PAL_M:
+		state->tv.norm = DRM_MODE_TV_NORM_PAL_M;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int
+vc4_vec_connector_get_property(struct drm_connector *connector,
+			       const struct drm_connector_state *state,
+			       struct drm_property *property,
+			       uint64_t *val)
+{
+	struct vc4_vec *vec = connector_to_vc4_vec(connector);
+
+	if (property != vec->tv_mode_property)
+		return -EINVAL;
+
+	switch (state->tv.norm) {
+	case DRM_MODE_TV_NORM_NTSC_J:
+		*val = VC4_VEC_TV_MODE_NTSC_J;
+		break;
+
+	case DRM_MODE_TV_NORM_NTSC_M:
+		*val = VC4_VEC_TV_MODE_NTSC;
+		break;
+
+	case DRM_MODE_TV_NORM_PAL_B:
+		*val = VC4_VEC_TV_MODE_PAL;
+		break;
+
+	case DRM_MODE_TV_NORM_PAL_M:
+		*val = VC4_VEC_TV_MODE_PAL_M;
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static const struct drm_connector_funcs vc4_vec_connector_funcs = {
 	.detect = vc4_vec_connector_detect,
 	.fill_modes = drm_helper_probe_single_connector_modes,
 	.reset = vc4_vec_connector_reset,
 	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+	.atomic_get_property = vc4_vec_connector_get_property,
+	.atomic_set_property = vc4_vec_connector_set_property,
 };
 
 static const struct drm_connector_helper_funcs vc4_vec_connector_helper_funcs = {
+	.atomic_check = drm_atomic_helper_connector_tv_check,
 	.get_modes = vc4_vec_connector_get_modes,
 };
 
 static int vc4_vec_connector_init(struct drm_device *dev, struct vc4_vec *vec)
 {
 	struct drm_connector *connector = &vec->connector;
+	struct drm_property *prop;
 	int ret;
 
 	connector->interlace_allowed = true;
@@ -304,8 +414,16 @@ static int vc4_vec_connector_init(struct drm_device *dev, struct vc4_vec *vec)
 	drm_connector_helper_add(connector, &vc4_vec_connector_helper_funcs);
 
 	drm_object_attach_property(&connector->base,
-				   dev->mode_config.tv_mode_property,
-				   VC4_VEC_TV_MODE_NTSC);
+				   dev->mode_config.tv_norm_property,
+				   DRM_MODE_TV_NORM_NTSC_M);
+
+	prop = drm_property_create_enum(dev, 0, "mode",
+					tv_mode_names, ARRAY_SIZE(tv_mode_names));
+	if (!prop)
+		return -ENOMEM;
+	vec->tv_mode_property = prop;
+
+	drm_object_attach_property(&connector->base, prop, VC4_VEC_TV_MODE_NTSC);
 
 	drm_connector_attach_encoder(connector, &vec->encoder.base);
 
@@ -352,13 +470,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 	struct drm_connector *connector = &vec->connector;
 	struct drm_connector_state *conn_state =
 		drm_atomic_get_new_connector_state(state, connector);
-	const struct vc4_vec_tv_mode *tv_mode =
-		&vc4_vec_tv_modes[conn_state->tv.mode];
+	const struct vc4_vec_tv_mode *tv_mode;
 	int idx, ret;
 
 	if (!drm_dev_enter(drm, &idx))
 		return;
 
+	tv_mode = vc4_vec_tv_mode_lookup(conn_state->tv.norm);
+	if (!tv_mode)
+		goto err_dev_exit;
+
 	ret = pm_runtime_get_sync(&vec->pdev->dev);
 	if (ret < 0) {
 		DRM_ERROR("Failed to retain power domain: %d\n", ret);
@@ -435,23 +556,7 @@ static void vc4_vec_encoder_enable(struct drm_encoder *encoder,
 	drm_dev_exit(idx);
 }
 
-static int vc4_vec_encoder_atomic_check(struct drm_encoder *encoder,
-					struct drm_crtc_state *crtc_state,
-					struct drm_connector_state *conn_state)
-{
-	const struct vc4_vec_tv_mode *vec_mode;
-
-	vec_mode = &vc4_vec_tv_modes[conn_state->tv.mode];
-
-	if (conn_state->crtc &&
-	    !drm_mode_equal(vec_mode->mode, &crtc_state->adjusted_mode))
-		return -EINVAL;
-
-	return 0;
-}
-
 static const struct drm_encoder_helper_funcs vc4_vec_encoder_helper_funcs = {
-	.atomic_check = vc4_vec_encoder_atomic_check,
 	.atomic_disable = vc4_vec_encoder_disable,
 	.atomic_enable = vc4_vec_encoder_enable,
 };
@@ -492,13 +597,6 @@ static const struct of_device_id vc4_vec_dt_match[] = {
 	{ /* sentinel */ },
 };
 
-static const char * const tv_mode_names[] = {
-	[VC4_VEC_TV_MODE_NTSC] = "NTSC",
-	[VC4_VEC_TV_MODE_NTSC_J] = "NTSC-J",
-	[VC4_VEC_TV_MODE_PAL] = "PAL",
-	[VC4_VEC_TV_MODE_PAL_M] = "PAL-M",
-};
-
 static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
@@ -507,9 +605,11 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
 	int ret;
 
 	ret = drm_mode_create_tv_properties(drm,
-					    0,
-					    ARRAY_SIZE(tv_mode_names),
-					    tv_mode_names);
+					    DRM_MODE_TV_NORM_NTSC_J |
+					    DRM_MODE_TV_NORM_NTSC_M |
+					    DRM_MODE_TV_NORM_PAL_B |
+					    DRM_MODE_TV_NORM_PAL_M,
+					    0, NULL);
 	if (ret)
 		return ret;
 

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property

[Noralf Trønnes]

Den 29.07.2022 18.35, skrev Maxime Ripard:
> Now that the core can deal fine with analog TV modes, let's convert the vc4
> VEC driver to leverage those new features.
> 
> We've added some backward compatibility to support the old TV mode property
> and translate it into the new TV norm property.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c

>  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>  {
> -	struct drm_connector_state *state = connector->state;
>  	struct drm_display_mode *mode;
>  
> -	mode = drm_mode_duplicate(connector->dev,
> -				  vc4_vec_tv_modes[state->tv.mode].mode);
> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
> +	if (!mode) {
> +		DRM_ERROR("Failed to create a new display mode\n");
> +		return -ENOMEM;
> +	}
> +
> +	drm_mode_probed_add(connector, mode);
> +
> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);

Maybe the mode that matches tv.norm should be marked as preferred so
userspace knows which one to pick?

Noralf.

>  	if (!mode) {
>  		DRM_ERROR("Failed to create a new display mode\n");
>  		return -ENOMEM;
> @@ -277,21 +313,95 @@ static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>  	return 1;
>  }

Re: [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property

[Maxime Ripard]

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

Hi,

On Sat, Aug 20, 2022 at 07:22:48PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.35, skrev Maxime Ripard:
> > Now that the core can deal fine with analog TV modes, let's convert the vc4
> > VEC driver to leverage those new features.
> > 
> > We've added some backward compatibility to support the old TV mode property
> > and translate it into the new TV norm property.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> 
> >  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> >  {
> > -	struct drm_connector_state *state = connector->state;
> >  	struct drm_display_mode *mode;
> >  
> > -	mode = drm_mode_duplicate(connector->dev,
> > -				  vc4_vec_tv_modes[state->tv.mode].mode);
> > +	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
> > +	if (!mode) {
> > +		DRM_ERROR("Failed to create a new display mode\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	drm_mode_probed_add(connector, mode);
> > +
> > +	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
> 
> Maybe the mode that matches tv.norm should be marked as preferred so
> userspace knows which one to pick?

I'm not sure how realistic that would be. Doing this based on the driver
/ cmdline preference is going to be fairly easy, but then it's a
property, it's going to be updated, and we probably don't want to mess
around the mode flags based on new property values?

Maxime

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

Re: [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property

[Noralf Trønnes]

Den 24.08.2022 17.26, skrev Maxime Ripard:
> Hi,
> 
> On Sat, Aug 20, 2022 at 07:22:48PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.35, skrev Maxime Ripard:
>>> Now that the core can deal fine with analog TV modes, let's convert the vc4
>>> VEC driver to leverage those new features.
>>>
>>> We've added some backward compatibility to support the old TV mode property
>>> and translate it into the new TV norm property.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>>
>>>  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>>>  {
>>> -	struct drm_connector_state *state = connector->state;
>>>  	struct drm_display_mode *mode;
>>>  
>>> -	mode = drm_mode_duplicate(connector->dev,
>>> -				  vc4_vec_tv_modes[state->tv.mode].mode);
>>> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
>>> +	if (!mode) {
>>> +		DRM_ERROR("Failed to create a new display mode\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	drm_mode_probed_add(connector, mode);
>>> +
>>> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
>>
>> Maybe the mode that matches tv.norm should be marked as preferred so
>> userspace knows which one to pick?
> 
> I'm not sure how realistic that would be. Doing this based on the driver
> / cmdline preference is going to be fairly easy, but then it's a
> property, it's going to be updated, and we probably don't want to mess
> around the mode flags based on new property values?
> 

Strictly speaking we need to fire an event to userspace if the mode
changes, and this is probably not straightforward to do underneath
modeset locks, would probably need a worker.

Clever userspace like GNOME will try to use the active mode, so it will
handle this that way. If someone has set up the pipeline first that is.
drm_client/fbdev and plymouth can do that because they honour userdef modes.

Other userspace that don't know the userdef flag will fallback to the
first mode which is NTSC which is also the default tvmode, so maybe this
is good enough. PAL users will have to specify the mode, or teach their
program about the userdef flag.

But ofc relying on the userdef flag depends on the fact that there's a
mode on the kernel command line, but maybe there's no way to avoid that
since much/most? userspace treat "unknown" connector status as
disconnected so many will have to force the connector to "connected"
anyway. At least I don't know any way to permanetly force the connector
status other than using video=.

Noralf.

Re: [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode property

[Maxime Ripard]

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

Hi Noralf,

On Thu, Aug 25, 2022 at 03:14:01PM +0200, Noralf Trønnes wrote:
> Den 24.08.2022 17.26, skrev Maxime Ripard:
> > On Sat, Aug 20, 2022 at 07:22:48PM +0200, Noralf Trønnes wrote:
> >> Den 29.07.2022 18.35, skrev Maxime Ripard:
> >>> Now that the core can deal fine with analog TV modes, let's convert the vc4
> >>> VEC driver to leverage those new features.
> >>>
> >>> We've added some backward compatibility to support the old TV mode property
> >>> and translate it into the new TV norm property.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>
> >>> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> >>
> >>>  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> >>>  {
> >>> -	struct drm_connector_state *state = connector->state;
> >>>  	struct drm_display_mode *mode;
> >>>  
> >>> -	mode = drm_mode_duplicate(connector->dev,
> >>> -				  vc4_vec_tv_modes[state->tv.mode].mode);
> >>> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
> >>> +	if (!mode) {
> >>> +		DRM_ERROR("Failed to create a new display mode\n");
> >>> +		return -ENOMEM;
> >>> +	}
> >>> +
> >>> +	drm_mode_probed_add(connector, mode);
> >>> +
> >>> +	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
> >>
> >> Maybe the mode that matches tv.norm should be marked as preferred so
> >> userspace knows which one to pick?
> > 
> > I'm not sure how realistic that would be. Doing this based on the driver
> > / cmdline preference is going to be fairly easy, but then it's a
> > property, it's going to be updated, and we probably don't want to mess
> > around the mode flags based on new property values?
> > 
> 
> Strictly speaking we need to fire an event to userspace if the mode
> changes, and this is probably not straightforward to do underneath
> modeset locks, would probably need a worker.

I'm not sure this would work in all cases. Kodi for example doesn't
handle hotplug events at all, so we might end up in situations where the
state is not consistent anymore.

Even if we were to only expose one mode to the userspace, depending on
the current TV mode, userspace could still end up trying to push a mode
into KMS that isn't the one we expose anymore, so I'm not sure we can
solve this entirely.

> Clever userspace like GNOME will try to use the active mode, so it will
> handle this that way. If someone has set up the pipeline first that is.
> drm_client/fbdev and plymouth can do that because they honour userdef modes.
> 
> Other userspace that don't know the userdef flag will fallback to the
> first mode which is NTSC which is also the default tvmode, so maybe this
> is good enough. PAL users will have to specify the mode, or teach their
> program about the userdef flag.
> 
> But ofc relying on the userdef flag depends on the fact that there's a
> mode on the kernel command line, but maybe there's no way to avoid that
> since much/most? userspace treat "unknown" connector status as
> disconnected so many will have to force the connector to "connected"
> anyway. At least I don't know any way to permanetly force the connector
> status other than using video=.

You can do it through sysfs as well, in .../status

Maxime

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

[PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards

[Maxime Ripard]

From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>

Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):

- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
  4.43361875 MHz (the PAL subcarrier frequency). Never used for
  broadcasting, but sometimes used as a hack to play NTSC content in PAL
  regions (e.g. on VCRs).
- PAL_N - PAL with alternative chroma subcarrier frequency,
  3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
  and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
- PAL60 - 480i60 signal with PAL-style color at normal European PAL
  frequency. Another non-standard, non-broadcast mode, used in similar
  contexts as NTSC_443. Some displays support one but not the other.
- SECAM - French frequency-modulated analog color standard; also have
  been broadcast in Eastern Europe and various parts of Africa and Asia.
  Uses the same 576i50 timings as PAL.

Also added some comments explaining color subcarrier frequency
registers.

Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index e40b55de1b3c..91d343238b0f 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -46,6 +46,7 @@
 #define VEC_CONFIG0_YDEL(x)		((x) << 26)
 #define VEC_CONFIG0_CDEL_MASK		GENMASK(25, 24)
 #define VEC_CONFIG0_CDEL(x)		((x) << 24)
+#define VEC_CONFIG0_SECAM_STD		BIT(21)
 #define VEC_CONFIG0_PBPR_FIL		BIT(18)
 #define VEC_CONFIG0_CHROMA_GAIN_MASK	GENMASK(17, 16)
 #define VEC_CONFIG0_CHROMA_GAIN_UNITY	(0 << 16)
@@ -76,6 +77,27 @@
 #define VEC_SOFT_RESET			0x10c
 #define VEC_CLMP0_START			0x144
 #define VEC_CLMP0_END			0x148
+
+/*
+ * These set the color subcarrier frequency
+ * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
+ *
+ * VEC_FREQ1_0 contains the most significant 16-bit half-word,
+ * VEC_FREQ3_2 contains the least significant 16-bit half-word.
+ * 0x80000000 seems to be equivalent to the pixel clock
+ * (which itself is the VEC clock divided by 8).
+ *
+ * Reference values (with the default pixel clock of 13.5 MHz):
+ *
+ * NTSC  (3579545.[45] Hz)     - 0x21F07C1F
+ * PAL   (4433618.75 Hz)       - 0x2A098ACB
+ * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
+ * PAL-N (3582056.25 Hz)       - 0x21F69446
+ *
+ * NOTE: For SECAM, it is used as the Dr center frequency,
+ * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
+ * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
+ */
 #define VEC_FREQ3_2			0x180
 #define VEC_FREQ1_0			0x184
 
@@ -118,6 +140,14 @@
 
 #define VEC_INTERRUPT_CONTROL		0x190
 #define VEC_INTERRUPT_STATUS		0x194
+
+/*
+ * Db center frequency for SECAM; the clock for this is the same as for
+ * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
+ *
+ * This is specified as 4250000 Hz, which corresponds to 0x284BDA13.
+ * That is also the default value, so no need to set it explicitly.
+ */
 #define VEC_FCW_SECAM_B			0x198
 #define VEC_SECAM_GAIN_VAL		0x19c
 
@@ -194,9 +224,13 @@ connector_to_vc4_vec(struct drm_connector *connector)
 
 enum vc4_vec_tv_mode_id {
 	VC4_VEC_TV_MODE_NTSC,
+	VC4_VEC_TV_MODE_NTSC_443,
 	VC4_VEC_TV_MODE_NTSC_J,
 	VC4_VEC_TV_MODE_PAL,
+	VC4_VEC_TV_MODE_PAL_60,
 	VC4_VEC_TV_MODE_PAL_M,
+	VC4_VEC_TV_MODE_PAL_N,
+	VC4_VEC_TV_MODE_SECAM,
 };
 
 struct vc4_vec_tv_mode {
@@ -234,6 +268,12 @@ static const struct debugfs_reg32 vec_regs[] = {
 };
 
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
+	{
+		.mode = DRM_MODE_TV_NORM_NTSC_443,
+		.config0 = VEC_CONFIG0_NTSC_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+		.custom_freq = 0x2a098acb,
+	},
 	{
 		.mode = DRM_MODE_TV_NORM_NTSC_M,
 		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
@@ -244,6 +284,12 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
 		.config0 = VEC_CONFIG0_NTSC_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
+	{
+		.mode = DRM_MODE_TV_NORM_PAL_60,
+		.config0 = VEC_CONFIG0_PAL_M_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+		.custom_freq = 0x2a098acb,
+	},
 	{
 		.mode = DRM_MODE_TV_NORM_PAL_B,
 		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
@@ -254,6 +300,17 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
 		.config0 = VEC_CONFIG0_PAL_M_STD,
 		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
 	},
+	{
+		.mode = DRM_MODE_TV_NORM_PAL_N,
+		.config0 = VEC_CONFIG0_PAL_N_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
+	},
+	{
+		.mode = DRM_MODE_TV_NORM_SECAM_B,
+		.config0 = VEC_CONFIG0_SECAM_STD,
+		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
+		.custom_freq = 0x29c71c72,
+	},
 };
 
 static inline const struct vc4_vec_tv_mode *
@@ -273,9 +330,13 @@ vc4_vec_tv_mode_lookup(unsigned int mode)
 
 static const struct drm_prop_enum_list tv_mode_names[] = {
 	{ VC4_VEC_TV_MODE_NTSC, "NTSC", },
+	{ VC4_VEC_TV_MODE_NTSC_443, "NTSC-443", },
 	{ VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
 	{ VC4_VEC_TV_MODE_PAL, "PAL", },
+	{ VC4_VEC_TV_MODE_PAL_60, "PAL-60", },
 	{ VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
+	{ VC4_VEC_TV_MODE_PAL_N, "PAL-N", },
+	{ VC4_VEC_TV_MODE_SECAM, "SECAM", },
 };
 
 static enum drm_connector_status
@@ -329,6 +390,10 @@ vc4_vec_connector_set_property(struct drm_connector *connector,
 		state->tv.norm = DRM_MODE_TV_NORM_NTSC_M;
 		break;
 
+	case VC4_VEC_TV_MODE_NTSC_443:
+		state->tv.norm = DRM_MODE_TV_NORM_NTSC_443;
+		break;
+
 	case VC4_VEC_TV_MODE_NTSC_J:
 		state->tv.norm = DRM_MODE_TV_NORM_NTSC_J;
 		break;
@@ -337,10 +402,22 @@ vc4_vec_connector_set_property(struct drm_connector *connector,
 		state->tv.norm = DRM_MODE_TV_NORM_PAL_B;
 		break;
 
+	case VC4_VEC_TV_MODE_PAL_60:
+		state->tv.norm = DRM_MODE_TV_NORM_PAL_60;
+		break;
+
 	case VC4_VEC_TV_MODE_PAL_M:
 		state->tv.norm = DRM_MODE_TV_NORM_PAL_M;
 		break;
 
+	case VC4_VEC_TV_MODE_PAL_N:
+		state->tv.norm = DRM_MODE_TV_NORM_PAL_N;
+		break;
+
+	case VC4_VEC_TV_MODE_SECAM:
+		state->tv.norm = DRM_MODE_TV_NORM_SECAM_B;
+		break;
+
 	default:
 		return -EINVAL;
 	}
@@ -360,6 +437,10 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
 		return -EINVAL;
 
 	switch (state->tv.norm) {
+	case DRM_MODE_TV_NORM_NTSC_443:
+		*val = VC4_VEC_TV_MODE_NTSC_443;
+		break;
+
 	case DRM_MODE_TV_NORM_NTSC_J:
 		*val = VC4_VEC_TV_MODE_NTSC_J;
 		break;
@@ -368,6 +449,10 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
 		*val = VC4_VEC_TV_MODE_NTSC;
 		break;
 
+	case DRM_MODE_TV_NORM_PAL_60:
+		*val = VC4_VEC_TV_MODE_PAL_60;
+		break;
+
 	case DRM_MODE_TV_NORM_PAL_B:
 		*val = VC4_VEC_TV_MODE_PAL;
 		break;
@@ -376,6 +461,14 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
 		*val = VC4_VEC_TV_MODE_PAL_M;
 		break;
 
+	case DRM_MODE_TV_NORM_PAL_N:
+		*val = VC4_VEC_TV_MODE_PAL_N;
+		break;
+
+	case DRM_MODE_TV_NORM_SECAM_B:
+		*val = VC4_VEC_TV_MODE_SECAM;
+		break;
+
 	default:
 		return -EINVAL;
 	}
@@ -605,10 +698,13 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
 	int ret;
 
 	ret = drm_mode_create_tv_properties(drm,
+					    DRM_MODE_TV_NORM_NTSC_443 |
 					    DRM_MODE_TV_NORM_NTSC_J |
 					    DRM_MODE_TV_NORM_NTSC_M |
 					    DRM_MODE_TV_NORM_PAL_B |
-					    DRM_MODE_TV_NORM_PAL_M,
+					    DRM_MODE_TV_NORM_PAL_M |
+					    DRM_MODE_TV_NORM_PAL_N |
+					    DRM_MODE_TV_NORM_SECAM_B,
 					    0, NULL);
 	if (ret)
 		return ret;

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards

[Mateusz Kwiatkowski]

Hi Maxime,

I think that declaring PAL-B and SECAM-B as the only supported 576i 
norms is a bit random.

Norms B, D, G, H, I, K, K1 and L (for both PAL and SECAM) are 
essentially identical if we're talking about baseband signals, AFAIK 
they only differ when those are modulated as RF signals. I'm not sure if 
there's a point to differentiating those (that's more about patch 05/35) 
unless we need to deal with some device that actually features an RF 
modulator.

But if we do want to have all those norms separate, then I'd say that 
VC4 should declare support for all of those, and all should map to the 
same VEC settings. Some users from e.g. the UK might think that they 
won't get proper picture if PAL-I is not on the list of supported norms. 
Same goes for e.g. SECAM-D/K in the former Soviet territories, and so on.

Best regards,
Mateusz Kwiatkowski

W dniu 29.07.2022 o 18:35, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>    4.43361875 MHz (the PAL subcarrier frequency). Never used for
>    broadcasting, but sometimes used as a hack to play NTSC content in PAL
>    regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
>    3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>    and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>    frequency. Another non-standard, non-broadcast mode, used in similar
>    contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
>    been broadcast in Eastern Europe and various parts of Africa and Asia.
>    Uses the same 576i50 timings as PAL.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index e40b55de1b3c..91d343238b0f 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
>   #define VEC_CONFIG0_YDEL(x)		((x) << 26)
>   #define VEC_CONFIG0_CDEL_MASK		GENMASK(25, 24)
>   #define VEC_CONFIG0_CDEL(x)		((x) << 24)
> +#define VEC_CONFIG0_SECAM_STD		BIT(21)
>   #define VEC_CONFIG0_PBPR_FIL		BIT(18)
>   #define VEC_CONFIG0_CHROMA_GAIN_MASK	GENMASK(17, 16)
>   #define VEC_CONFIG0_CHROMA_GAIN_UNITY	(0 << 16)
> @@ -76,6 +77,27 @@
>   #define VEC_SOFT_RESET			0x10c
>   #define VEC_CLMP0_START			0x144
>   #define VEC_CLMP0_END			0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit half-word,
> + * VEC_FREQ3_2 contains the least significant 16-bit half-word.
> + * 0x80000000 seems to be equivalent to the pixel clock
> + * (which itself is the VEC clock divided by 8).
> + *
> + * Reference values (with the default pixel clock of 13.5 MHz):
> + *
> + * NTSC  (3579545.[45] Hz)     - 0x21F07C1F
> + * PAL   (4433618.75 Hz)       - 0x2A098ACB
> + * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
> + * PAL-N (3582056.25 Hz)       - 0x21F69446
> + *
> + * NOTE: For SECAM, it is used as the Dr center frequency,
> + * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
> + * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
> + */
>   #define VEC_FREQ3_2			0x180
>   #define VEC_FREQ1_0			0x184
>   
> @@ -118,6 +140,14 @@
>   
>   #define VEC_INTERRUPT_CONTROL		0x190
>   #define VEC_INTERRUPT_STATUS		0x194
> +
> +/*
> + * Db center frequency for SECAM; the clock for this is the same as for
> + * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
> + *
> + * This is specified as 4250000 Hz, which corresponds to 0x284BDA13.
> + * That is also the default value, so no need to set it explicitly.
> + */
>   #define VEC_FCW_SECAM_B			0x198
>   #define VEC_SECAM_GAIN_VAL		0x19c
>   
> @@ -194,9 +224,13 @@ connector_to_vc4_vec(struct drm_connector *connector)
>   
>   enum vc4_vec_tv_mode_id {
>   	VC4_VEC_TV_MODE_NTSC,
> +	VC4_VEC_TV_MODE_NTSC_443,
>   	VC4_VEC_TV_MODE_NTSC_J,
>   	VC4_VEC_TV_MODE_PAL,
> +	VC4_VEC_TV_MODE_PAL_60,
>   	VC4_VEC_TV_MODE_PAL_M,
> +	VC4_VEC_TV_MODE_PAL_N,
> +	VC4_VEC_TV_MODE_SECAM,
>   };
>   
>   struct vc4_vec_tv_mode {
> @@ -234,6 +268,12 @@ static const struct debugfs_reg32 vec_regs[] = {
>   };
>   
>   static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
> +	{
> +		.mode = DRM_MODE_TV_NORM_NTSC_443,
> +		.config0 = VEC_CONFIG0_NTSC_STD,
> +		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
> +		.custom_freq = 0x2a098acb,
> +	},
>   	{
>   		.mode = DRM_MODE_TV_NORM_NTSC_M,
>   		.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
> @@ -244,6 +284,12 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>   		.config0 = VEC_CONFIG0_NTSC_STD,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
>   	},
> +	{
> +		.mode = DRM_MODE_TV_NORM_PAL_60,
> +		.config0 = VEC_CONFIG0_PAL_M_STD,
> +		.config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
> +		.custom_freq = 0x2a098acb,
> +	},
>   	{
>   		.mode = DRM_MODE_TV_NORM_PAL_B,
>   		.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
> @@ -254,6 +300,17 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
>   		.config0 = VEC_CONFIG0_PAL_M_STD,
>   		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
>   	},
> +	{
> +		.mode = DRM_MODE_TV_NORM_PAL_N,
> +		.config0 = VEC_CONFIG0_PAL_N_STD,
> +		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
> +	},
> +	{
> +		.mode = DRM_MODE_TV_NORM_SECAM_B,
> +		.config0 = VEC_CONFIG0_SECAM_STD,
> +		.config1 = VEC_CONFIG1_C_CVBS_CVBS,
> +		.custom_freq = 0x29c71c72,
> +	},
>   };
>   
>   static inline const struct vc4_vec_tv_mode *
> @@ -273,9 +330,13 @@ vc4_vec_tv_mode_lookup(unsigned int mode)
>   
>   static const struct drm_prop_enum_list tv_mode_names[] = {
>   	{ VC4_VEC_TV_MODE_NTSC, "NTSC", },
> +	{ VC4_VEC_TV_MODE_NTSC_443, "NTSC-443", },
>   	{ VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
>   	{ VC4_VEC_TV_MODE_PAL, "PAL", },
> +	{ VC4_VEC_TV_MODE_PAL_60, "PAL-60", },
>   	{ VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
> +	{ VC4_VEC_TV_MODE_PAL_N, "PAL-N", },
> +	{ VC4_VEC_TV_MODE_SECAM, "SECAM", },
>   };
>   
>   static enum drm_connector_status
> @@ -329,6 +390,10 @@ vc4_vec_connector_set_property(struct drm_connector *connector,
>   		state->tv.norm = DRM_MODE_TV_NORM_NTSC_M;
>   		break;
>   
> +	case VC4_VEC_TV_MODE_NTSC_443:
> +		state->tv.norm = DRM_MODE_TV_NORM_NTSC_443;
> +		break;
> +
>   	case VC4_VEC_TV_MODE_NTSC_J:
>   		state->tv.norm = DRM_MODE_TV_NORM_NTSC_J;
>   		break;
> @@ -337,10 +402,22 @@ vc4_vec_connector_set_property(struct drm_connector *connector,
>   		state->tv.norm = DRM_MODE_TV_NORM_PAL_B;
>   		break;
>   
> +	case VC4_VEC_TV_MODE_PAL_60:
> +		state->tv.norm = DRM_MODE_TV_NORM_PAL_60;
> +		break;
> +
>   	case VC4_VEC_TV_MODE_PAL_M:
>   		state->tv.norm = DRM_MODE_TV_NORM_PAL_M;
>   		break;
>   
> +	case VC4_VEC_TV_MODE_PAL_N:
> +		state->tv.norm = DRM_MODE_TV_NORM_PAL_N;
> +		break;
> +
> +	case VC4_VEC_TV_MODE_SECAM:
> +		state->tv.norm = DRM_MODE_TV_NORM_SECAM_B;
> +		break;
> +
>   	default:
>   		return -EINVAL;
>   	}
> @@ -360,6 +437,10 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
>   		return -EINVAL;
>   
>   	switch (state->tv.norm) {
> +	case DRM_MODE_TV_NORM_NTSC_443:
> +		*val = VC4_VEC_TV_MODE_NTSC_443;
> +		break;
> +
>   	case DRM_MODE_TV_NORM_NTSC_J:
>   		*val = VC4_VEC_TV_MODE_NTSC_J;
>   		break;
> @@ -368,6 +449,10 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
>   		*val = VC4_VEC_TV_MODE_NTSC;
>   		break;
>   
> +	case DRM_MODE_TV_NORM_PAL_60:
> +		*val = VC4_VEC_TV_MODE_PAL_60;
> +		break;
> +
>   	case DRM_MODE_TV_NORM_PAL_B:
>   		*val = VC4_VEC_TV_MODE_PAL;
>   		break;
> @@ -376,6 +461,14 @@ vc4_vec_connector_get_property(struct drm_connector *connector,
>   		*val = VC4_VEC_TV_MODE_PAL_M;
>   		break;
>   
> +	case DRM_MODE_TV_NORM_PAL_N:
> +		*val = VC4_VEC_TV_MODE_PAL_N;
> +		break;
> +
> +	case DRM_MODE_TV_NORM_SECAM_B:
> +		*val = VC4_VEC_TV_MODE_SECAM;
> +		break;
> +
>   	default:
>   		return -EINVAL;
>   	}
> @@ -605,10 +698,13 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
>   	int ret;
>   
>   	ret = drm_mode_create_tv_properties(drm,
> +					    DRM_MODE_TV_NORM_NTSC_443 |
>   					    DRM_MODE_TV_NORM_NTSC_J |
>   					    DRM_MODE_TV_NORM_NTSC_M |
>   					    DRM_MODE_TV_NORM_PAL_B |
> -					    DRM_MODE_TV_NORM_PAL_M,
> +					    DRM_MODE_TV_NORM_PAL_M |
> +					    DRM_MODE_TV_NORM_PAL_N |
> +					    DRM_MODE_TV_NORM_SECAM_B,
>   					    0, NULL);
>   	if (ret)
>   		return ret;
>

Re: [PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards

[Maxime Ripard]

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

Hi,

On Fri, Jul 29, 2022 at 07:55:30PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
> 
> I think that declaring PAL-B and SECAM-B as the only supported 576i
> norms is a bit random.

Starting with this patch, PAL-N should be supported as well, right?

> Norms B, D, G, H, I, K, K1 and L (for both PAL and SECAM) are
> essentially identical if we're talking about baseband signals, AFAIK
> they only differ when those are modulated as RF signals. I'm not sure
> if there's a point to differentiating those (that's more about patch
> 05/35) unless we need to deal with some device that actually features
> an RF modulator.

What I was aiming for is to have all the cases we have in all the
drivers covered so that we can make that property generic. i915
declares and uses all those variants:

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_sdvo.c#L68

Especially since it's i915 and it's pretty much the standard as far as
the uAPI goes, I'd rather avoid any regression there.

> But if we do want to have all those norms separate, then I'd say that
> VC4 should declare support for all of those, and all should map to the
> same VEC settings. Some users from e.g. the UK might think that they
> won't get proper picture if PAL-I is not on the list of supported
> norms. Same goes for e.g. SECAM-D/K in the former Soviet territories,
> and so on.

I'd be open to it, but we can always extend vc4 to support those modes
later on. The work you did to make that easier should make it trivial.

Maxime

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

Re: [PATCH v1 24/35] drm/vc4: vec: Add support for more analog TV standards

[Mateusz Kwiatkowski]

Hi Maxime,

W dniu 15.08.2022 o 10:37, Maxime Ripard pisze:
> Hi,
>
> On Fri, Jul 29, 2022 at 07:55:30PM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> I think that declaring PAL-B and SECAM-B as the only supported 576i
>> norms is a bit random.
>
> Starting with this patch, PAL-N should be supported as well, right?

Oh, sure. I forgot about it. My brain was too focused on the "standard PAL"
modes, which excludes PAL-N.

>
>> Norms B, D, G, H, I, K, K1 and L (for both PAL and SECAM) are
>> essentially identical if we're talking about baseband signals, AFAIK
>> they only differ when those are modulated as RF signals. I'm not sure
>> if there's a point to differentiating those (that's more about patch
>> 05/35) unless we need to deal with some device that actually features
>> an RF modulator.
>
> What I was aiming for is to have all the cases we have in all the
> drivers covered so that we can make that property generic. i915
> declares and uses all those variants:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_sdvo.c#L68
>
> Especially since it's i915 and it's pretty much the standard as far as
> the uAPI goes, I'd rather avoid any regression there.

OK, if there are already drivers that differentiate those, then it doesn't make
sense to introduce regressions. And yes, there is plenty of software already out
there that differentiate between those modes in the context of composite video.
It still doesn't make much sense from the engineering point of view, though.

>
>> But if we do want to have all those norms separate, then I'd say that
>> VC4 should declare support for all of those, and all should map to the
>> same VEC settings. Some users from e.g. the UK might think that they
>> won't get proper picture if PAL-I is not on the list of supported
>> norms. Same goes for e.g. SECAM-D/K in the former Soviet territories,
>> and so on.
>
> I'd be open to it, but we can always extend vc4 to support those modes
> later on. The work you did to make that easier should make it trivial.

Doing that in the future is OK as well. I just wanted to point out that
PAL-B/D/G/H/I/K/K1/L (and same for SECAM) is the same exact thing as far as
baseband composite video is concerned, so declaring only one of those as
supported is potentially misleading for anybody who is not aware of that fact.

>
> Maxime

Best regards,
Mateusz Kwiatkowski

[PATCH v1 25/35] drm/sun4i: tv: Remove unused mode_valid

[Maxime Ripard]

The mode_valid implementation is pretty much a nop, let's remove it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 94883abe0dfd..53152d77c392 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -497,16 +497,8 @@ static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
 	return i;
 }
 
-static int sun4i_tv_comp_mode_valid(struct drm_connector *connector,
-				    struct drm_display_mode *mode)
-{
-	/* TODO */
-	return MODE_OK;
-}
-
 static const struct drm_connector_helper_funcs sun4i_tv_comp_connector_helper_funcs = {
 	.get_modes	= sun4i_tv_comp_get_modes,
-	.mode_valid	= sun4i_tv_comp_mode_valid,
 };
 
 static void

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 25/35] drm/sun4i: tv: Remove unused mode_valid

[Jernej Škrabec]

Dne petek, 29. julij 2022 ob 18:35:08 CEST je Maxime Ripard napisal(a):
> The mode_valid implementation is pretty much a nop, let's remove it.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index 94883abe0dfd..53152d77c392 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -497,16 +497,8 @@ static int sun4i_tv_comp_get_modes(struct drm_connector
> *connector) return i;
>  }
> 
> -static int sun4i_tv_comp_mode_valid(struct drm_connector *connector,
> -				    struct drm_display_mode 
*mode)
> -{
> -	/* TODO */
> -	return MODE_OK;
> -}
> -
>  static const struct drm_connector_helper_funcs
> sun4i_tv_comp_connector_helper_funcs = { .get_modes	=
> sun4i_tv_comp_get_modes,
> -	.mode_valid	= sun4i_tv_comp_mode_valid,
>  };
> 
>  static void

[PATCH v1 26/35] drm/sun4i: tv: Convert to atomic hooks

[Maxime Ripard]

The VC4 VEC driver still uses legacy enable and disable hook
implementation. Let's convert to the atomic variants.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 53152d77c392..f7aad995ab5b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -339,7 +339,8 @@ static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
 	mode->vtotal = mode->vsync_end  + tv_mode->vback_porch;
 }
 
-static void sun4i_tv_disable(struct drm_encoder *encoder)
+static void sun4i_tv_disable(struct drm_encoder *encoder,
+			    struct drm_atomic_state *state)
 {
 	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
 	struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
@@ -353,7 +354,8 @@ static void sun4i_tv_disable(struct drm_encoder *encoder)
 	sunxi_engine_disable_color_correction(crtc->engine);
 }
 
-static void sun4i_tv_enable(struct drm_encoder *encoder)
+static void sun4i_tv_enable(struct drm_encoder *encoder,
+			    struct drm_atomic_state *state)
 {
 	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
 	struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
@@ -469,8 +471,8 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
 }
 
 static const struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
-	.disable	= sun4i_tv_disable,
-	.enable		= sun4i_tv_enable,
+	.atomic_disable	= sun4i_tv_disable,
+	.atomic_enable	= sun4i_tv_enable,
 	.mode_set	= sun4i_tv_mode_set,
 };
 

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 26/35] drm/sun4i: tv: Convert to atomic hooks

[Jernej Škrabec]

Dne petek, 29. julij 2022 ob 18:35:09 CEST je Maxime Ripard napisal(a):
> The VC4 VEC driver still uses legacy enable and disable hook

s/VC4 VEC/sun4i tv/

Best regards,
Jernej

> implementation. Let's convert to the atomic variants.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index 53152d77c392..f7aad995ab5b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -339,7 +339,8 @@ static void sun4i_tv_mode_to_drm_mode(const struct
> tv_mode *tv_mode, mode->vtotal = mode->vsync_end  + tv_mode->vback_porch;
>  }
> 
> -static void sun4i_tv_disable(struct drm_encoder *encoder)
> +static void sun4i_tv_disable(struct drm_encoder *encoder,
> +			    struct drm_atomic_state *state)
>  {
>  	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
>  	struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
> @@ -353,7 +354,8 @@ static void sun4i_tv_disable(struct drm_encoder
> *encoder) sunxi_engine_disable_color_correction(crtc->engine);
>  }
> 
> -static void sun4i_tv_enable(struct drm_encoder *encoder)
> +static void sun4i_tv_enable(struct drm_encoder *encoder,
> +			    struct drm_atomic_state *state)
>  {
>  	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
>  	struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
> @@ -469,8 +471,8 @@ static void sun4i_tv_mode_set(struct drm_encoder
> *encoder, }
> 
>  static const struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
> -	.disable	= sun4i_tv_disable,
> -	.enable		= sun4i_tv_enable,
> +	.atomic_disable	= sun4i_tv_disable,
> +	.atomic_enable	= sun4i_tv_enable,
>  	.mode_set	= sun4i_tv_mode_set,
>  };

[PATCH v1 27/35] drm/sun4i: tv: Merge mode_set into atomic_enable

[Maxime Ripard]

Our mode_set implementation can be merged into our atomic_enable
implementation to simplify things, so let's do this.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index f7aad995ab5b..3944da9a3c34 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -359,23 +359,13 @@ static void sun4i_tv_enable(struct drm_encoder *encoder,
 {
 	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
 	struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
-
-	DRM_DEBUG_DRIVER("Enabling the TV Output\n");
-
-	sunxi_engine_apply_color_correction(crtc->engine);
-
-	regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
-			   SUN4I_TVE_EN_ENABLE,
-			   SUN4I_TVE_EN_ENABLE);
-}
-
-static void sun4i_tv_mode_set(struct drm_encoder *encoder,
-			      struct drm_display_mode *mode,
-			      struct drm_display_mode *adjusted_mode)
-{
-	struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
+	struct drm_crtc_state *crtc_state =
+		drm_atomic_get_new_crtc_state(state, encoder->crtc);
+	struct drm_display_mode *mode = &crtc_state->mode;
 	const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
 
+	DRM_DEBUG_DRIVER("Enabling the TV Output\n");
+
 	/* Enable and map the DAC to the output */
 	regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
 			   SUN4I_TVE_EN_DAC_MAP_MASK,
@@ -468,12 +458,17 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
 		      SUN4I_TVE_RESYNC_FIELD : 0));
 
 	regmap_write(tv->regs, SUN4I_TVE_SLAVE_REG, 0);
+
+	sunxi_engine_apply_color_correction(crtc->engine);
+
+	regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
+			   SUN4I_TVE_EN_ENABLE,
+			   SUN4I_TVE_EN_ENABLE);
 }
 
 static const struct drm_encoder_helper_funcs sun4i_tv_helper_funcs = {
 	.atomic_disable	= sun4i_tv_disable,
 	.atomic_enable	= sun4i_tv_enable,
-	.mode_set	= sun4i_tv_mode_set,
 };
 
 static int sun4i_tv_comp_get_modes(struct drm_connector *connector)

-- 
b4 0.10.0-dev-49460

[PATCH v1 28/35] drm/sun4i: tv: Remove useless function

[Maxime Ripard]

The drm_connector_to_sun4i_tv() function isn't used anywhere in the driver,
so let's remove it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 3944da9a3c34..52bbba8f19dc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -275,13 +275,6 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
 			    encoder);
 }
 
-static inline struct sun4i_tv *
-drm_connector_to_sun4i_tv(struct drm_connector *connector)
-{
-	return container_of(connector, struct sun4i_tv,
-			    connector);
-}
-
 /*
  * FIXME: If only the drm_display_mode private field was usable, this
  * could go away...

-- 
b4 0.10.0-dev-49460

[PATCH v1 29/35] drm/sun4i: tv: Remove useless destroy function

[Maxime Ripard]

Our destroy implementation is just calling the generic helper, so let's
just remove our function and directly use the helper.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 52bbba8f19dc..6d7e1d51569a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -491,15 +491,9 @@ static const struct drm_connector_helper_funcs sun4i_tv_comp_connector_helper_fu
 	.get_modes	= sun4i_tv_comp_get_modes,
 };
 
-static void
-sun4i_tv_comp_connector_destroy(struct drm_connector *connector)
-{
-	drm_connector_cleanup(connector);
-}
-
 static const struct drm_connector_funcs sun4i_tv_comp_connector_funcs = {
 	.fill_modes		= drm_helper_probe_single_connector_modes,
-	.destroy		= sun4i_tv_comp_connector_destroy,
+	.destroy		= drm_connector_cleanup,
 	.reset			= drm_atomic_helper_connector_reset,
 	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 29/35] drm/sun4i: tv: Remove useless destroy function

[Jernej Škrabec]

Dne petek, 29. julij 2022 ob 18:35:12 CEST je Maxime Ripard napisal(a):
> Our destroy implementation is just calling the generic helper, so let's
> just remove our function and directly use the helper.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index 52bbba8f19dc..6d7e1d51569a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -491,15 +491,9 @@ static const struct drm_connector_helper_funcs
> sun4i_tv_comp_connector_helper_fu .get_modes	= sun4i_tv_comp_get_modes,
>  };
> 
> -static void
> -sun4i_tv_comp_connector_destroy(struct drm_connector *connector)
> -{
> -	drm_connector_cleanup(connector);
> -}
> -
>  static const struct drm_connector_funcs sun4i_tv_comp_connector_funcs = {
>  	.fill_modes		= drm_helper_probe_single_connector_modes,
> -	.destroy		= sun4i_tv_comp_connector_destroy,
> +	.destroy		= drm_connector_cleanup,
>  	.reset			= 
drm_atomic_helper_connector_reset,
>  	.atomic_duplicate_state	= 
drm_atomic_helper_connector_duplicate_state,
>  	.atomic_destroy_state	= 
drm_atomic_helper_connector_destroy_state,

[PATCH v1 30/35] drm/sun4i: tv: Rename error label

[Maxime Ripard]

The other error labels in sun4i_tv_bind() are named after the task they
perform (err_disable_clk to call clk_disable_unprepare for example).

However, the err_cleanup_connector is named after the calling site
(drm_connector_init failing) and will actually cleanup the encoder. Let's
rename it to err_cleanup_encoder to be consistent.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 6d7e1d51569a..ad6a3739bfa9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -580,7 +580,7 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
 	if (ret) {
 		dev_err(dev,
 			"Couldn't initialise the Composite connector\n");
-		goto err_cleanup_connector;
+		goto err_cleanup_encoder;
 	}
 	tv->connector.interlace_allowed = true;
 
@@ -588,7 +588,7 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
 
 	return 0;
 
-err_cleanup_connector:
+err_cleanup_encoder:
 	drm_encoder_cleanup(&tv->encoder);
 err_disable_clk:
 	clk_disable_unprepare(tv->clk);

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 30/35] drm/sun4i: tv: Rename error label

[Jernej Škrabec]

Dne petek, 29. julij 2022 ob 18:35:13 CEST je Maxime Ripard napisal(a):
> The other error labels in sun4i_tv_bind() are named after the task they
> perform (err_disable_clk to call clk_disable_unprepare for example).
> 
> However, the err_cleanup_connector is named after the calling site
> (drm_connector_init failing) and will actually cleanup the encoder. Let's
> rename it to err_cleanup_encoder to be consistent.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index 6d7e1d51569a..ad6a3739bfa9 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -580,7 +580,7 @@ static int sun4i_tv_bind(struct device *dev, struct
> device *master, if (ret) {
>  		dev_err(dev,
>  			"Couldn't initialise the Composite 
connector\n");
> -		goto err_cleanup_connector;
> +		goto err_cleanup_encoder;
>  	}
>  	tv->connector.interlace_allowed = true;
> 
> @@ -588,7 +588,7 @@ static int sun4i_tv_bind(struct device *dev, struct
> device *master,
> 
>  	return 0;
> 
> -err_cleanup_connector:
> +err_cleanup_encoder:
>  	drm_encoder_cleanup(&tv->encoder);
>  err_disable_clk:
>  	clk_disable_unprepare(tv->clk);

[PATCH v1 31/35] drm/sun4i: tv: Add missing reset assertion

[Maxime Ripard]

The reset line is deasserted at bind, and asserted if we ever encounter an
error there. However, it's never deasserted in unbind which will lead to a
resource unbalance.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index ad6a3739bfa9..74ff5ad6a8b9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -605,6 +605,7 @@ static void sun4i_tv_unbind(struct device *dev, struct device *master,
 	drm_connector_cleanup(&tv->connector);
 	drm_encoder_cleanup(&tv->encoder);
 	clk_disable_unprepare(tv->clk);
+	reset_control_assert(tv->reset);
 }
 
 static const struct component_ops sun4i_tv_ops = {

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 31/35] drm/sun4i: tv: Add missing reset assertion

[Jernej Škrabec]

Dne petek, 29. julij 2022 ob 18:35:14 CEST je Maxime Ripard napisal(a):
> The reset line is deasserted at bind, and asserted if we ever encounter an
> error there. However, it's never deasserted in unbind which will lead to a

s/deasserted/asserted/

Once fixed:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> resource unbalance.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> b/drivers/gpu/drm/sun4i/sun4i_tv.c index ad6a3739bfa9..74ff5ad6a8b9 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -605,6 +605,7 @@ static void sun4i_tv_unbind(struct device *dev, struct
> device *master, drm_connector_cleanup(&tv->connector);
>  	drm_encoder_cleanup(&tv->encoder);
>  	clk_disable_unprepare(tv->clk);
> +	reset_control_assert(tv->reset);
>  }
> 
>  static const struct component_ops sun4i_tv_ops = {

[PATCH v1 32/35] drm/sun4i: tv: Convert to the new TV mode property

[Maxime Ripard]

Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 74ff5ad6a8b9..bed52423776e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -140,23 +140,15 @@ struct resync_parameters {
 struct tv_mode {
 	char		*name;
 
+	unsigned int	tv_mode;
+	const struct drm_display_mode	*display_mode;
+
 	u32		mode;
 	u32		chroma_freq;
 	u16		back_porch;
 	u16		front_porch;
-	u16		line_number;
 	u16		vblank_level;
 
-	u32		hdisplay;
-	u16		hfront_porch;
-	u16		hsync_len;
-	u16		hback_porch;
-
-	u32		vdisplay;
-	u16		vfront_porch;
-	u16		vsync_len;
-	u16		vback_porch;
-
 	bool		yc_en;
 	bool		dac3_en;
 	bool		dac_bit25_en;
@@ -212,7 +204,8 @@ static const struct resync_parameters pal_resync_parameters = {
 
 static const struct tv_mode tv_modes[] = {
 	{
-		.name		= "NTSC",
+		.tv_mode	= DRM_MODE_TV_NORM_NTSC_M,
+		.display_mode	= &drm_mode_480i,
 		.mode		= SUN4I_TVE_CFG0_RES_480i,
 		.chroma_freq	= 0x21f07c1f,
 		.yc_en		= true,
@@ -221,17 +214,6 @@ static const struct tv_mode tv_modes[] = {
 
 		.back_porch	= 118,
 		.front_porch	= 32,
-		.line_number	= 525,
-
-		.hdisplay	= 720,
-		.hfront_porch	= 18,
-		.hsync_len	= 2,
-		.hback_porch	= 118,
-
-		.vdisplay	= 480,
-		.vfront_porch	= 26,
-		.vsync_len	= 2,
-		.vback_porch	= 17,
 
 		.vblank_level	= 240,
 
@@ -241,23 +223,13 @@ static const struct tv_mode tv_modes[] = {
 		.resync_params	= &ntsc_resync_parameters,
 	},
 	{
-		.name		= "PAL",
+		.tv_mode	= DRM_MODE_TV_NORM_PAL_B,
+		.display_mode	= &drm_mode_576i,
 		.mode		= SUN4I_TVE_CFG0_RES_576i,
 		.chroma_freq	= 0x2a098acb,
 
 		.back_porch	= 138,
 		.front_porch	= 24,
-		.line_number	= 625,
-
-		.hdisplay	= 720,
-		.hfront_porch	= 3,
-		.hsync_len	= 2,
-		.hback_porch	= 139,
-
-		.vdisplay	= 576,
-		.vfront_porch	= 28,
-		.vsync_len	= 2,
-		.vback_porch	= 19,
 
 		.vblank_level	= 252,
 
@@ -275,63 +247,21 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
 			    encoder);
 }
 
-/*
- * FIXME: If only the drm_display_mode private field was usable, this
- * could go away...
- *
- * So far, it doesn't seem to be preserved when the mode is passed by
- * to mode_set for some reason.
- */
-static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct drm_display_mode *mode)
+static const struct tv_mode *
+sun4i_tv_find_tv_by_mode(unsigned int mode)
 {
 	int i;
 
-	/* First try to identify the mode by name */
 	for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
 		const struct tv_mode *tv_mode = &tv_modes[i];
 
-		DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
-				 mode->name, tv_mode->name);
-
-		if (!strcmp(mode->name, tv_mode->name))
-			return tv_mode;
-	}
-
-	/* Then by number of lines */
-	for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
-		const struct tv_mode *tv_mode = &tv_modes[i];
-
-		DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs %d)",
-				 mode->name, tv_mode->name,
-				 mode->vdisplay, tv_mode->vdisplay);
-
-		if (mode->vdisplay == tv_mode->vdisplay)
+		if (tv_mode->tv_mode == mode)
 			return tv_mode;
 	}
 
 	return NULL;
 }
 
-static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
-				      struct drm_display_mode *mode)
-{
-	DRM_DEBUG_DRIVER("Creating mode %s\n", mode->name);
-
-	mode->type = DRM_MODE_TYPE_DRIVER;
-	mode->clock = 13500;
-	mode->flags = DRM_MODE_FLAG_INTERLACE;
-
-	mode->hdisplay = tv_mode->hdisplay;
-	mode->hsync_start = mode->hdisplay + tv_mode->hfront_porch;
-	mode->hsync_end = mode->hsync_start + tv_mode->hsync_len;
-	mode->htotal = mode->hsync_end  + tv_mode->hback_porch;
-
-	mode->vdisplay = tv_mode->vdisplay;
-	mode->vsync_start = mode->vdisplay + tv_mode->vfront_porch;
-	mode->vsync_end = mode->vsync_start + tv_mode->vsync_len;
-	mode->vtotal = mode->vsync_end  + tv_mode->vback_porch;
-}
-
 static void sun4i_tv_disable(struct drm_encoder *encoder,
 			    struct drm_atomic_state *state)
 {
@@ -355,7 +285,11 @@ static void sun4i_tv_enable(struct drm_encoder *encoder,
 	struct drm_crtc_state *crtc_state =
 		drm_atomic_get_new_crtc_state(state, encoder->crtc);
 	struct drm_display_mode *mode = &crtc_state->mode;
-	const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
+	struct drm_connector *connector = &tv->connector;
+	struct drm_connector_state *conn_state =
+		drm_atomic_get_new_connector_state(state, connector);
+	const struct tv_mode *tv_mode =
+		sun4i_tv_find_tv_by_mode(conn_state->tv.norm);
 
 	DRM_DEBUG_DRIVER("Enabling the TV Output\n");
 
@@ -403,7 +337,7 @@ static void sun4i_tv_enable(struct drm_encoder *encoder,
 	/* Set the lines setup */
 	regmap_write(tv->regs, SUN4I_TVE_LINE_REG,
 		     SUN4I_TVE_LINE_FIRST(22) |
-		     SUN4I_TVE_LINE_NUMBER(tv_mode->line_number));
+		     SUN4I_TVE_LINE_NUMBER(mode->vtotal));
 
 	regmap_write(tv->regs, SUN4I_TVE_LEVEL_REG,
 		     SUN4I_TVE_LEVEL_BLANK(tv_mode->video_levels->blank) |
@@ -472,15 +406,12 @@ static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
 		struct drm_display_mode *mode;
 		const struct tv_mode *tv_mode = &tv_modes[i];
 
-		mode = drm_mode_create(connector->dev);
+		mode = drm_mode_duplicate(connector->dev, tv_mode->display_mode);
 		if (!mode) {
 			DRM_ERROR("Failed to create a new display mode\n");
 			return 0;
 		}
 
-		strcpy(mode->name, tv_mode->name);
-
-		sun4i_tv_mode_to_drm_mode(tv_mode, mode);
 		drm_mode_probed_add(connector, mode);
 	}
 
@@ -488,13 +419,20 @@ static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
 }
 
 static const struct drm_connector_helper_funcs sun4i_tv_comp_connector_helper_funcs = {
+	.atomic_check	= drm_atomic_helper_connector_tv_check,
 	.get_modes	= sun4i_tv_comp_get_modes,
 };
 
+static void sun4i_tv_connector_reset(struct drm_connector *connector)
+{
+	drm_atomic_helper_connector_reset(connector);
+	drm_atomic_helper_connector_tv_reset(connector);
+}
+
 static const struct drm_connector_funcs sun4i_tv_comp_connector_funcs = {
 	.fill_modes		= drm_helper_probe_single_connector_modes,
 	.destroy		= drm_connector_cleanup,
-	.reset			= drm_atomic_helper_connector_reset,
+	.reset			= sun4i_tv_connector_reset,
 	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
 	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
 };
@@ -586,8 +524,17 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
 
 	drm_connector_attach_encoder(&tv->connector, &tv->encoder);
 
+	ret = drm_mode_create_tv_properties(drm,
+					    DRM_MODE_TV_NORM_NTSC_M |
+					    DRM_MODE_TV_NORM_PAL_B,
+					    0, NULL);
+	if (ret)
+		goto err_cleanup_connector;
+
 	return 0;
 
+err_cleanup_connector:
+	drm_connector_cleanup(&tv->connector);
 err_cleanup_encoder:
 	drm_encoder_cleanup(&tv->encoder);
 err_disable_clk:

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 32/35] drm/sun4i: tv: Convert to the new TV mode property

[Noralf Trønnes]

Den 29.07.2022 18.35, skrev Maxime Ripard:
> Now that the core can deal fine with analog TV modes, let's convert the
> sun4i TV driver to leverage those new features.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 74ff5ad6a8b9..bed52423776e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c

> @@ -586,8 +524,17 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
>  
>  	drm_connector_attach_encoder(&tv->connector, &tv->encoder);
>  
> +	ret = drm_mode_create_tv_properties(drm,
> +					    DRM_MODE_TV_NORM_NTSC_M |
> +					    DRM_MODE_TV_NORM_PAL_B,
> +					    0, NULL);
> +	if (ret)
> +		goto err_cleanup_connector;
> +

Looks like you have forgotten to attach the property?

Noralf.

>  	return 0;
>  
> +err_cleanup_connector:
> +	drm_connector_cleanup(&tv->connector);
>  err_cleanup_encoder:
>  	drm_encoder_cleanup(&tv->encoder);
>  err_disable_clk:
> 

[PATCH v1 33/35] drm/connector: Remove TV modes property

[Maxime Ripard]

Now that all the other drivers have been converted to the new style TV mode
property, let's get rid of the old one.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index d7ff6c644c2f..d52e87e8e6aa 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -698,8 +698,6 @@ static int drm_atomic_connector_set_property(struct drm_connector *connector,
 		state->tv.margins.top = val;
 	} else if (property == config->tv_bottom_margin_property) {
 		state->tv.margins.bottom = val;
-	} else if (property == config->tv_mode_property) {
-		state->tv.mode = val;
 	} else if (property == config->tv_norm_property) {
 		state->tv.norm = val;
 	} else if (property == config->tv_brightness_property) {
@@ -810,8 +808,6 @@ drm_atomic_connector_get_property(struct drm_connector *connector,
 		*val = state->tv.margins.top;
 	} else if (property == config->tv_bottom_margin_property) {
 		*val = state->tv.margins.bottom;
-	} else if (property == config->tv_mode_property) {
-		*val = state->tv.mode;
 	} else if (property == config->tv_norm_property) {
 		*val = state->tv.norm;
 	} else if (property == config->tv_brightness_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d73a68764b6e..5e138159f2de 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1650,9 +1650,7 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * 0 on success or a negative error code on failure.
  */
 int drm_mode_create_tv_properties(struct drm_device *dev,
-				  unsigned int supported_tv_norms,
-				  unsigned int num_modes,
-				  const char * const modes[])
+				  unsigned int supported_tv_norms)
 {
 	static const struct drm_prop_enum_list tv_norm_values[] = {
 		{ __builtin_ffs(DRM_MODE_TV_NORM_NTSC_443) - 1, "NTSC-443" },
@@ -1722,20 +1720,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 		goto nomem;
 	dev->mode_config.tv_norm_property = tv_norm;
 
-	if (num_modes) {
-		unsigned int i;
-
-		dev->mode_config.tv_mode_property =
-			drm_property_create(dev, DRM_MODE_PROP_ENUM,
-					    "mode", num_modes);
-		if (!dev->mode_config.tv_mode_property)
-			goto nomem;
-
-		for (i = 0; i < num_modes; i++)
-			drm_property_add_enum(dev->mode_config.tv_mode_property,
-					      i, modes[i]);
-	}
-
 	dev->mode_config.tv_brightness_property =
 		drm_property_create_range(dev, 0, "brightness", 0, 100);
 	if (!dev->mode_config.tv_brightness_property)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index bed52423776e..1d4025663530 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -526,8 +526,7 @@ static int sun4i_tv_bind(struct device *dev, struct device *master,
 
 	ret = drm_mode_create_tv_properties(drm,
 					    DRM_MODE_TV_NORM_NTSC_M |
-					    DRM_MODE_TV_NORM_PAL_B,
-					    0, NULL);
+					    DRM_MODE_TV_NORM_PAL_B);
 	if (ret)
 		goto err_cleanup_connector;
 
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 91d343238b0f..2e7e964928b3 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -704,8 +704,7 @@ static int vc4_vec_bind(struct device *dev, struct device *master, void *data)
 					    DRM_MODE_TV_NORM_PAL_B |
 					    DRM_MODE_TV_NORM_PAL_M |
 					    DRM_MODE_TV_NORM_PAL_N |
-					    DRM_MODE_TV_NORM_SECAM_B,
-					    0, NULL);
+					    DRM_MODE_TV_NORM_SECAM_B);
 	if (ret)
 		return ret;
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 78275e68ff66..e535dca6376e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -712,7 +712,6 @@ struct drm_tv_connector_state {
 	enum drm_mode_subconnector select_subconnector;
 	enum drm_mode_subconnector subconnector;
 	struct drm_connector_tv_margins margins;
-	unsigned int mode;
 	unsigned int norm;
 	unsigned int brightness;
 	unsigned int contrast;
@@ -1806,9 +1805,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
 
 int drm_mode_create_tv_margin_properties(struct drm_device *dev);
 int drm_mode_create_tv_properties(struct drm_device *dev,
-				  unsigned int supported_tv_norms,
-				  unsigned int num_modes,
-				  const char * const modes[]);
+				  unsigned int supported_tv_norms);
 void drm_connector_attach_tv_margin_properties(struct drm_connector *conn);
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_connector_attach_content_type_property(struct drm_connector *dev);

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 33/35] drm/connector: Remove TV modes property

[kernel test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on 37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
base:   37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9
config: hexagon-randconfig-r041-20220729 (https://download.01.org/0day-ci/archive/20220730/202207300305.EGSDOjh4-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 8dfaecc4c24494337933aff9d9166486ca0949f1)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/intel-lab-lkp/linux/commit/83327cd72054a9c8d02b6f632453a8bdc90d3797
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
        git checkout 83327cd72054a9c8d02b6f632453a8bdc90d3797
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/i2c/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/i2c/ch7006_drv.c:253:51: error: too many arguments to function call, expected 2, have 3
           drm_mode_create_tv_properties(dev, NUM_TV_NORMS, ch7006_tv_norm_names);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                    ^~~~~~~~~~~~~~~~~~~~
   include/drm/drm_connector.h:1807:5: note: 'drm_mode_create_tv_properties' declared here
   int drm_mode_create_tv_properties(struct drm_device *dev,
       ^
   1 error generated.


vim +253 drivers/gpu/drm/i2c/ch7006_drv.c

6ee738610f41b5 Ben Skeggs   2009-12-11  245  
6ee738610f41b5 Ben Skeggs   2009-12-11  246  static int ch7006_encoder_create_resources(struct drm_encoder *encoder,
6ee738610f41b5 Ben Skeggs   2009-12-11  247  					   struct drm_connector *connector)
6ee738610f41b5 Ben Skeggs   2009-12-11  248  {
6ee738610f41b5 Ben Skeggs   2009-12-11  249  	struct ch7006_priv *priv = to_ch7006_priv(encoder);
6ee738610f41b5 Ben Skeggs   2009-12-11  250  	struct drm_device *dev = encoder->dev;
6ee738610f41b5 Ben Skeggs   2009-12-11  251  	struct drm_mode_config *conf = &dev->mode_config;
6ee738610f41b5 Ben Skeggs   2009-12-11  252  
6ee738610f41b5 Ben Skeggs   2009-12-11 @253  	drm_mode_create_tv_properties(dev, NUM_TV_NORMS, ch7006_tv_norm_names);
6ee738610f41b5 Ben Skeggs   2009-12-11  254  
d9bc3c02e36d84 Sascha Hauer 2012-02-06  255  	priv->scale_property = drm_property_create_range(dev, 0, "scale", 0, 2);
44084efc2fd804 Insu Yun     2016-01-28  256  	if (!priv->scale_property)
44084efc2fd804 Insu Yun     2016-01-28  257  		return -ENOMEM;
6ee738610f41b5 Ben Skeggs   2009-12-11  258  
ec61c71d0dba24 Rob Clark    2012-10-11  259  	drm_object_attach_property(&connector->base, conf->tv_select_subconnector_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  260  				      priv->select_subconnector);
ec61c71d0dba24 Rob Clark    2012-10-11  261  	drm_object_attach_property(&connector->base, conf->tv_subconnector_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  262  				      priv->subconnector);
ec61c71d0dba24 Rob Clark    2012-10-11  263  	drm_object_attach_property(&connector->base, conf->tv_left_margin_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  264  				      priv->hmargin);
ec61c71d0dba24 Rob Clark    2012-10-11  265  	drm_object_attach_property(&connector->base, conf->tv_bottom_margin_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  266  				      priv->vmargin);
ec61c71d0dba24 Rob Clark    2012-10-11  267  	drm_object_attach_property(&connector->base, conf->tv_mode_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  268  				      priv->norm);
ec61c71d0dba24 Rob Clark    2012-10-11  269  	drm_object_attach_property(&connector->base, conf->tv_brightness_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  270  				      priv->brightness);
ec61c71d0dba24 Rob Clark    2012-10-11  271  	drm_object_attach_property(&connector->base, conf->tv_contrast_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  272  				      priv->contrast);
ec61c71d0dba24 Rob Clark    2012-10-11  273  	drm_object_attach_property(&connector->base, conf->tv_flicker_reduction_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  274  				      priv->flicker);
ec61c71d0dba24 Rob Clark    2012-10-11  275  	drm_object_attach_property(&connector->base, priv->scale_property,
6ee738610f41b5 Ben Skeggs   2009-12-11  276  				      priv->scale);
6ee738610f41b5 Ben Skeggs   2009-12-11  277  
6ee738610f41b5 Ben Skeggs   2009-12-11  278  	return 0;
6ee738610f41b5 Ben Skeggs   2009-12-11  279  }
6ee738610f41b5 Ben Skeggs   2009-12-11  280  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH v1 33/35] drm/connector: Remove TV modes property

[kernel test robot]

Hi Maxime,

I love your patch! Yet something to improve:

[auto build test ERROR on 37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9]

url:    https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
base:   37b355fdaf31ee18bda9a93c2a438dc1cbf57ec9
config: riscv-randconfig-r042-20220729 (https://download.01.org/0day-ci/archive/20220730/202207300454.3rIc8wpM-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 8dfaecc4c24494337933aff9d9166486ca0949f1)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install riscv cross compiling tool for clang build
        # apt-get install binutils-riscv-linux-gnu
        # https://github.com/intel-lab-lkp/linux/commit/83327cd72054a9c8d02b6f632453a8bdc90d3797
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Maxime-Ripard/drm-Analog-TV-Improvements/20220730-004859
        git checkout 83327cd72054a9c8d02b6f632453a8bdc90d3797
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/gpu/drm/

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/nouveau/dispnv04/tvnv17.c:656:51: error: too many arguments to function call, expected 2, have 3
           drm_mode_create_tv_properties(dev, num_tv_norms, nv17_tv_norm_names);
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                    ^~~~~~~~~~~~~~~~~~
   include/drm/drm_connector.h:1807:5: note: 'drm_mode_create_tv_properties' declared here
   int drm_mode_create_tv_properties(struct drm_device *dev,
       ^
   1 error generated.


vim +656 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c

6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  633  
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  634  static int nv17_tv_create_resources(struct drm_encoder *encoder,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  635  				    struct drm_connector *connector)
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  636  {
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  637  	struct drm_device *dev = encoder->dev;
77145f1cbdf8d2 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2012-07-31  638  	struct nouveau_drm *drm = nouveau_drm(dev);
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  639  	struct drm_mode_config *conf = &dev->mode_config;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  640  	struct nv17_tv_encoder *tv_enc = to_tv_enc(encoder);
cb75d97e9c7774 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2012-07-11  641  	struct dcb_output *dcb = nouveau_encoder(encoder)->dcb;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  642  	int num_tv_norms = dcb->tvconf.has_component_output ? NUM_TV_NORMS :
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  643  							NUM_LD_TV_NORMS;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  644  	int i;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  645  
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  646  	if (nouveau_tv_norm) {
2574c809d7c0f0 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c YueHaibing 2019-12-30  647  		i = match_string(nv17_tv_norm_names, num_tv_norms,
2574c809d7c0f0 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c YueHaibing 2019-12-30  648  				 nouveau_tv_norm);
2574c809d7c0f0 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c YueHaibing 2019-12-30  649  		if (i < 0)
77145f1cbdf8d2 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2012-07-31  650  			NV_WARN(drm, "Invalid TV norm setting \"%s\"\n",
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  651  				nouveau_tv_norm);
2574c809d7c0f0 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c YueHaibing 2019-12-30  652  		else
2574c809d7c0f0 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c YueHaibing 2019-12-30  653  			tv_enc->tv_norm = i;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  654  	}
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  655  
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11 @656  	drm_mode_create_tv_properties(dev, num_tv_norms, nv17_tv_norm_names);
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  657  
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  658  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  659  					conf->tv_select_subconnector_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  660  					tv_enc->select_subconnector);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  661  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  662  					conf->tv_subconnector_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  663  					tv_enc->subconnector);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  664  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  665  					conf->tv_mode_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  666  					tv_enc->tv_norm);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  667  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  668  					conf->tv_flicker_reduction_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  669  					tv_enc->flicker);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  670  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  671  					conf->tv_saturation_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  672  					tv_enc->saturation);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  673  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  674  					conf->tv_hue_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  675  					tv_enc->hue);
2db83827dc7679 drivers/gpu/drm/nouveau/nv17_tv.c         Rob Clark  2012-10-11  676  	drm_object_attach_property(&connector->base,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  677  					conf->tv_overscan_property,
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  678  					tv_enc->overscan);
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  679  
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  680  	return 0;
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  681  }
6ee738610f41b5 drivers/gpu/drm/nouveau/nv17_tv.c         Ben Skeggs 2009-12-11  682  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Maxime Ripard]

Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.

Let's add some code to allow it, and some unit tests to exercise that code.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index fce5569bd66a..49da8d8236f5 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -490,6 +490,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
 {
 	struct drm_device *dev = connector->dev;
+	struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
 	struct drm_connector_state *state = connector->state;
 	struct drm_property *prop;
 	uint64_t val;
@@ -500,6 +501,9 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
 							   prop, &val))
 			state->tv.norm = val;
 
+	if (cmdline->tv_mode)
+		state->tv.norm = cmdline->tv_mode;
+
 	prop = dev->mode_config.tv_select_subconnector_property;
 	if (prop)
 		if (!drm_object_property_get_default_value(&connector->base,
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ecb2e83cf860..3634ac9f787d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1677,6 +1677,80 @@ static int drm_mode_parse_panel_orientation(const char *delim,
 	return 0;
 }
 
+#define TV_OPTION_EQUAL(value, len, option) \
+	((strlen(option) == len) && !strncmp(value, option, len))
+
+static int drm_mode_parse_tv_mode(const char *delim,
+				  struct drm_cmdline_mode *mode)
+{
+	const char *value;
+	unsigned int len;
+
+	if (*delim != '=')
+		return -EINVAL;
+
+	value = delim + 1;
+	delim = strchr(value, ',');
+	if (!delim)
+		delim = value + strlen(value);
+
+	len = delim - value;
+	if (TV_OPTION_EQUAL(value, len, "NTSC-443"))
+		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_443;
+	else if (TV_OPTION_EQUAL(value, len, "NTSC-J"))
+		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_J;
+	else if (TV_OPTION_EQUAL(value, len, "NTSC-M"))
+		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_M;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-60"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_60;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-B"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_B;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-D"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_D;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-G"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_G;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-H"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_H;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-I"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_I;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-M"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_M;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-N"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_N;
+	else if (TV_OPTION_EQUAL(value, len, "PAL-NC"))
+		mode->tv_mode = DRM_MODE_TV_NORM_PAL_NC;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-60"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_60;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-B"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_B;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-D"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_D;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-G"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_G;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-K"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_K;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-K1"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_K1;
+	else if (TV_OPTION_EQUAL(value, len, "SECAM-L"))
+		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_L;
+	else if (TV_OPTION_EQUAL(value, len, "HD480I"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD480I;
+	else if (TV_OPTION_EQUAL(value, len, "HD480P"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD480P;
+	else if (TV_OPTION_EQUAL(value, len, "HD576I"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD576I;
+	else if (TV_OPTION_EQUAL(value, len, "HD576P"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD576P;
+	else if (TV_OPTION_EQUAL(value, len, "HD720P"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD720P;
+	else if (TV_OPTION_EQUAL(value, len, "HD1080I"))
+		mode->tv_mode = DRM_MODE_TV_NORM_HD1080I;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static int drm_mode_parse_cmdline_options(const char *str,
 					  bool freestanding,
 					  const struct drm_connector *connector,
@@ -1746,6 +1820,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
 		} else if (!strncmp(option, "panel_orientation", delim - option)) {
 			if (drm_mode_parse_panel_orientation(delim, mode))
 				return -EINVAL;
+		} else if (!strncmp(option, "tv_mode", delim - option)) {
+			if (drm_mode_parse_tv_mode(delim, mode))
+				return -EINVAL;
 		} else {
 			return -EINVAL;
 		}
@@ -1771,11 +1848,12 @@ static int drm_mode_parse_cmdline_options(const char *str,
 struct drm_named_mode {
 	const char *name;
 	const struct drm_display_mode *mode;
+	unsigned int tv_mode;
 };
 
 static const struct drm_named_mode drm_named_modes[] = {
-	{ "NTSC", &drm_mode_480i, },
-	{ "PAL", &drm_mode_576i, },
+	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
+	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
 };
 
 static bool drm_mode_parse_cmdline_named_mode(const char *name,
@@ -1796,6 +1874,7 @@ static bool drm_mode_parse_cmdline_named_mode(const char *name,
 		cmdline_mode->xres = mode->mode->hdisplay;
 		cmdline_mode->yres = mode->mode->vdisplay;
 		cmdline_mode->interlace = !!(mode->mode->flags & DRM_MODE_FLAG_INTERLACE);
+		cmdline_mode->tv_mode = mode->tv_mode;
 		cmdline_mode->specified = true;
 
 		return true;
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 59b29cdfdd35..d198717c8375 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -885,6 +885,274 @@ static void drm_cmdline_test_multiple_options(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
 }
 
+static void drm_cmdline_test_tv_options(struct kunit *test,
+					const char *cmdline,
+					const struct drm_display_mode *expected_mode,
+					unsigned int expected_tv_mode)
+{
+	struct drm_cmdline_mode mode = { };
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_parse_command_line_for_connector(cmdline,
+									  &no_connector, &mode));
+	KUNIT_EXPECT_TRUE(test, mode.specified);
+	KUNIT_EXPECT_EQ(test, mode.xres, expected_mode->hdisplay);
+	KUNIT_EXPECT_EQ(test, mode.yres, expected_mode->vdisplay);
+	KUNIT_EXPECT_EQ(test, mode.tv_mode, expected_tv_mode);
+
+	KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
+
+	KUNIT_EXPECT_FALSE(test, mode.bpp_specified);
+
+	KUNIT_EXPECT_FALSE(test, mode.rb);
+	KUNIT_EXPECT_FALSE(test, mode.cvt);
+	KUNIT_EXPECT_EQ(test, mode.interlace, !!(expected_mode->flags & DRM_MODE_FLAG_INTERLACE));
+	KUNIT_EXPECT_FALSE(test, mode.margins);
+	KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
+}
+
+static void drm_cmdline_test_tv_option_hd480i(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480i,tv_mode=HD480I",
+				    &drm_mode_480i,
+				    DRM_MODE_TV_NORM_HD480I);
+}
+
+static const struct drm_display_mode drm_mode_480p = {
+	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000,
+		 720, 735, 743, 858, 0, 480, 490, 494, 525, 0,
+		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
+};
+
+static void drm_cmdline_test_tv_option_hd480p(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480,tv_mode=HD480P",
+				    &drm_mode_480p,
+				    DRM_MODE_TV_NORM_HD480P);
+}
+
+static void drm_cmdline_test_tv_option_hd576i(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=HD576I",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_HD576I);
+}
+
+static const struct drm_display_mode drm_mode_576p = {
+	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 27000,
+		 720, 730, 738, 864, 0, 576, 581, 585, 625, 0,
+		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
+};
+
+static void drm_cmdline_test_tv_option_hd576p(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576,tv_mode=HD576P",
+				    &drm_mode_576p,
+				    DRM_MODE_TV_NORM_HD576P);
+}
+
+static const struct drm_display_mode drm_mode_720p = {
+	DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250,
+		 1280, 1349, 1357, 1650, 0, 720, 725, 730, 750, 0,
+		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
+};
+
+static void drm_cmdline_test_tv_option_hd720p(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "1280x720,tv_mode=HD720P",
+				    &drm_mode_720p,
+				    DRM_MODE_TV_NORM_HD720P);
+}
+
+static const struct drm_display_mode drm_mode_1080i = {
+	DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250,
+		 1920, 1961, 2049, 2200, 0, 1080, 1084, 1088, 1125, 0,
+		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC
+		 | DRM_MODE_FLAG_INTERLACE)
+};
+
+static void drm_cmdline_test_tv_option_hd1080i(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "1920x1080i,tv_mode=HD1080I",
+				    &drm_mode_1080i,
+				    DRM_MODE_TV_NORM_HD1080I);
+}
+
+static void drm_cmdline_test_tv_option_ntsc_443(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480i,tv_mode=NTSC-443",
+				    &drm_mode_480i,
+				    DRM_MODE_TV_NORM_NTSC_443);
+}
+
+static void drm_cmdline_test_tv_option_ntsc_j(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480i,tv_mode=NTSC-J",
+				    &drm_mode_480i,
+				    DRM_MODE_TV_NORM_NTSC_J);
+}
+
+static void drm_cmdline_test_tv_option_ntsc_m(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480i,tv_mode=NTSC-M",
+				    &drm_mode_480i,
+				    DRM_MODE_TV_NORM_NTSC_M);
+}
+
+static void drm_cmdline_test_tv_option_pal_60(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-60",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_60);
+}
+
+static void drm_cmdline_test_tv_option_pal_b(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-B",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_B);
+}
+
+static void drm_cmdline_test_tv_option_pal_d(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-D",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_D);
+}
+
+static void drm_cmdline_test_tv_option_pal_g(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-G",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_G);
+}
+
+static void drm_cmdline_test_tv_option_pal_h(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-H",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_H);
+}
+
+static void drm_cmdline_test_tv_option_pal_i(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-I",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_I);
+}
+
+static void drm_cmdline_test_tv_option_pal_m(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x480i,tv_mode=PAL-M",
+				    &drm_mode_480i,
+				    DRM_MODE_TV_NORM_PAL_M);
+}
+
+static void drm_cmdline_test_tv_option_pal_n(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-N",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_N);
+}
+
+static void drm_cmdline_test_tv_option_pal_nc(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=PAL-NC",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_PAL_NC);
+}
+
+static void drm_cmdline_test_tv_option_secam_60(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-60",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_60);
+}
+
+static void drm_cmdline_test_tv_option_secam_b(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-B",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_B);
+}
+
+static void drm_cmdline_test_tv_option_secam_d(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-D",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_D);
+}
+
+static void drm_cmdline_test_tv_option_secam_g(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-G",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_G);
+}
+
+static void drm_cmdline_test_tv_option_secam_k(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-K",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_K);
+}
+
+static void drm_cmdline_test_tv_option_secam_k1(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-K1",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_K1);
+}
+
+static void drm_cmdline_test_tv_option_secam_l(struct kunit *test)
+{
+	drm_cmdline_test_tv_options(test,
+				    "720x576i,tv_mode=SECAM-L",
+				    &drm_mode_576i,
+				    DRM_MODE_TV_NORM_SECAM_L);
+}
+
+static void drm_cmdline_test_tv_option_invalid(struct kunit *test)
+{
+	struct drm_cmdline_mode mode = { };
+	const char *cmdline = "720x480i,tv_mode=invalid";
+
+	KUNIT_EXPECT_FALSE(test, drm_mode_parse_command_line_for_connector(cmdline,
+									   &no_connector, &mode));
+}
+
+static void drm_cmdline_test_tv_option_truncated(struct kunit *test)
+{
+	struct drm_cmdline_mode mode = { };
+	const char *cmdline = "720x480i,tv_mode=NTSC";
+
+	KUNIT_EXPECT_FALSE(test, drm_mode_parse_command_line_for_connector(cmdline,
+									   &no_connector, &mode));
+}
+
 static void drm_cmdline_test_invalid_option(struct kunit *test)
 {
 	struct drm_cmdline_mode mode = { };
@@ -1047,6 +1315,33 @@ static struct kunit_case drm_cmdline_parser_tests[] = {
 	KUNIT_CASE(drm_cmdline_test_name_refresh_invalid_mode),
 	KUNIT_CASE(drm_cmdline_test_name_option),
 	KUNIT_CASE(drm_cmdline_test_name_bpp_option),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd480i),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd480p),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd576i),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd576p),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd720p),
+	KUNIT_CASE(drm_cmdline_test_tv_option_hd1080i),
+	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_443),
+	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_j),
+	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_m),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_60),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_b),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_d),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_g),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_h),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_i),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_m),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_n),
+	KUNIT_CASE(drm_cmdline_test_tv_option_pal_nc),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_60),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_b),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_d),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_g),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_k),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_k1),
+	KUNIT_CASE(drm_cmdline_test_tv_option_secam_l),
+	KUNIT_CASE(drm_cmdline_test_tv_option_invalid),
+	KUNIT_CASE(drm_cmdline_test_tv_option_truncated),
 	KUNIT_CASE(drm_cmdline_test_rotate_0),
 	KUNIT_CASE(drm_cmdline_test_rotate_90),
 	KUNIT_CASE(drm_cmdline_test_rotate_180),
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e535dca6376e..26a779e85785 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1305,6 +1305,11 @@ struct drm_cmdline_mode {
 	 * @tv_margins: TV margins to apply to the mode.
 	 */
 	struct drm_connector_tv_margins tv_margins;
+
+	/**
+	 * @tv_mode: TV mode standard. See DRM_MODE_TV_NORM_*.
+	 */
+	unsigned int tv_mode;
 };
 
 /**

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Geert Uytterhoeven]

Hi Maxime,

On Fri, Jul 29, 2022 at 6:37 PM Maxime Ripard <maxime@cerno.tech> wrote:
> Our new tv mode option allows to specify the TV mode from a property.
> However, it can still be useful, for example to avoid any boot time
> artifact, to set that property directly from the kernel command line.
>
> Let's add some code to allow it, and some unit tests to exercise that code.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Thanks for your patch!

> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1677,6 +1677,80 @@ static int drm_mode_parse_panel_orientation(const char *delim,
>         return 0;
>  }
>
> +#define TV_OPTION_EQUAL(value, len, option) \
> +       ((strlen(option) == len) && !strncmp(value, option, len))
> +
> +static int drm_mode_parse_tv_mode(const char *delim,
> +                                 struct drm_cmdline_mode *mode)
> +{
> +       const char *value;
> +       unsigned int len;
> +
> +       if (*delim != '=')
> +               return -EINVAL;
> +
> +       value = delim + 1;
> +       delim = strchr(value, ',');
> +       if (!delim)
> +               delim = value + strlen(value);
> +
> +       len = delim - value;
> +       if (TV_OPTION_EQUAL(value, len, "NTSC-443"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_443;
> +       else if (TV_OPTION_EQUAL(value, len, "NTSC-J"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_J;
> +       else if (TV_OPTION_EQUAL(value, len, "NTSC-M"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_M;

[...]

You already have the array tv_norm_values[] from "[PATCH v1 05/35]
drm/connector: Add TV standard property". Can't you export that, and
loop over that array instead?

> +       else if (TV_OPTION_EQUAL(value, len, "HD480I"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD480I;
> +       else if (TV_OPTION_EQUAL(value, len, "HD480P"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD480P;
> +       else if (TV_OPTION_EQUAL(value, len, "HD576I"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD576I;
> +       else if (TV_OPTION_EQUAL(value, len, "HD576P"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD576P;
> +       else if (TV_OPTION_EQUAL(value, len, "HD720P"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD720P;
> +       else if (TV_OPTION_EQUAL(value, len, "HD1080I"))
> +               mode->tv_mode = DRM_MODE_TV_NORM_HD1080I;

The names in tv_norm_values[] use lower-case, while you use upper-case
here.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Maxime Ripard]

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

On Fri, Aug 12, 2022 at 03:31:19PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
> 
> On Fri, Jul 29, 2022 at 6:37 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > Our new tv mode option allows to specify the TV mode from a property.
> > However, it can still be useful, for example to avoid any boot time
> > artifact, to set that property directly from the kernel command line.
> >
> > Let's add some code to allow it, and some unit tests to exercise that code.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> Thanks for your patch!
> 
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1677,6 +1677,80 @@ static int drm_mode_parse_panel_orientation(const char *delim,
> >         return 0;
> >  }
> >
> > +#define TV_OPTION_EQUAL(value, len, option) \
> > +       ((strlen(option) == len) && !strncmp(value, option, len))
> > +
> > +static int drm_mode_parse_tv_mode(const char *delim,
> > +                                 struct drm_cmdline_mode *mode)
> > +{
> > +       const char *value;
> > +       unsigned int len;
> > +
> > +       if (*delim != '=')
> > +               return -EINVAL;
> > +
> > +       value = delim + 1;
> > +       delim = strchr(value, ',');
> > +       if (!delim)
> > +               delim = value + strlen(value);
> > +
> > +       len = delim - value;
> > +       if (TV_OPTION_EQUAL(value, len, "NTSC-443"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_443;
> > +       else if (TV_OPTION_EQUAL(value, len, "NTSC-J"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_J;
> > +       else if (TV_OPTION_EQUAL(value, len, "NTSC-M"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_NTSC_M;
> 
> [...]
> 
> You already have the array tv_norm_values[] from "[PATCH v1 05/35]
> drm/connector: Add TV standard property". Can't you export that, and
> loop over that array instead?

I'm not sure, the command line doesn't follow the same conventions than
the property names for a number of conventions, but at the same time we
should try to keep it as consistent as possible...

Then again, Jani and Thomas didn't seem too fond about exposing data as
part of the API, so I'm not sure how we could expose that properly.

> > +       else if (TV_OPTION_EQUAL(value, len, "HD480I"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD480I;
> > +       else if (TV_OPTION_EQUAL(value, len, "HD480P"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD480P;
> > +       else if (TV_OPTION_EQUAL(value, len, "HD576I"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD576I;
> > +       else if (TV_OPTION_EQUAL(value, len, "HD576P"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD576P;
> > +       else if (TV_OPTION_EQUAL(value, len, "HD720P"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD720P;
> > +       else if (TV_OPTION_EQUAL(value, len, "HD1080I"))
> > +               mode->tv_mode = DRM_MODE_TV_NORM_HD1080I;
> 
> The names in tv_norm_values[] use lower-case, while you use upper-case
> here.

Indeed, I'll fix it, thanks!
Maxime

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

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Noralf Trønnes]

Den 29.07.2022 18.35, skrev Maxime Ripard:
> Our new tv mode option allows to specify the TV mode from a property.
> However, it can still be useful, for example to avoid any boot time
> artifact, to set that property directly from the kernel command line.
> 
> Let's add some code to allow it, and some unit tests to exercise that code.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 

In the subject it says "tv_mode property", but the property is called
"tv norm", so the option should be tv_norm?

Noralf.

> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index fce5569bd66a..49da8d8236f5 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -490,6 +490,7 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
>  void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
>  {
>  	struct drm_device *dev = connector->dev;
> +	struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
>  	struct drm_connector_state *state = connector->state;
>  	struct drm_property *prop;
>  	uint64_t val;
> @@ -500,6 +501,9 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
>  							   prop, &val))
>  			state->tv.norm = val;
>  
> +	if (cmdline->tv_mode)
> +		state->tv.norm = cmdline->tv_mode;
> +
>  	prop = dev->mode_config.tv_select_subconnector_property;
>  	if (prop)
>  		if (!drm_object_property_get_default_value(&connector->base,
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ecb2e83cf860..3634ac9f787d 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1677,6 +1677,80 @@ static int drm_mode_parse_panel_orientation(const char *delim,
>  	return 0;
>  }
>  
> +#define TV_OPTION_EQUAL(value, len, option) \
> +	((strlen(option) == len) && !strncmp(value, option, len))
> +
> +static int drm_mode_parse_tv_mode(const char *delim,
> +				  struct drm_cmdline_mode *mode)
> +{
> +	const char *value;
> +	unsigned int len;
> +
> +	if (*delim != '=')
> +		return -EINVAL;
> +
> +	value = delim + 1;
> +	delim = strchr(value, ',');
> +	if (!delim)
> +		delim = value + strlen(value);
> +
> +	len = delim - value;
> +	if (TV_OPTION_EQUAL(value, len, "NTSC-443"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_443;
> +	else if (TV_OPTION_EQUAL(value, len, "NTSC-J"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_J;
> +	else if (TV_OPTION_EQUAL(value, len, "NTSC-M"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_NTSC_M;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-60"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_60;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-B"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_B;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-D"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_D;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-G"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_G;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-H"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_H;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-I"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_I;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-M"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_M;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-N"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_N;
> +	else if (TV_OPTION_EQUAL(value, len, "PAL-NC"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_PAL_NC;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-60"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_60;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-B"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_B;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-D"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_D;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-G"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_G;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-K"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_K;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-K1"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_K1;
> +	else if (TV_OPTION_EQUAL(value, len, "SECAM-L"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_SECAM_L;
> +	else if (TV_OPTION_EQUAL(value, len, "HD480I"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD480I;
> +	else if (TV_OPTION_EQUAL(value, len, "HD480P"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD480P;
> +	else if (TV_OPTION_EQUAL(value, len, "HD576I"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD576I;
> +	else if (TV_OPTION_EQUAL(value, len, "HD576P"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD576P;
> +	else if (TV_OPTION_EQUAL(value, len, "HD720P"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD720P;
> +	else if (TV_OPTION_EQUAL(value, len, "HD1080I"))
> +		mode->tv_mode = DRM_MODE_TV_NORM_HD1080I;
> +	else
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
>  static int drm_mode_parse_cmdline_options(const char *str,
>  					  bool freestanding,
>  					  const struct drm_connector *connector,
> @@ -1746,6 +1820,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
>  		} else if (!strncmp(option, "panel_orientation", delim - option)) {
>  			if (drm_mode_parse_panel_orientation(delim, mode))
>  				return -EINVAL;
> +		} else if (!strncmp(option, "tv_mode", delim - option)) {
> +			if (drm_mode_parse_tv_mode(delim, mode))
> +				return -EINVAL;
>  		} else {
>  			return -EINVAL;
>  		}
> @@ -1771,11 +1848,12 @@ static int drm_mode_parse_cmdline_options(const char *str,
>  struct drm_named_mode {
>  	const char *name;
>  	const struct drm_display_mode *mode;
> +	unsigned int tv_mode;
>  };
>  
>  static const struct drm_named_mode drm_named_modes[] = {
> -	{ "NTSC", &drm_mode_480i, },
> -	{ "PAL", &drm_mode_576i, },
> +	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
> +	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
>  };
>  
>  static bool drm_mode_parse_cmdline_named_mode(const char *name,
> @@ -1796,6 +1874,7 @@ static bool drm_mode_parse_cmdline_named_mode(const char *name,
>  		cmdline_mode->xres = mode->mode->hdisplay;
>  		cmdline_mode->yres = mode->mode->vdisplay;
>  		cmdline_mode->interlace = !!(mode->mode->flags & DRM_MODE_FLAG_INTERLACE);
> +		cmdline_mode->tv_mode = mode->tv_mode;
>  		cmdline_mode->specified = true;
>  
>  		return true;
> diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> index 59b29cdfdd35..d198717c8375 100644
> --- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> +++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> @@ -885,6 +885,274 @@ static void drm_cmdline_test_multiple_options(struct kunit *test)
>  	KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
>  }
>  
> +static void drm_cmdline_test_tv_options(struct kunit *test,
> +					const char *cmdline,
> +					const struct drm_display_mode *expected_mode,
> +					unsigned int expected_tv_mode)
> +{
> +	struct drm_cmdline_mode mode = { };
> +
> +	KUNIT_EXPECT_TRUE(test, drm_mode_parse_command_line_for_connector(cmdline,
> +									  &no_connector, &mode));
> +	KUNIT_EXPECT_TRUE(test, mode.specified);
> +	KUNIT_EXPECT_EQ(test, mode.xres, expected_mode->hdisplay);
> +	KUNIT_EXPECT_EQ(test, mode.yres, expected_mode->vdisplay);
> +	KUNIT_EXPECT_EQ(test, mode.tv_mode, expected_tv_mode);
> +
> +	KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
> +
> +	KUNIT_EXPECT_FALSE(test, mode.bpp_specified);
> +
> +	KUNIT_EXPECT_FALSE(test, mode.rb);
> +	KUNIT_EXPECT_FALSE(test, mode.cvt);
> +	KUNIT_EXPECT_EQ(test, mode.interlace, !!(expected_mode->flags & DRM_MODE_FLAG_INTERLACE));
> +	KUNIT_EXPECT_FALSE(test, mode.margins);
> +	KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
> +}
> +
> +static void drm_cmdline_test_tv_option_hd480i(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480i,tv_mode=HD480I",
> +				    &drm_mode_480i,
> +				    DRM_MODE_TV_NORM_HD480I);
> +}
> +
> +static const struct drm_display_mode drm_mode_480p = {
> +	DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000,
> +		 720, 735, 743, 858, 0, 480, 490, 494, 525, 0,
> +		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
> +};
> +
> +static void drm_cmdline_test_tv_option_hd480p(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480,tv_mode=HD480P",
> +				    &drm_mode_480p,
> +				    DRM_MODE_TV_NORM_HD480P);
> +}
> +
> +static void drm_cmdline_test_tv_option_hd576i(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=HD576I",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_HD576I);
> +}
> +
> +static const struct drm_display_mode drm_mode_576p = {
> +	DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 27000,
> +		 720, 730, 738, 864, 0, 576, 581, 585, 625, 0,
> +		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
> +};
> +
> +static void drm_cmdline_test_tv_option_hd576p(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576,tv_mode=HD576P",
> +				    &drm_mode_576p,
> +				    DRM_MODE_TV_NORM_HD576P);
> +}
> +
> +static const struct drm_display_mode drm_mode_720p = {
> +	DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250,
> +		 1280, 1349, 1357, 1650, 0, 720, 725, 730, 750, 0,
> +		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC)
> +};
> +
> +static void drm_cmdline_test_tv_option_hd720p(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "1280x720,tv_mode=HD720P",
> +				    &drm_mode_720p,
> +				    DRM_MODE_TV_NORM_HD720P);
> +}
> +
> +static const struct drm_display_mode drm_mode_1080i = {
> +	DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250,
> +		 1920, 1961, 2049, 2200, 0, 1080, 1084, 1088, 1125, 0,
> +		 DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC
> +		 | DRM_MODE_FLAG_INTERLACE)
> +};
> +
> +static void drm_cmdline_test_tv_option_hd1080i(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "1920x1080i,tv_mode=HD1080I",
> +				    &drm_mode_1080i,
> +				    DRM_MODE_TV_NORM_HD1080I);
> +}
> +
> +static void drm_cmdline_test_tv_option_ntsc_443(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480i,tv_mode=NTSC-443",
> +				    &drm_mode_480i,
> +				    DRM_MODE_TV_NORM_NTSC_443);
> +}
> +
> +static void drm_cmdline_test_tv_option_ntsc_j(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480i,tv_mode=NTSC-J",
> +				    &drm_mode_480i,
> +				    DRM_MODE_TV_NORM_NTSC_J);
> +}
> +
> +static void drm_cmdline_test_tv_option_ntsc_m(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480i,tv_mode=NTSC-M",
> +				    &drm_mode_480i,
> +				    DRM_MODE_TV_NORM_NTSC_M);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_60(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-60",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_60);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_b(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-B",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_B);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_d(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-D",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_D);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_g(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-G",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_G);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_h(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-H",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_H);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_i(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-I",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_I);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_m(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x480i,tv_mode=PAL-M",
> +				    &drm_mode_480i,
> +				    DRM_MODE_TV_NORM_PAL_M);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_n(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-N",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_N);
> +}
> +
> +static void drm_cmdline_test_tv_option_pal_nc(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=PAL-NC",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_PAL_NC);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_60(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-60",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_60);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_b(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-B",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_B);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_d(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-D",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_D);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_g(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-G",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_G);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_k(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-K",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_K);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_k1(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-K1",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_K1);
> +}
> +
> +static void drm_cmdline_test_tv_option_secam_l(struct kunit *test)
> +{
> +	drm_cmdline_test_tv_options(test,
> +				    "720x576i,tv_mode=SECAM-L",
> +				    &drm_mode_576i,
> +				    DRM_MODE_TV_NORM_SECAM_L);
> +}
> +
> +static void drm_cmdline_test_tv_option_invalid(struct kunit *test)
> +{
> +	struct drm_cmdline_mode mode = { };
> +	const char *cmdline = "720x480i,tv_mode=invalid";
> +
> +	KUNIT_EXPECT_FALSE(test, drm_mode_parse_command_line_for_connector(cmdline,
> +									   &no_connector, &mode));
> +}
> +
> +static void drm_cmdline_test_tv_option_truncated(struct kunit *test)
> +{
> +	struct drm_cmdline_mode mode = { };
> +	const char *cmdline = "720x480i,tv_mode=NTSC";
> +
> +	KUNIT_EXPECT_FALSE(test, drm_mode_parse_command_line_for_connector(cmdline,
> +									   &no_connector, &mode));
> +}
> +
>  static void drm_cmdline_test_invalid_option(struct kunit *test)
>  {
>  	struct drm_cmdline_mode mode = { };
> @@ -1047,6 +1315,33 @@ static struct kunit_case drm_cmdline_parser_tests[] = {
>  	KUNIT_CASE(drm_cmdline_test_name_refresh_invalid_mode),
>  	KUNIT_CASE(drm_cmdline_test_name_option),
>  	KUNIT_CASE(drm_cmdline_test_name_bpp_option),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd480i),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd480p),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd576i),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd576p),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd720p),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_hd1080i),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_443),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_j),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_ntsc_m),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_60),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_b),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_d),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_g),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_h),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_i),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_m),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_n),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_pal_nc),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_60),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_b),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_d),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_g),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_k),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_k1),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_secam_l),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_invalid),
> +	KUNIT_CASE(drm_cmdline_test_tv_option_truncated),
>  	KUNIT_CASE(drm_cmdline_test_rotate_0),
>  	KUNIT_CASE(drm_cmdline_test_rotate_90),
>  	KUNIT_CASE(drm_cmdline_test_rotate_180),
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index e535dca6376e..26a779e85785 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1305,6 +1305,11 @@ struct drm_cmdline_mode {
>  	 * @tv_margins: TV margins to apply to the mode.
>  	 */
>  	struct drm_connector_tv_margins tv_margins;
> +
> +	/**
> +	 * @tv_mode: TV mode standard. See DRM_MODE_TV_NORM_*.
> +	 */
> +	unsigned int tv_mode;
>  };
>  
>  /**
> 

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Maxime Ripard]

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

Hi Noralf,

On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.35, skrev Maxime Ripard:
> > Our new tv mode option allows to specify the TV mode from a property.
> > However, it can still be useful, for example to avoid any boot time
> > artifact, to set that property directly from the kernel command line.
> > 
> > Let's add some code to allow it, and some unit tests to exercise that code.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> 
> In the subject it says "tv_mode property", but the property is called
> "tv norm", so the option should be tv_norm?

Yeah... I don't know. mode is taken but it's obviously the best name. So
I went with norm to avoid the (internal) conflict but I left mode for
the user facing property.

I'm not sure what's best here, or maybe we can pick another name entirely?

Maxime

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

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Mateusz Kwiatkowski]

Hi Maxime & Noralf,

W dniu 24.08.2022 o 17:45, Maxime Ripard pisze:
> Hi Noralf,
>
> On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.35, skrev Maxime Ripard:
>>> Our new tv mode option allows to specify the TV mode from a property.
>>> However, it can still be useful, for example to avoid any boot time
>>> artifact, to set that property directly from the kernel command line.
>>>
>>> Let's add some code to allow it, and some unit tests to exercise that code.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>
>>
>> In the subject it says "tv_mode property", but the property is called
>> "tv norm", so the option should be tv_norm?
>
> Yeah... I don't know. mode is taken but it's obviously the best name. So
> I went with norm to avoid the (internal) conflict but I left mode for
> the user facing property.
>
> I'm not sure what's best here, or maybe we can pick another name entirely?

I think "standard" and "system" are also fairly common names for this property.

I once had an old multi-standard Sharp CRT TV that allowed manually selecting
the expected color encoding (PAL/SECAM/NTSC/NTSC-443), and the relevant button
on the remote was labeled "SYSTEM".

V4L2 calls this "standard", see include/uapi/linux/videodev2.h, compare with
v4l2_std_id, V4L2_STD_* etc.

BTW, maybe reusing those V4L2 constants, or aligning the numerical values,
would make some sense?

>
> Maxime

Best regards,
Mateusz Kwiatkowski

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Noralf Trønnes]

Den 24.08.2022 17.45, skrev Maxime Ripard:
> Hi Noralf,
> 
> On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.35, skrev Maxime Ripard:
>>> Our new tv mode option allows to specify the TV mode from a property.
>>> However, it can still be useful, for example to avoid any boot time
>>> artifact, to set that property directly from the kernel command line.
>>>
>>> Let's add some code to allow it, and some unit tests to exercise that code.
>>>
>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>
>>
>> In the subject it says "tv_mode property", but the property is called
>> "tv norm", so the option should be tv_norm?
> 
> Yeah... I don't know. mode is taken but it's obviously the best name. So
> I went with norm to avoid the (internal) conflict but I left mode for
> the user facing property.
> 
> I'm not sure what's best here, or maybe we can pick another name entirely?
> 

Why not just call it "tv mode" or even better "TV Mode". The state
member can be called tv_mode, but the mode_config member will need a
temporary name until the "mode" property is removed. tv_tv_mode or maybe
connector_tv_mode?

But IMO, if there are no users of this property, adding it should have a
drm maintainers ack.

Noralf.

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Maxime Ripard]

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

On Thu, Aug 25, 2022 at 02:41:27PM +0200, Noralf Trønnes wrote:
> Den 24.08.2022 17.45, skrev Maxime Ripard:
> > Hi Noralf,
> > 
> > On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote:
> >> Den 29.07.2022 18.35, skrev Maxime Ripard:
> >>> Our new tv mode option allows to specify the TV mode from a property.
> >>> However, it can still be useful, for example to avoid any boot time
> >>> artifact, to set that property directly from the kernel command line.
> >>>
> >>> Let's add some code to allow it, and some unit tests to exercise that code.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> >>>
> >>
> >> In the subject it says "tv_mode property", but the property is called
> >> "tv norm", so the option should be tv_norm?
> > 
> > Yeah... I don't know. mode is taken but it's obviously the best name. So
> > I went with norm to avoid the (internal) conflict but I left mode for
> > the user facing property.
> > 
> > I'm not sure what's best here, or maybe we can pick another name entirely?
> > 
> 
> Why not just call it "tv mode" or even better "TV Mode". The state
> member can be called tv_mode, but the mode_config member will need a
> temporary name until the "mode" property is removed. tv_tv_mode or maybe
> connector_tv_mode?

Yeah, that seems like a good idea. Would legacy_tv_mode work for you?

> But IMO, if there are no users of this property, adding it should have a
> drm maintainers ack.

Yep, of course :)

Maxime

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

Re: [PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a command-line option

[Noralf Trønnes]

Den 26.08.2022 08.46, skrev Maxime Ripard:
> On Thu, Aug 25, 2022 at 02:41:27PM +0200, Noralf Trønnes wrote:
>> Den 24.08.2022 17.45, skrev Maxime Ripard:
>>> Hi Noralf,
>>>
>>> On Sat, Aug 20, 2022 at 10:18:47PM +0200, Noralf Trønnes wrote:
>>>> Den 29.07.2022 18.35, skrev Maxime Ripard:
>>>>> Our new tv mode option allows to specify the TV mode from a property.
>>>>> However, it can still be useful, for example to avoid any boot time
>>>>> artifact, to set that property directly from the kernel command line.
>>>>>
>>>>> Let's add some code to allow it, and some unit tests to exercise that code.
>>>>>
>>>>> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
>>>>>
>>>>
>>>> In the subject it says "tv_mode property", but the property is called
>>>> "tv norm", so the option should be tv_norm?
>>>
>>> Yeah... I don't know. mode is taken but it's obviously the best name. So
>>> I went with norm to avoid the (internal) conflict but I left mode for
>>> the user facing property.
>>>
>>> I'm not sure what's best here, or maybe we can pick another name entirely?
>>>
>>
>> Why not just call it "tv mode" or even better "TV Mode". The state
>> member can be called tv_mode, but the mode_config member will need a
>> temporary name until the "mode" property is removed. tv_tv_mode or maybe
>> connector_tv_mode?
> 
> Yeah, that seems like a good idea. Would legacy_tv_mode work for you?
> 

Oh yeah, renaming the "mode" property, that works fine.

Noralf.

[PATCH v1 35/35] drm/modes: Introduce more named modes

[Maxime Ripard]

Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3634ac9f787d..09ed5ce7746d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1853,7 +1853,9 @@ struct drm_named_mode {
 
 static const struct drm_named_mode drm_named_modes[] = {
 	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
+	{ "NTSC_J", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_J, },
 	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
+	{ "PAL_M", &drm_mode_480i, DRM_MODE_TV_NORM_PAL_M, },
 };
 
 static bool drm_mode_parse_cmdline_named_mode(const char *name,
diff --git a/drivers/gpu/drm/tests/drm_mode_test.c b/drivers/gpu/drm/tests/drm_mode_test.c
index 006b73a61fd4..991eb8ed687c 100644
--- a/drivers/gpu/drm/tests/drm_mode_test.c
+++ b/drivers/gpu/drm/tests/drm_mode_test.c
@@ -156,6 +156,32 @@ static void drm_mode_named_ntsc(struct kunit *test)
 	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
 }
 
+static void drm_mode_named_ntsc_j(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+	struct drm_device *drm = priv->drm;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+	struct drm_display_mode *mode;
+	const char *cmdline = "NTSC_J";
+	int ret;
+
+	KUNIT_ASSERT_TRUE(test,
+			  drm_mode_parse_command_line_for_connector(cmdline,
+								    connector,
+								    cmdline_mode));
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	mode = drm_connector_pick_cmdline_mode(connector);
+	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
+}
+
 static void drm_mode_named_pal(struct kunit *test)
 {
 	struct drm_mode_test_priv *priv = test->priv;
@@ -182,10 +208,38 @@ static void drm_mode_named_pal(struct kunit *test)
 	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_576i, mode));
 }
 
+static void drm_mode_named_pal_m(struct kunit *test)
+{
+	struct drm_mode_test_priv *priv = test->priv;
+	struct drm_device *drm = priv->drm;
+	struct drm_connector *connector = &priv->connector;
+	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+	struct drm_display_mode *mode;
+	const char *cmdline = "PAL_M";
+	int ret;
+
+	KUNIT_ASSERT_TRUE(test,
+			  drm_mode_parse_command_line_for_connector(cmdline,
+								    connector,
+								    cmdline_mode));
+
+	mutex_lock(&drm->mode_config.mutex);
+	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+	mutex_unlock(&drm->mode_config.mutex);
+	KUNIT_ASSERT_GT(test, ret, 0);
+
+	mode = drm_connector_pick_cmdline_mode(connector);
+	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
+}
+
 static struct kunit_case drm_mode_tests[] = {
 	KUNIT_CASE(drm_mode_res_1920_1080_60),
 	KUNIT_CASE(drm_mode_named_ntsc),
+	KUNIT_CASE(drm_mode_named_ntsc_j),
 	KUNIT_CASE(drm_mode_named_pal),
+	KUNIT_CASE(drm_mode_named_pal_m),
 	{}
 };
 

-- 
b4 0.10.0-dev-49460

Re: [PATCH v1 35/35] drm/modes: Introduce more named modes

[Noralf Trønnes]

Den 29.07.2022 18.35, skrev Maxime Ripard:
> Now that we can easily extend the named modes list, let's add a few more
> analog TV modes that were used in the wild, and some unit tests to make
> sure it works as intended.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 3634ac9f787d..09ed5ce7746d 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1853,7 +1853,9 @@ struct drm_named_mode {
>  
>  static const struct drm_named_mode drm_named_modes[] = {
>  	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
> +	{ "NTSC_J", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_J, },
>  	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
> +	{ "PAL_M", &drm_mode_480i, DRM_MODE_TV_NORM_PAL_M, },

Please use a dash instead of an underscore to keep it consistent with
what's used elsewhere.

I tried to use PAL and set the connector as connected, but that didn't
work: video=Composite-1:PALe

Is this a bug and it should work or should it be phrased differently?
It would have been nice to get a warning in the log if the parser fails
to understand.

This very verbose version did work:
video=Composite-1:720x576@50ie,tv_mode=PAL-B

(it seems to me that userspace often treats connection status "unknown"
the same as "disconnected")

Noralf.

>  };
>  
>  static bool drm_mode_parse_cmdline_named_mode(const char *name,
> diff --git a/drivers/gpu/drm/tests/drm_mode_test.c b/drivers/gpu/drm/tests/drm_mode_test.c
> index 006b73a61fd4..991eb8ed687c 100644
> --- a/drivers/gpu/drm/tests/drm_mode_test.c
> +++ b/drivers/gpu/drm/tests/drm_mode_test.c
> @@ -156,6 +156,32 @@ static void drm_mode_named_ntsc(struct kunit *test)
>  	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
>  }
>  
> +static void drm_mode_named_ntsc_j(struct kunit *test)
> +{
> +	struct drm_mode_test_priv *priv = test->priv;
> +	struct drm_device *drm = priv->drm;
> +	struct drm_connector *connector = &priv->connector;
> +	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
> +	struct drm_display_mode *mode;
> +	const char *cmdline = "NTSC_J";
> +	int ret;
> +
> +	KUNIT_ASSERT_TRUE(test,
> +			  drm_mode_parse_command_line_for_connector(cmdline,
> +								    connector,
> +								    cmdline_mode));
> +
> +	mutex_lock(&drm->mode_config.mutex);
> +	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> +	mutex_unlock(&drm->mode_config.mutex);
> +	KUNIT_ASSERT_GT(test, ret, 0);
> +
> +	mode = drm_connector_pick_cmdline_mode(connector);
> +	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
> +
> +	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
> +}
> +
>  static void drm_mode_named_pal(struct kunit *test)
>  {
>  	struct drm_mode_test_priv *priv = test->priv;
> @@ -182,10 +208,38 @@ static void drm_mode_named_pal(struct kunit *test)
>  	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_576i, mode));
>  }
>  
> +static void drm_mode_named_pal_m(struct kunit *test)
> +{
> +	struct drm_mode_test_priv *priv = test->priv;
> +	struct drm_device *drm = priv->drm;
> +	struct drm_connector *connector = &priv->connector;
> +	struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
> +	struct drm_display_mode *mode;
> +	const char *cmdline = "PAL_M";
> +	int ret;
> +
> +	KUNIT_ASSERT_TRUE(test,
> +			  drm_mode_parse_command_line_for_connector(cmdline,
> +								    connector,
> +								    cmdline_mode));
> +
> +	mutex_lock(&drm->mode_config.mutex);
> +	ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
> +	mutex_unlock(&drm->mode_config.mutex);
> +	KUNIT_ASSERT_GT(test, ret, 0);
> +
> +	mode = drm_connector_pick_cmdline_mode(connector);
> +	KUNIT_ASSERT_PTR_NE(test, mode, NULL);
> +
> +	KUNIT_EXPECT_TRUE(test, drm_mode_equal(&drm_mode_480i, mode));
> +}
> +
>  static struct kunit_case drm_mode_tests[] = {
>  	KUNIT_CASE(drm_mode_res_1920_1080_60),
>  	KUNIT_CASE(drm_mode_named_ntsc),
> +	KUNIT_CASE(drm_mode_named_ntsc_j),
>  	KUNIT_CASE(drm_mode_named_pal),
> +	KUNIT_CASE(drm_mode_named_pal_m),
>  	{}
>  };
>  
> 

Re: [PATCH v1 35/35] drm/modes: Introduce more named modes

[Maxime Ripard]

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

On Sun, Aug 21, 2022 at 06:16:15PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 29.07.2022 18.35, skrev Maxime Ripard:
> > Now that we can easily extend the named modes list, let's add a few more
> > analog TV modes that were used in the wild, and some unit tests to make
> > sure it works as intended.
> > 
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 3634ac9f787d..09ed5ce7746d 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1853,7 +1853,9 @@ struct drm_named_mode {
> >  
> >  static const struct drm_named_mode drm_named_modes[] = {
> >  	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
> > +	{ "NTSC_J", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_J, },
> >  	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
> > +	{ "PAL_M", &drm_mode_480i, DRM_MODE_TV_NORM_PAL_M, },
> 
> Please use a dash instead of an underscore to keep it consistent with
> what's used elsewhere.

Yeah, I tried not to use it since I didn't want to cripple the parser
with bad heuristics, but Geert has done a much better job than my
attempts here:
https://lore.kernel.org/dri-devel/2eb205da88c3cb19ddf04d167ece4e16a330948b.1657788997.git.geert@linux-m68k.org/

I've taken that patch in, renamed the modes and we already have unit
tests in other patches to cover that part of the parser.

> I tried to use PAL and set the connector as connected, but that didn't
> work: video=Composite-1:PALe
> 
> Is this a bug and it should work or should it be phrased differently?

I'm not sure. We never supported something like that so far, because the
expectation is that if it starts with a letter, it's a named mode. Thus
the named mode is PALe in your case, which doesn't match.

I'm not even sure what would be a good heuristic to support it, since
interpreting any e, E, or D as the last letter seems like a recipe for
disaster when some modes might legitimately end with e or d.

> It would have been nice to get a warning in the log if the parser fails
> to understand.
> 
> This very verbose version did work:
> video=Composite-1:720x576@50ie,tv_mode=PAL-B

I think that's what we should be using in that case.

Maxime

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

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> Hi,
> 
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
> 
> The named modes support were initially introduced to allow to specify the
> analog TV mode to be used.
> 
> However, this was causing multiple issues:
> 
>   * The mode name parsed on the command line was passed directly to the
>     driver, which had to figure out which mode it was suppose to match;
> 
>   * Figuring that out wasn't really easy, since the video= argument or what
>     the userspace might not even have a name in the first place, but
>     instead could have passed a mode with the same timings;
> 
>   * The fallback to matching on the timings was mostly working as long as
>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
>     (PAL), but couldn't differentiate between two modes with the same
>     timings (NTSC vs PAL-M vs NSTC-J for example); 
> 
>   * There was also some overlap with the tv mode property registered by 
>     drm_mode_create_tv_properties(), but named modes weren't interacting
>     with that property at all.
> 
>   * Even though that property was generic, its possible values were
>     specific to each drivers, which made some generic support difficult.
> 
> Thus, I chose to tackle in multiple steps:
> 
>   * A new TV norm property was introduced, with generic values, each driver
>     reporting through a bitmask what standard it supports to the userspace;
> 
>   * This option was added to the command line parsing code to be able to
>     specify it on the kernel command line, and new atomic_check and reset
>     helpers were created to integrate properly into atomic KMS;
> 
>   * The named mode parsing code is now creating a proper display mode for
>     the given named mode, and the TV standard will thus be part of the
>     connector state;
> 
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
>     some backward compatibility code to translate the old TV mode to the
>     new TV mode;
> 
> Unit tests were created along the way. Nouveau, ch7006 and gud are
> currently broken for now since I expect that work to be reworked fairly
> significantly. I'm also not entirely sure about how to migrate GUD to the
> new property.
> 

I have looked at gud and I think the future proof solution is to add a
new TV_NORM property to the GUD protocol and add backwards compatibility
for the GUD_TV_MODE property (just for the modes that Raspberry Pi
supports since the gadget driver is out of tree). I don't bother
supporting the tv.mode property in userspace (I haven't seen anything
that uses the property).

I have written up most of the host driver changes but I have to do the
gadget side as well to make sure it works. I'll post some patches when
I'm done. In hindsight I should have used a bitmask for the TV standards
in the first place ;)

Noralf.

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Noralf Trønnes]

Den 29.07.2022 18.34, skrev Maxime Ripard:
> Hi,
> 
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
> 
> The named modes support were initially introduced to allow to specify the
> analog TV mode to be used.
> 
> However, this was causing multiple issues:
> 
>   * The mode name parsed on the command line was passed directly to the
>     driver, which had to figure out which mode it was suppose to match;
> 
>   * Figuring that out wasn't really easy, since the video= argument or what
>     the userspace might not even have a name in the first place, but
>     instead could have passed a mode with the same timings;
> 
>   * The fallback to matching on the timings was mostly working as long as
>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
>     (PAL), but couldn't differentiate between two modes with the same
>     timings (NTSC vs PAL-M vs NSTC-J for example); 
> 
>   * There was also some overlap with the tv mode property registered by 
>     drm_mode_create_tv_properties(), but named modes weren't interacting
>     with that property at all.
> 
>   * Even though that property was generic, its possible values were
>     specific to each drivers, which made some generic support difficult.
> 
> Thus, I chose to tackle in multiple steps:
> 
>   * A new TV norm property was introduced, with generic values, each driver
>     reporting through a bitmask what standard it supports to the userspace;
> 
>   * This option was added to the command line parsing code to be able to
>     specify it on the kernel command line, and new atomic_check and reset
>     helpers were created to integrate properly into atomic KMS;
> 
>   * The named mode parsing code is now creating a proper display mode for
>     the given named mode, and the TV standard will thus be part of the
>     connector state;
> 
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
>     some backward compatibility code to translate the old TV mode to the
>     new TV mode;
> 
> Unit tests were created along the way. Nouveau, ch7006 and gud are
> currently broken for now since I expect that work to be reworked fairly
> significantly. I'm also not entirely sure about how to migrate GUD to the
> new property.
> 
> Let me know what you think,
> Maxime
> 

I don't know if it's related to this patchset or not, but I do get this:

pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
&& dmesg
[  430.066211] Console: switching to colour dummy device 80x30
[  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
[  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
[vc4])
[  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
timed out
[  441.446529] Console: switching to colour frame buffer device 90x30
[  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
[  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
timed out
[  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
[  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
commit wait timed out
[  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
[  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
timed out
[  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
[  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
[  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
timed out
[  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

Noralf.

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Maxime Ripard]

Hi,

On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.34, skrev Maxime Ripard:
> > Hi,
> > 
> > Here's a series aiming at improving the command line named modes support,
> > and more importantly how we deal with all the analog TV variants.
> > 
> > The named modes support were initially introduced to allow to specify the
> > analog TV mode to be used.
> > 
> > However, this was causing multiple issues:
> > 
> >   * The mode name parsed on the command line was passed directly to the
> >     driver, which had to figure out which mode it was suppose to match;
> > 
> >   * Figuring that out wasn't really easy, since the video= argument or what
> >     the userspace might not even have a name in the first place, but
> >     instead could have passed a mode with the same timings;
> > 
> >   * The fallback to matching on the timings was mostly working as long as
> >     we were supporting one 525 lines (most likely NSTC) and one 625 lines
> >     (PAL), but couldn't differentiate between two modes with the same
> >     timings (NTSC vs PAL-M vs NSTC-J for example); 
> > 
> >   * There was also some overlap with the tv mode property registered by 
> >     drm_mode_create_tv_properties(), but named modes weren't interacting
> >     with that property at all.
> > 
> >   * Even though that property was generic, its possible values were
> >     specific to each drivers, which made some generic support difficult.
> > 
> > Thus, I chose to tackle in multiple steps:
> > 
> >   * A new TV norm property was introduced, with generic values, each driver
> >     reporting through a bitmask what standard it supports to the userspace;
> > 
> >   * This option was added to the command line parsing code to be able to
> >     specify it on the kernel command line, and new atomic_check and reset
> >     helpers were created to integrate properly into atomic KMS;
> > 
> >   * The named mode parsing code is now creating a proper display mode for
> >     the given named mode, and the TV standard will thus be part of the
> >     connector state;
> > 
> >   * Two drivers were converted and tested for now (vc4 and sun4i), with
> >     some backward compatibility code to translate the old TV mode to the
> >     new TV mode;
> > 
> > Unit tests were created along the way. Nouveau, ch7006 and gud are
> > currently broken for now since I expect that work to be reworked fairly
> > significantly. I'm also not entirely sure about how to migrate GUD to the
> > new property.
> > 
> > Let me know what you think,
> > Maxime
> > 
> 
> I don't know if it's related to this patchset or not, but I do get this:
> 
> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
> && dmesg
> [  430.066211] Console: switching to colour dummy device 80x30
> [  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> [  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
> [  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> [  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
> [vc4])
> [  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> [  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
> timed out
> [  441.446529] Console: switching to colour frame buffer device 90x30
> [  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> [  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
> timed out
> [  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> [  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
> commit wait timed out
> [  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> [  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
> timed out
> [  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> [  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
> [  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
> timed out
> [  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

Module unloading/reloading has been janky for a while.

I've fixed it up recently but it doesn't surprise me that there's still
some situation that won't work. Is it on a Pi3?

Maxime

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Mateusz Kwiatkowski]

Hi Maxime,

I tried testing and reviewing your changes properly over the last weekend, but
ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
mitigate it, at least so far. This seems to pop up every time I try to change
modes in any way (either change the TV norm, or just try doing
"xrandr --output Composite-1 --off" followed by bringing it back on; it also
means that the Pi goes unusable when the DE's screen saving routine kicks in).

I'm using a Pi 4, and it works with the rpi-5.13.y branch
https://github.com/raspberrypi/linux, but seemingly nothing newer.
I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
which is the current main branch in Raspberry Pi OS, seems to be broken since
forever; at least since my patches (originally written for 5.10) landed there.

I'll try identifying the issue further, possibly later today, and maybe check
the rpi-6.0.y branch as well.

Best regards,
Mateusz Kwiatkowski

W dniu 22.08.2022 o 09:48, Maxime Ripard pisze:
> Hi,
>
> On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> Hi,
>>>
>>> Here's a series aiming at improving the command line named modes support,
>>> and more importantly how we deal with all the analog TV variants.
>>>
>>> The named modes support were initially introduced to allow to specify the
>>> analog TV mode to be used.
>>>
>>> However, this was causing multiple issues:
>>>
>>>   * The mode name parsed on the command line was passed directly to the
>>>     driver, which had to figure out which mode it was suppose to match;
>>>
>>>   * Figuring that out wasn't really easy, since the video= argument or what
>>>     the userspace might not even have a name in the first place, but
>>>     instead could have passed a mode with the same timings;
>>>
>>>   * The fallback to matching on the timings was mostly working as long as
>>>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
>>>     (PAL), but couldn't differentiate between two modes with the same
>>>     timings (NTSC vs PAL-M vs NSTC-J for example); 
>>>
>>>   * There was also some overlap with the tv mode property registered by 
>>>     drm_mode_create_tv_properties(), but named modes weren't interacting
>>>     with that property at all.
>>>
>>>   * Even though that property was generic, its possible values were
>>>     specific to each drivers, which made some generic support difficult.
>>>
>>> Thus, I chose to tackle in multiple steps:
>>>
>>>   * A new TV norm property was introduced, with generic values, each driver
>>>     reporting through a bitmask what standard it supports to the userspace;
>>>
>>>   * This option was added to the command line parsing code to be able to
>>>     specify it on the kernel command line, and new atomic_check and reset
>>>     helpers were created to integrate properly into atomic KMS;
>>>
>>>   * The named mode parsing code is now creating a proper display mode for
>>>     the given named mode, and the TV standard will thus be part of the
>>>     connector state;
>>>
>>>   * Two drivers were converted and tested for now (vc4 and sun4i), with
>>>     some backward compatibility code to translate the old TV mode to the
>>>     new TV mode;
>>>
>>> Unit tests were created along the way. Nouveau, ch7006 and gud are
>>> currently broken for now since I expect that work to be reworked fairly
>>> significantly. I'm also not entirely sure about how to migrate GUD to the
>>> new property.
>>>
>>> Let me know what you think,
>>> Maxime
>>>
>> I don't know if it's related to this patchset or not, but I do get this:
>>
>> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
>> && dmesg
>> [  430.066211] Console: switching to colour dummy device 80x30
>> [  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>> [  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
>> [  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>> [  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
>> [vc4])
>> [  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>> [  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>> timed out
>> [  441.446529] Console: switching to colour frame buffer device 90x30
>> [  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
>> timed out
>> [  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
>> commit wait timed out
>> [  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
>> timed out
>> [  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
>> [  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>> timed out
>> [  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> Module unloading/reloading has been janky for a while.
>
> I've fixed it up recently but it doesn't surprise me that there's still
> some situation that won't work. Is it on a Pi3?
>
> Maxime

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Maxime Ripard]

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

Hi Mateusz,

On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
> 
> I tried testing and reviewing your changes properly over the last weekend, but
> ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
> mitigate it, at least so far. This seems to pop up every time I try to change
> modes in any way (either change the TV norm, or just try doing
> "xrandr --output Composite-1 --off" followed by bringing it back on; it also
> means that the Pi goes unusable when the DE's screen saving routine kicks in).
> 
> I'm using a Pi 4, and it works with the rpi-5.13.y branch
> https://github.com/raspberrypi/linux, but seemingly nothing newer.
> I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
> which is the current main branch in Raspberry Pi OS, seems to be broken since
> forever; at least since my patches (originally written for 5.10) landed there.
> 
> I'll try identifying the issue further, possibly later today, and maybe check
> the rpi-6.0.y branch as well.

I've tried it this, and I can't reproduce it here. But I'm curious, how
did you apply this series? rpi-5.13.y is probably full of conflicts
everywhere?

Maxime

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

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Mateusz Kwiatkowski]

Hi Maxime,

W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
> Hi Mateusz,
>
> On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> I tried testing and reviewing your changes properly over the last weekend, but
>> ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
>> mitigate it, at least so far. This seems to pop up every time I try to change
>> modes in any way (either change the TV norm, or just try doing
>> "xrandr --output Composite-1 --off" followed by bringing it back on; it also
>> means that the Pi goes unusable when the DE's screen saving routine kicks in).
>>
>> I'm using a Pi 4, and it works with the rpi-5.13.y branch
>> https://github.com/raspberrypi/linux, but seemingly nothing newer.
>> I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
>> which is the current main branch in Raspberry Pi OS, seems to be broken since
>> forever; at least since my patches (originally written for 5.10) landed there.
>>
>> I'll try identifying the issue further, possibly later today, and maybe check
>> the rpi-6.0.y branch as well.
>
> I've tried it this, and I can't reproduce it here. But I'm curious, how
> did you apply this series? rpi-5.13.y is probably full of conflicts
> everywhere?

I applied your patches onto rpi-5.15.y. There were conflicts, but they seemed
relatively minor. I'm not sure if I did a good job at resolving them - I ran
into various problems trying to test your changes, but I chose not to criticize
you before making sure that it's really due to your changes, or without some
remarks more constructive than "doesn't work" ;-)

I can push my rebase onto some Github fork if you're interested.

I was able to work around some of those problems, and also saw that some
of them were already mentioned by other reviewers (such as the generic modes
not matching due to the aspect ratio setting).

Ultimately I got stuck on this bug, so I put testing this series on hold
in favor of debugging the bigger issue. So far unfortunately no luck with it.

I did not try rebasing your changes onto 5.13 or older.

> Maxime

Best regards,
Mateusz Kwiatkowski

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Mateusz Kwiatkowski]

Hi Maxime, Noralf and everyone,

Just as a quick update. I isolated the issue to the power management subsystem.
Unfortunately I know very little about the power management subsystem so
I don't think I can help.

There are two alternative dirty ad-hoc hacks that get things working.

- Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
- Reverting this PR by Dom Cobley a.k.a. popcornmix:
   https://github.com/raspberrypi/linux/pull/4639

Either of these approaches makes VEC mode switching work again. Obviously
neither is appropriate for a permanent solution.

I tried some random code permutations that came to my mind, like using the
vc4_encoder callbacks (e.g. post_crtc_powerdown) instead of the standard
enable/disable encoder callbacks, but to no avail.

Since the clocks and power management seem to be delegated to the firmware now,
my guess is that this might be a firmware issue, but I can't really check all
the firmware versions. It certainly crashes on the version currently available
in Raspberry Pi OS repos, and on this one:
https://github.com/raspberrypi/rpi-firmware/commit/4dde751. My Pi4 doesn't boot
using any newer firmware, at least not from USB - I might try some SD card
after the weekend.

Best regards,
Mateusz Kwiatkowski

W dniu 25.08.2022 o 18:17, Mateusz Kwiatkowski pisze:
> Hi Maxime,
>
> W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
>> Hi Mateusz,
>>
>> On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
>>> Hi Maxime,
>>>
>>> I tried testing and reviewing your changes properly over the last weekend, but
>>> ultimately ran into this ("flip_done timed out" etc.) issue and was unable to
>>> mitigate it, at least so far. This seems to pop up every time I try to change
>>> modes in any way (either change the TV norm, or just try doing
>>> "xrandr --output Composite-1 --off" followed by bringing it back on; it also
>>> means that the Pi goes unusable when the DE's screen saving routine kicks in).
>>>
>>> I'm using a Pi 4, and it works with the rpi-5.13.y branch
>>> https://github.com/raspberrypi/linux, but seemingly nothing newer.
>>> I specifically tried rpi-5.14.y, rpi-5.15.y and rpi-5.19.y - rpi-5.15.y,
>>> which is the current main branch in Raspberry Pi OS, seems to be broken since
>>> forever; at least since my patches (originally written for 5.10) landed there.
>>>
>>> I'll try identifying the issue further, possibly later today, and maybe check
>>> the rpi-6.0.y branch as well.
>> I've tried it this, and I can't reproduce it here. But I'm curious, how
>> did you apply this series? rpi-5.13.y is probably full of conflicts
>> everywhere?
> I applied your patches onto rpi-5.15.y. There were conflicts, but they seemed
> relatively minor. I'm not sure if I did a good job at resolving them - I ran
> into various problems trying to test your changes, but I chose not to criticize
> you before making sure that it's really due to your changes, or without some
> remarks more constructive than "doesn't work" ;-)
>
> I can push my rebase onto some Github fork if you're interested.
>
> I was able to work around some of those problems, and also saw that some
> of them were already mentioned by other reviewers (such as the generic modes
> not matching due to the aspect ratio setting).
>
> Ultimately I got stuck on this bug, so I put testing this series on hold
> in favor of debugging the bigger issue. So far unfortunately no luck with it.
>
> I did not try rebasing your changes onto 5.13 or older.
>
>> Maxime
> Best regards,
> Mateusz Kwiatkowski

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Maxime Ripard]

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

On Fri, Aug 26, 2022 at 06:07:47AM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime, Noralf and everyone,
> 
> Just as a quick update. I isolated the issue to the power management subsystem.
> Unfortunately I know very little about the power management subsystem so
> I don't think I can help.
> 
> There are two alternative dirty ad-hoc hacks that get things working.
> 
> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
> - Reverting this PR by Dom Cobley a.k.a. popcornmix:
>   https://github.com/raspberrypi/linux/pull/4639

We don't have that PR upstream, so that might be the explanation to why
you're seeing this and I don't. I'll look into this further and will
open an issue.

I can't see anything wrong with the pm_runtime use though.

> Either of these approaches makes VEC mode switching work again. Obviously
> neither is appropriate for a permanent solution.
> 
> I tried some random code permutations that came to my mind, like using the
> vc4_encoder callbacks (e.g. post_crtc_powerdown) instead of the standard
> enable/disable encoder callbacks, but to no avail.
> 
> Since the clocks and power management seem to be delegated to the firmware now,
> my guess is that this might be a firmware issue, but I can't really check all
> the firmware versions. It certainly crashes on the version currently available
> in Raspberry Pi OS repos, and on this one:
> https://github.com/raspberrypi/rpi-firmware/commit/4dde751. My Pi4 doesn't boot
> using any newer firmware, at least not from USB - I might try some SD card
> after the weekend.

Thanks for your testing

Maxime

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

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Dom Cobley]

On Fri, 26 Aug 2022 at 05:08, Mateusz Kwiatkowski <kfyatek@gmail.com> wrote:
> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
> - Reverting this PR by Dom Cobley a.k.a. popcornmix:
>    https://github.com/raspberrypi/linux/pull/4639
>
> Either of these approaches makes VEC mode switching work again. Obviously
> neither is appropriate for a permanent solution.

Might be worth trying the latest rpi-update firmware.
There was a change that affects restoring PIXEL/VEC clocks after a
power domain cycle.
There is also a fix for a USB boot breakage.

If you still have an issue that occurs in downstream pi tree but not
upstream, then create a linux github issue.

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Noralf Trønnes]

Den 26.08.2022 16.56, skrev Dom Cobley:
> On Fri, 26 Aug 2022 at 05:08, Mateusz Kwiatkowski <kfyatek@gmail.com> wrote:
>> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
>> - Reverting this PR by Dom Cobley a.k.a. popcornmix:
>>    https://github.com/raspberrypi/linux/pull/4639
>>
>> Either of these approaches makes VEC mode switching work again. Obviously
>> neither is appropriate for a permanent solution.
> 
> Might be worth trying the latest rpi-update firmware.
> There was a change that affects restoring PIXEL/VEC clocks after a
> power domain cycle.
> There is also a fix for a USB boot breakage.
> 

That firmware gives me firmware timeout references in the 5 attempts
I've done.

My first attempt gave me this:

[  112.454982] WARNING: CPU: 2 PID: 855 at
drivers/firmware/raspberrypi.c:63 rpi_firmware_property_list+0x204/0x270
[  112.466985] Firmware transaction timeout
...
[  112.533740]  warn_slowpath_fmt from
rpi_firmware_property_list+0x204/0x270
[  112.541449]  rpi_firmware_property_list from
rpi_firmware_property+0x68/0x94
[  112.549326]  rpi_firmware_property from
raspberrypi_clock_property+0x50/0x84
[  112.557197]  raspberrypi_clock_property from
raspberrypi_fw_set_rate+0x4c/0xc4
[  112.565242]  raspberrypi_fw_set_rate from clk_change_rate+0x16c/0x6f8
[  112.572502]  clk_change_rate from clk_core_set_rate_nolock+0x1c4/0x2a4
[  112.579857]  clk_core_set_rate_nolock from
clk_set_rate_range.part.0+0x128/0x2ac
[  112.588091]  clk_set_rate_range.part.0 from
vc4_atomic_commit_tail+0x2b4/0x854 [vc4]
[  112.596832]  vc4_atomic_commit_tail [vc4] from commit_tail+0xa4/0x19c
[  112.604269]  commit_tail from drm_atomic_helper_commit+0x16c/0x194
[  112.611279]  drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xec
[  112.618625]  drm_atomic_commit from drm_mode_atomic_ioctl+0x8f0/0xb6c
[  112.625877]  drm_mode_atomic_ioctl from drm_ioctl_kernel+0xcc/0x170
[  112.632950]  drm_ioctl_kernel from drm_ioctl+0x1d8/0x374
[  112.639056]  drm_ioctl from sys_ioctl+0xe4/0xbac
[  112.644462]  sys_ioctl from ret_fast_syscall+0x0/0x1c
...
[  112.726171] raspberrypi-clk soc:firmware:clocks: Failed to change
fw-clk-core frequency: -110

I've also done one with drm debug enabled.
Kernel messages:
https://gist.github.com/notro/53afe9fdc3d0afbf0fb12678be1ab377

Dom, in case you want to debug this I've uploaded a rpi-update'able
archive plus config.txt and cmdline.txt.
There are some custom overlays in there that are needed.

Kernel: tronnes.org/downloads/vec-kernel-2022-08-27.gz
Build/setup info from another post:
https://gist.github.com/notro/41c59d77c3022dc6d931d4f9547c4ea6

I've tried this on another Pi4 (same revision: c03111) as well to rule
out any hw issues. The first attempt also gave me an mmc fault (no dmesg
-w) and the second one (dmesg -w) gave me the timeout.

Noralf.

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[kFYatek]

W dniu 26.08.2022 o 16:56, Dom Cobley pisze:
> On Fri, 26 Aug 2022 at 05:08, Mateusz Kwiatkowski <kfyatek@gmail.com> wrote:
>> - Commenting out the pm_runtime_put() / pm_runtime_get_sync() calls in vc4_vec.c
>> - Reverting this PR by Dom Cobley a.k.a. popcornmix:
>>    https://github.com/raspberrypi/linux/pull/4639
>>
>> Either of these approaches makes VEC mode switching work again. Obviously
>> neither is appropriate for a permanent solution.
> Might be worth trying the latest rpi-update firmware.
> There was a change that affects restoring PIXEL/VEC clocks after a
> power domain cycle.
> There is also a fix for a USB boot breakage.
>
> If you still have an issue that occurs in downstream pi tree but not
> upstream, then create a linux github issue.

Hi Dom,

I just tested the 868f1cf firmware and its associated kernel, and everything
works like a charm for me, both USB boot and VEC power management.

Thanks!

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Noralf Trønnes]

Den 22.08.2022 09.48, skrev Maxime Ripard:
> Hi,
> 
> On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>> Hi,
>>>
>>> Here's a series aiming at improving the command line named modes support,
>>> and more importantly how we deal with all the analog TV variants.
>>>
>>> The named modes support were initially introduced to allow to specify the
>>> analog TV mode to be used.
>>>
>>> However, this was causing multiple issues:
>>>
>>>   * The mode name parsed on the command line was passed directly to the
>>>     driver, which had to figure out which mode it was suppose to match;
>>>
>>>   * Figuring that out wasn't really easy, since the video= argument or what
>>>     the userspace might not even have a name in the first place, but
>>>     instead could have passed a mode with the same timings;
>>>
>>>   * The fallback to matching on the timings was mostly working as long as
>>>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
>>>     (PAL), but couldn't differentiate between two modes with the same
>>>     timings (NTSC vs PAL-M vs NSTC-J for example); 
>>>
>>>   * There was also some overlap with the tv mode property registered by 
>>>     drm_mode_create_tv_properties(), but named modes weren't interacting
>>>     with that property at all.
>>>
>>>   * Even though that property was generic, its possible values were
>>>     specific to each drivers, which made some generic support difficult.
>>>
>>> Thus, I chose to tackle in multiple steps:
>>>
>>>   * A new TV norm property was introduced, with generic values, each driver
>>>     reporting through a bitmask what standard it supports to the userspace;
>>>
>>>   * This option was added to the command line parsing code to be able to
>>>     specify it on the kernel command line, and new atomic_check and reset
>>>     helpers were created to integrate properly into atomic KMS;
>>>
>>>   * The named mode parsing code is now creating a proper display mode for
>>>     the given named mode, and the TV standard will thus be part of the
>>>     connector state;
>>>
>>>   * Two drivers were converted and tested for now (vc4 and sun4i), with
>>>     some backward compatibility code to translate the old TV mode to the
>>>     new TV mode;
>>>
>>> Unit tests were created along the way. Nouveau, ch7006 and gud are
>>> currently broken for now since I expect that work to be reworked fairly
>>> significantly. I'm also not entirely sure about how to migrate GUD to the
>>> new property.
>>>
>>> Let me know what you think,
>>> Maxime
>>>
>>
>> I don't know if it's related to this patchset or not, but I do get this:
>>
>> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
>> && dmesg
>> [  430.066211] Console: switching to colour dummy device 80x30
>> [  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>> [  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
>> [  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>> [  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
>> [vc4])
>> [  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>> [  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>> timed out
>> [  441.446529] Console: switching to colour frame buffer device 90x30
>> [  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
>> timed out
>> [  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
>> commit wait timed out
>> [  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
>> timed out
>> [  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>> [  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
>> [  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>> timed out
>> [  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> 
> Module unloading/reloading has been janky for a while.
> 
> I've fixed it up recently but it doesn't surprise me that there's still
> some situation that won't work. Is it on a Pi3?
> 

It's a Pi4.

Noralf.

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Maxime Ripard]

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

On Mon, Aug 22, 2022 at 03:21:29PM +0200, Noralf Trønnes wrote:
> 
> 
> Den 22.08.2022 09.48, skrev Maxime Ripard:
> > Hi,
> > 
> > On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
> >> Den 29.07.2022 18.34, skrev Maxime Ripard:
> >>> Hi,
> >>>
> >>> Here's a series aiming at improving the command line named modes support,
> >>> and more importantly how we deal with all the analog TV variants.
> >>>
> >>> The named modes support were initially introduced to allow to specify the
> >>> analog TV mode to be used.
> >>>
> >>> However, this was causing multiple issues:
> >>>
> >>>   * The mode name parsed on the command line was passed directly to the
> >>>     driver, which had to figure out which mode it was suppose to match;
> >>>
> >>>   * Figuring that out wasn't really easy, since the video= argument or what
> >>>     the userspace might not even have a name in the first place, but
> >>>     instead could have passed a mode with the same timings;
> >>>
> >>>   * The fallback to matching on the timings was mostly working as long as
> >>>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
> >>>     (PAL), but couldn't differentiate between two modes with the same
> >>>     timings (NTSC vs PAL-M vs NSTC-J for example); 
> >>>
> >>>   * There was also some overlap with the tv mode property registered by 
> >>>     drm_mode_create_tv_properties(), but named modes weren't interacting
> >>>     with that property at all.
> >>>
> >>>   * Even though that property was generic, its possible values were
> >>>     specific to each drivers, which made some generic support difficult.
> >>>
> >>> Thus, I chose to tackle in multiple steps:
> >>>
> >>>   * A new TV norm property was introduced, with generic values, each driver
> >>>     reporting through a bitmask what standard it supports to the userspace;
> >>>
> >>>   * This option was added to the command line parsing code to be able to
> >>>     specify it on the kernel command line, and new atomic_check and reset
> >>>     helpers were created to integrate properly into atomic KMS;
> >>>
> >>>   * The named mode parsing code is now creating a proper display mode for
> >>>     the given named mode, and the TV standard will thus be part of the
> >>>     connector state;
> >>>
> >>>   * Two drivers were converted and tested for now (vc4 and sun4i), with
> >>>     some backward compatibility code to translate the old TV mode to the
> >>>     new TV mode;
> >>>
> >>> Unit tests were created along the way. Nouveau, ch7006 and gud are
> >>> currently broken for now since I expect that work to be reworked fairly
> >>> significantly. I'm also not entirely sure about how to migrate GUD to the
> >>> new property.
> >>>
> >>> Let me know what you think,
> >>> Maxime
> >>>
> >>
> >> I don't know if it's related to this patchset or not, but I do get this:
> >>
> >> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
> >> && dmesg
> >> [  430.066211] Console: switching to colour dummy device 80x30
> >> [  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> [  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
> >> [  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> >> [  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
> >> [vc4])
> >> [  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> >> [  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
> >> timed out
> >> [  441.446529] Console: switching to colour frame buffer device 90x30
> >> [  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> >> [  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
> >> timed out
> >> [  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> >> [  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
> >> commit wait timed out
> >> [  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> >> [  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
> >> timed out
> >> [  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
> >> [  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
> >> [  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
> >> timed out
> >> [  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> > 
> > Module unloading/reloading has been janky for a while.
> > 
> > I've fixed it up recently but it doesn't surprise me that there's still
> > some situation that won't work. Is it on a Pi3?
> > 
> 
> It's a Pi4.

With which kernel? I just tested it on last next and it seems to work ok
there. I've fixed it recently though, so it's only in drm-misc-next and
linux-next at the moment.

Maxime

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

Re: [PATCH v1 00/35] drm: Analog TV Improvements

[Noralf Trønnes]

Den 25.08.2022 18.21, skrev Maxime Ripard:
> On Mon, Aug 22, 2022 at 03:21:29PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 22.08.2022 09.48, skrev Maxime Ripard:
>>> Hi,
>>>
>>> On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
>>>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>>> Hi,
>>>>>
>>>>> Here's a series aiming at improving the command line named modes support,
>>>>> and more importantly how we deal with all the analog TV variants.
>>>>>
>>>>> The named modes support were initially introduced to allow to specify the
>>>>> analog TV mode to be used.
>>>>>
>>>>> However, this was causing multiple issues:
>>>>>
>>>>>   * The mode name parsed on the command line was passed directly to the
>>>>>     driver, which had to figure out which mode it was suppose to match;
>>>>>
>>>>>   * Figuring that out wasn't really easy, since the video= argument or what
>>>>>     the userspace might not even have a name in the first place, but
>>>>>     instead could have passed a mode with the same timings;
>>>>>
>>>>>   * The fallback to matching on the timings was mostly working as long as
>>>>>     we were supporting one 525 lines (most likely NSTC) and one 625 lines
>>>>>     (PAL), but couldn't differentiate between two modes with the same
>>>>>     timings (NTSC vs PAL-M vs NSTC-J for example); 
>>>>>
>>>>>   * There was also some overlap with the tv mode property registered by 
>>>>>     drm_mode_create_tv_properties(), but named modes weren't interacting
>>>>>     with that property at all.
>>>>>
>>>>>   * Even though that property was generic, its possible values were
>>>>>     specific to each drivers, which made some generic support difficult.
>>>>>
>>>>> Thus, I chose to tackle in multiple steps:
>>>>>
>>>>>   * A new TV norm property was introduced, with generic values, each driver
>>>>>     reporting through a bitmask what standard it supports to the userspace;
>>>>>
>>>>>   * This option was added to the command line parsing code to be able to
>>>>>     specify it on the kernel command line, and new atomic_check and reset
>>>>>     helpers were created to integrate properly into atomic KMS;
>>>>>
>>>>>   * The named mode parsing code is now creating a proper display mode for
>>>>>     the given named mode, and the TV standard will thus be part of the
>>>>>     connector state;
>>>>>
>>>>>   * Two drivers were converted and tested for now (vc4 and sun4i), with
>>>>>     some backward compatibility code to translate the old TV mode to the
>>>>>     new TV mode;
>>>>>
>>>>> Unit tests were created along the way. Nouveau, ch7006 and gud are
>>>>> currently broken for now since I expect that work to be reworked fairly
>>>>> significantly. I'm also not entirely sure about how to migrate GUD to the
>>>>> new property.
>>>>>
>>>>> Let me know what you think,
>>>>> Maxime
>>>>>
>>>>
>>>> I don't know if it's related to this patchset or not, but I do get this:
>>>>
>>>> pi@pi4t:~ $ sudo dmesg -C && sudo modprobe -r vc4 && sudo modprobe vc4
>>>> && dmesg
>>>> [  430.066211] Console: switching to colour dummy device 80x30
>>>> [  431.294788] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>>>> [  431.295115] vc4-drm gpu: bound fec13000.vec (ops vc4_vec_ops [vc4])
>>>> [  431.295467] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
>>>> [  431.295804] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops
>>>> [vc4])
>>>> [  431.298895] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
>>>> [  441.444250] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>>>> timed out
>>>> [  441.446529] Console: switching to colour frame buffer device 90x30
>>>> [  451.684321] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>>>> [  451.684347] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] commit wait
>>>> timed out
>>>> [  461.924255] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>>>> [  461.924281] vc4-drm gpu: [drm] *ERROR* [CONNECTOR:45:Composite-1]
>>>> commit wait timed out
>>>> [  472.164006] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>>>> [  472.164031] vc4-drm gpu: [drm] *ERROR* [PLANE:61:plane-1] commit wait
>>>> timed out
>>>> [  482.403877] vc4-drm gpu: [drm] *ERROR* flip_done timed out
>>>> [  482.403903] vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
>>>> [  492.643799] vc4-drm gpu: [drm] *ERROR* [CRTC:68:crtc-1] flip_done
>>>> timed out
>>>> [  492.647073] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
>>>
>>> Module unloading/reloading has been janky for a while.
>>>
>>> I've fixed it up recently but it doesn't surprise me that there's still
>>> some situation that won't work. Is it on a Pi3?
>>>
>>
>> It's a Pi4.
> 
> With which kernel? I just tested it on last next and it seems to work ok
> there. I've fixed it recently though, so it's only in drm-misc-next and
> linux-next at the moment.
> 

I'm on a week old drm-misc-next.

What's your setup so I can try that.

This is mine:
https://gist.github.com/notro/41c59d77c3022dc6d931d4f9547c4ea6

I can't see anything that should differ significantly from what you
could have done. Only maybe that I use the latest firmware and perhaps
you've got a 64-bit kernel.

Noralf.