mbox series

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

Message ID 20220728-rpi-analog-tv-properties-v1-0-3d53ae722097@cerno.tech (mailing list archive)
Headers show
Series drm: Analog TV Improvements | expand

Message

Maxime Ripard July 29, 2022, 4:34 p.m. UTC
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,

Comments

Noralf Trønnes Aug. 8, 2022, 1:03 p.m. UTC | #1
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.
Noralf Trønnes Aug. 21, 2022, 4:33 p.m. UTC | #2
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.
Maxime Ripard Aug. 22, 2022, 7:48 a.m. UTC | #3
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
Mateusz Kwiatkowski Aug. 22, 2022, 8:57 a.m. UTC | #4
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
Noralf Trønnes Aug. 22, 2022, 1:21 p.m. UTC | #5
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.
Maxime Ripard Aug. 25, 2022, 3:55 p.m. UTC | #6
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
Mateusz Kwiatkowski Aug. 25, 2022, 4:17 p.m. UTC | #7
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
Maxime Ripard Aug. 25, 2022, 4:21 p.m. UTC | #8
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
Noralf Trønnes Aug. 25, 2022, 7:36 p.m. UTC | #9
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.
Mateusz Kwiatkowski Aug. 26, 2022, 4:07 a.m. UTC | #10
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
Maxime Ripard Aug. 26, 2022, 8:39 a.m. UTC | #11
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
Dom Cobley Aug. 26, 2022, 2:56 p.m. UTC | #12
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.
Noralf Trønnes Aug. 27, 2022, 4:11 p.m. UTC | #13
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.
Mateusz Kwiatkowski Aug. 30, 2022, 9:31 p.m. UTC | #14
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!