| Message ID | 20220728-rpi-analog-tv-properties-v1-0-3d53ae722097@cerno.tech (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Analog TV Improvements | expand |
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.
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
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
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.
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
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, 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, 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
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.
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.
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!
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,