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(-)
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>
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.
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
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.
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
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.
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
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
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
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
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.
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!
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.
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
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.
© 2016 - 2026 Red Hat, Inc.