Re: [Nouveau] [PATCH v10 18/19] drm/vc4: vec: Add support for more analog TV standards

2022-11-17 Thread Maxime Ripard
On Thu, Nov 17, 2022 at 04:49:28PM +0100, Mauro Carvalho Chehab wrote: > On Thu, 17 Nov 2022 10:29:01 +0100 > Maxime Ripard wrote: > > > From: Mateusz Kwiatkowski > > > > Add support for the following composite output modes (all of them are > > somewhat more obscure than the previously defined

Re: [Nouveau] [PATCH v10 05/19] drm/connector: Add TV standard property

2022-11-17 Thread Maxime Ripard
On Thu, Nov 17, 2022 at 03:35:57PM +0100, Mauro Carvalho Chehab wrote: > On Thu, 17 Nov 2022 10:28:48 +0100 > Maxime Ripard 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

Re: [Nouveau] [PATCH v10 01/19] drm/tests: client: Mention that we can't use MODULE_ macros

2022-11-17 Thread Noralf Trønnes
Den 17.11.2022 10.28, skrev Maxime Ripard: > That file is included directly, so we can't use any MODULE macro. Let's > leave a comment to avoid any future mistake. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Noralf Trønnes

[Nouveau] [PATCH v10 19/19] drm/sun4i: tv: Convert to the new TV mode property

2022-11-17 Thread 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. Acked-by: Noralf Trønnes Reviewed-by: Jernej Skrabec Signed-off-by: Maxime Ripard --- Changes in v6: - Convert to new get_modes helper Changes in v5: - Removed the count

[Nouveau] [PATCH v10 18/19] drm/vc4: vec: Add support for more analog TV standards

2022-11-17 Thread Maxime Ripard
From: Mateusz Kwiatkowski 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

[Nouveau] [PATCH v10 16/19] drm/vc4: vec: Check for VEC output constraints

2022-11-17 Thread Maxime Ripard
From: Mateusz Kwiatkowski The VEC can accept pretty much any relatively reasonable mode, but still has a bunch of constraints to meet. Let's create an atomic_check() implementation that will make sure we don't end up accepting a non-functional mode. Acked-by: Noralf Trønnes Signed-off-by:

[Nouveau] [PATCH v10 17/19] drm/vc4: vec: Convert to the new TV mode property

2022-11-17 Thread 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. We're also making use of the new analog TV

[Nouveau] [PATCH v10 15/19] drm/vc4: vec: Use TV Reset implementation

2022-11-17 Thread 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(). Reviewed-by: Noralf Trønnes Tested-by: Mateusz Kwiatkowski Signed-off-by: Maxime Ripard ---

[Nouveau] [PATCH v10 14/19] drm/atomic-helper: Add an analog TV atomic_check implementation

2022-11-17 Thread Maxime Ripard
The analog TV connector drivers share some atomic_check logic, and the new TV standard property have created some boilerplate that can be shared across drivers too. Let's create an atomic_check helper for those use cases. Reviewed-by: Noralf Trønnes Tested-by: Mateusz Kwiatkowski

[Nouveau] [PATCH v10 13/19] drm/atomic-helper: Add a TV properties reset helper

2022-11-17 Thread 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. Reviewed-by: Noralf Trønnes

[Nouveau] [PATCH v10 12/19] drm/probe-helper: Provide a TV get_modes helper

2022-11-17 Thread Maxime Ripard
From: Noralf Trønnes Most of the TV connectors will need a similar get_modes implementation that will, depending on the drivers' capabilities, register the 480i and 576i modes. That implementation will also need to set the preferred flag and order the modes based on the driver and users

[Nouveau] [PATCH v10 11/19] drm/modes: Introduce more named modes

2022-11-17 Thread 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. Reviewed-by: Noralf Trønnes Tested-by: Mateusz Kwiatkowski Signed-off-by: Maxime Ripard --- Changes in v9: - Document the

[Nouveau] [PATCH v10 10/19] drm/client: Remove match on mode name

2022-11-17 Thread Maxime Ripard
Commit 3aeeb13d8996 ("drm/modes: Support modes names on the command line") initially introduced the named modes support by essentially matching the name passed on the command-line to the mode names defined by the drivers. This proved to be difficult to work with, since all drivers had to provide

[Nouveau] [PATCH v10 08/19] drm/modes: Introduce the tv_mode property as a command-line option

2022-11-17 Thread 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. Reviewed-by:

[Nouveau] [PATCH v10 09/19] drm/modes: Properly generate a drm_display_mode from a named mode

2022-11-17 Thread 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,

[Nouveau] [PATCH v10 06/19] drm/modes: Add a function to generate analog display modes

2022-11-17 Thread Maxime Ripard
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and 625-lines modes in their drivers. Since those modes are fairly standard, and that we'll need to use them in more places in the future, it makes sense to move their definition into the core framework. However, analog display

[Nouveau] [PATCH v10 07/19] drm/connector: Add a function to lookup a TV mode by its name

2022-11-17 Thread Maxime Ripard
As part of the command line parsing rework coming in the next patches, we'll need to lookup drm_connector_tv_mode values by their name, already defined in drm_tv_mode_enum_list. In order to avoid any code duplication, let's do a function that will perform a lookup of a TV mode name and return its

[Nouveau] [PATCH v10 05/19] drm/connector: Add TV standard property

2022-11-17 Thread 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

[Nouveau] [PATCH v10 04/19] drm/connector: Rename drm_mode_create_tv_properties

2022-11-17 Thread Maxime Ripard
drm_mode_create_tv_properties(), among other things, will create the "mode" property that stores the analog TV mode that connector is supposed to output. However, that property is getting deprecated, so let's rename that function to mention it's deprecated. We'll introduce a new variant of that

[Nouveau] [PATCH v10 02/19] drm/connector: Rename legacy TV property

2022-11-17 Thread Maxime Ripard
The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away

[Nouveau] [PATCH v10 03/19] drm/connector: Only register TV mode property if present

2022-11-17 Thread 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. Acked-by: Noralf Trønnes Tested-by: Mateusz Kwiatkowski

[Nouveau] [PATCH v10 01/19] drm/tests: client: Mention that we can't use MODULE_ macros

2022-11-17 Thread Maxime Ripard
That file is included directly, so we can't use any MODULE macro. Let's leave a comment to avoid any future mistake. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/tests/drm_client_modeset_test.c | 5 + 1 file changed, 5 insertions(+) diff --git

[Nouveau] [PATCH v10 00/19] drm: Analog TV Improvements

2022-11-17 Thread 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: *