vc4 / HDMI fixes for 6.12

[6by9]

Still doesn't support YUV422, but better than before.
Now has YUV422 support too.

@popcornmix @HiassofT

[popcornmix]

Can confirm this fixes issue where HDR is left enabled after disabling (clear infoframe).

I now get 8 bit mode for 1080p60
Mode 1920x1080 @ 60Hz: Found configuration: bpc: 8, fmt: RGB, clock: 148500000
When 12-bit requested and 4kp24 I get
Mode 3840x2160 @ 24Hz: Found configuration: bpc: 12, fmt: RGB, clock: 445054500
When 12-bit requested and 4kp60
Mode 3840x2160 @ 60Hz: Found configuration: bpc: 12, fmt: YUV 4:2:2, clock: 593407000

which are all as expected.

[6by9]

As @HiassofT has reported, I am also still seeing the default max_bpc being 12. I'm just investigating....

[HiassofT]

bpc limiting doesn't seem to work here, I'm still getting 1920x1200@60-12bpc here with my monitor, both in LibreELEC and also in RPiOS with rpi-update pulls/6485 and kmsprint -p shows the max bpc connector property is still set to 12.

[    6.033692] vc4-drm axi:gpu: [drm:drm_atomic_helper_connector_hdmi_check [drm_display_helper]] Trying with a 12 bpc output
[    6.033701] vc4-drm axi:gpu: [drm:hdmi_try_format_bpc [drm_display_helper]] Trying RGB output format
[    6.033710] vc4-drm axi:gpu: [drm:hdmi_try_format_bpc [drm_display_helper]] RGB Format, checking the constraints.
[    6.033713] vc4-drm axi:gpu: [drm:hdmi_try_format_bpc [drm_display_helper]] RGB format supported in that configuration.
[    6.033722] vc4-drm axi:gpu: [drm:hdmi_try_format_bpc [drm_display_helper]] RGB output format supported with 12 (TMDS char rate: 231000000 Hz)
[    6.033726] vc4-drm axi:gpu: [drm:drm_atomic_helper_connector_hdmi_check [drm_display_helper]] Mode 1920x1200 @ 60Hz: Found configuration: bpc: 12, fmt: RGB, clock: 231000000

Connector 0 (33) HDMI-A-1 (connected)
    EDID (1) = blob-id 678 len 256 (immutable)
    DPMS (2) = 0 (On) [On=0|Standby=1|Suspend=2|Off=3]
    TILE (4) = blob-id 0 (immutable)
    link-status (5) = 0 (Good) [Good=0|Bad=1]
    non-desktop (6) = 0 [0 - 1] (immutable)
    HDR_OUTPUT_METADATA (7) = blob-id 0
    CRTC_ID (20) = object id 92
    max bpc (34) = 12 [8 - 12]
    left margin (35) = 0 [0 - 100]
    right margin (36) = 0 [0 - 100]
    top margin (37) = 0 [0 - 100]
    bottom margin (38) = 0 [0 - 100]
    Colorspace (39) = 0 (Default) [Default=0|SMPTE_170M_YCC=1|BT709_YCC=2|XVYCC_601=3|XVYCC_709=4|SYCC_601=5|opYCC_601=6|opRGB=7|BT2020_CYCC=8|BT2020_RGB=9|BT2020_YCC=10|DCI-P3_RGB_D65=11|DCI-P3_RGB_Theater=12]
    Broadcast RGB (40) = 0 (Automatic) [Automatic=0|Full=1|Limited 16:235=2]

I've attached full dmesg with drm.debug=0x06 and base64 encoded edid of my monitor (same one as posted on LE slack)
dmesg-PR6485.txt
edid-hannspree-hf287.txt

[6by9]

PR updated so that __drm_atomic_helper_connector_hdmi_reset sets max_requested_bpc to 8, and that does seem to fix it for me.

[HiassofT]

I also noticed the Output format connector property seems to be gone in 6.12.

kmsprint -p on RPiOS 6.6.62:

Connector 0 (32) HDMI-A-1 (connected)
    EDID (1) = blob-id 681 len 256 (immutable)
    DPMS (2) = 0 (On) [On=0|Standby=1|Suspend=2|Off=3]
    TILE (4) = blob-id 0 (immutable)
    link-status (5) = 0 (Good) [Good=0|Bad=1]
    non-desktop (6) = 0 [0 - 1] (immutable)
    HDR_OUTPUT_METADATA (7) = blob-id 0
    CRTC_ID (20) = object id 93
    left margin (33) = 0 [0 - 100]
    right margin (34) = 0 [0 - 100]
    top margin (35) = 0 [0 - 100]
    bottom margin (36) = 0 [0 - 100]
    Colorspace (37) = 0 (Default) [Default=0|SMPTE_170M_YCC=1|BT709_YCC=2|XVYCC_601=3|XVYCC_709=4|SYCC_601=5|opYCC_601=6|opRGB=7|BT2020_CYCC=8|BT2020_RGB=9|BT2020_YCC=10|DCI-P3_RGB_D65=11|DCI-P3_RGB_Theater=12]
    max bpc (38) = 8 [8 - 12]
    Broadcast RGB (39) = 0 (Automatic) [Automatic=0|Full=1|Limited 16:235=2]
    Output format (40) = 0 (Automatic) [Automatic=0|RGB=1|YCbCr 4:2:2=2|YCbCr 4:4:4=3]

[6by9]

I also noticed the Output format connector property seems to be gone in 6.12.

Yes it has for the time being. This is the fun with upstream changing, and then downstream patches won't apply.

I have all my 2712 patches now reviewed for upstream, so I'm likely to revert all the downstream patches, apply those upstream ones, and then reimplement any features that haven't been upstreamed (hopefully not too many, and in a form that can be upstreamed where acceptable).
That then gives us a clean slate on 6.12 whilst we're still rebasing, and will make the updates in 6.13/14 far easier to manage. Of course it may introduce regressions in the process.....

[HiassofT]

thanks, pulling in upstream-next changes and basing on them sounds like a very good idea to me, too

[HiassofT]

Thanks a lot, bpc and YCC422 switching seems to work fine now, and it's also nice that YCC422 can now get selected with max bpc 10