[regression] RPI4B drm vc4: no crtc or sizes since 5.17 (works in 5.16; and still broken in at least 6.1)

Thu Mar 9 12:34:29 UTC 2023

On Thu, 9 Mar 2023 at 11:26, AL13N <alien at rmail.be> wrote:
>
> Dave Stevenson schreef op 2023-03-07 18:10:
> > Hi Maarten
> >
> > On Tue, 7 Mar 2023 at 16:25, AL13N <alien at rmail.be> wrote:
> >>
> >> AL13N schreef op 2023-03-06 17:34:
> >> > Hi,
> >> >
> >> > I have a RPI4B connected on 2nd HDMI port (furthest away from power)
> >> > to a 4K TV, which works until 5.16, from 5.17 there is no X (or
> >> > plymouth), the cause of no X is that EDID gives nothing, and in the
> >> > journal; there is "Cannot find any crct or sizes". Only the kernel is
> >> > changed for this.
> >> >
> >> > In 5.16 instead of this message there is a bunch of hex lines prefixed
> >> > with BAD.
> >> >
> >> > It is still broken in 6.1 at the very least.
> >> >
> >> > I donno if this is related to this part, but I wanted to try a newer
> >> > kernel, because the RPI4 seems to do all the video decoding in
> >> > software and cannot seem to handle it.
> >> >
> >> >
> >> > logs:
> >> > vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> >> > vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> >> > vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> > vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> > vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> > vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> > vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> > checking generic (3ea81000 12c000) vs hw (0 ffffffffffffffff)
> >> > fb0: switching to vc4 from simple
> >> > Console: switching to colour dummy device 80x25
> >> > [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> >> > vc4-drm gpu: [drm] Cannot find any crtc or sizes
> >>
> >> 5.16 log has:
> >>
> >> vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
> >> vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
> >> vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
> >> [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> >>         [00] BAD  00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
> >>         [00] BAD  0b 1f 01 03 00 23 01 78 0a cf 74 a3 57 4c b0 23
> >>         [00] BAD  09 48 4c 00 00 00 01 01 01 ff 01 ff ff 01 01 01
> >>         [00] BAD  01 01 01 01 01 20 08 e8 00 30 f2 70 5a 80 b0 58
> >>         [00] BAD  8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
> >>         [00] BAD  58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
> >>         [00] BAD  41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
> >>         [00] BAD  00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 01 aa
> >> Console: switching to colour frame buffer device 240x67
> >> vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> >>
> >>
> >> i donno what this bad is, but it doesn't happen in 5.17... maybe these
> >> BAD got filtered out, but they did end up working for me? or
> >> something?
> >> i donno...
> >
> > Run it through edid-decode - the checksum is wrong.
> >
> > Block 0, Base EDID:
> >   EDID Structure Version & Revision: 1.3
> >   Vendor & Product Identification:
> >     Manufacturer: MST
> >     Model: 0
> >     Made in: week 11 of 2021
> >   Basic Display Parameters & Features:
> >     Analog display
> >     Input voltage level: 0.7/0.3 V
> >     Blank level equals black level
> >     Maximum image size: 35 cm x 1 cm
> >     Gamma: 2.20
> >     RGB color display
> >     First detailed timing is the preferred timing
> >   Color Characteristics:
> >     Red  : 0.6396, 0.3398
> >     Green: 0.2998, 0.6904
> >     Blue : 0.1376, 0.0380
> >     White: 0.2822, 0.2968
> >   Established Timings I & II: none
> >   Standard Timings:
> >     GTF     :  2288x1432   61.000 Hz  16:10   90.463 kHz 282.245 MHz
> >   Detailed Timing Descriptors:
> >     DTD 1:  3840x2160   60.000 Hz  16:9   135.000 kHz 594.000 MHz (708
> > mm x 398 mm)
> >                  Hfront  176 Hsync  88 Hback 296 Hpol P
> >                  Vfront    8 Vsync  10 Vback  72 Vpol P
> >     DTD 2:  1920x1080   60.000 Hz  16:9    67.500 kHz 148.500 MHz (708
> > mm x 398 mm)
> >                  Hfront   88 Hsync  44 Hback 148 Hpol P
> >                  Vfront    4 Vsync   5 Vback  36 Vpol P
> >     Display Product Name: 'SALORA'
> >   Display Range Limits:
> >     Monitor ranges (GTF): 59-70 Hz V, 31-140 kHz H, max dotclock 600
> > MHz
> >   Extension blocks: 1
> > Checksum: 0xaa (should be 0xeb)
> >
> > Weird that it also says that it's an analog display when it's
> > connected over HDMI. Something rather bizarre there, and I think it'll
> > hit problems in drm_edid at [1] as we end up with a connector having
> > no color_formats defined. I was discussing this with Maxime only last
> > week, but in relation to VGA monitors connected through HDMI to VGA
> > adapters without rewriting the EDID.
> >
> >
> > If you have an issue between 5.16 and 5.17, then I'd guess at [2] and
> > your monitor not asserting hotplug correctly. The raw hotplug status
> > is reported in /sys/kernel/debug/dri/N/hdmi0_regs (N will be either 0
> > or 1 depending on the probe order of the vc4 and v3d drivers). Grep
> > for HDMI_HOTPLUG.
> >
> > Incorrect hotplug behaviour causes grief when combined with HDMI2.0
> > and scrambling. If you don' t know the other end has been
> > disconnected, then you never know that scrambling needs to be
> > re-negotiated over SCDC, and the display will typically end up just
> > being blank.
> >
> > [1]
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_edid.c#L6460
> > [2]
> > https://github.com/torvalds/linux/commit/cc5f1cbbc1e12ad5b11d594159fe793eb03c70fa
>
> So, i looked at these hdmi0_regs (and hdmi1_regs) and that seemed empty
> in 5.16 ? i did a cat on them, but nothing came out... (5.16 doesn't
> have v3d, so there was only one dri)

So what did a more recent kernel report? Your display isn't going to
change hotplug behaviour just because you changed kernel version.

The fact that it works with "video=HDMI-A-2:D" on the kernel command
line implies that it is incorrect hotplug behaviour in your monitor.
There's very little that can be done in software to fix that.

  Dave

> >> I also noticed that earlier in the logs there are more bound lines:
> >> (some are double)
> >>
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >>
> >> and then here for some reason systemd does modprobe at drm.service ? is
> >> this just a delayed starting log line, or does it actually try to
> >> unload
> >> drm and reload? i doubt it?
> >> in any case there is more that appears before:
> >>
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
> >> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> >> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
> >>
> >>
> >> so, the error message is weird, as it implies 2 possibilities.
> >> however,
> >> i think it did find a crtc since all those pixelvalve things use crtc
> >> functions?
> >>
> >> So then why do i have this problem on my RPI4? do most people just use
> >> the raspberry pi kernels?
> >
> > Largely, yes, people use our vendor kernels.
> >
> > Stefan Wahren has been co-ordinating Pi4 support in mainline. I
> > believe [3] is tracking the current state.
> > Maxime has been working on the vc4 driver, and it should be functional
> > on most hardware. It looks like yours is not complying with the
> > standards.
> >
> >   Dave
> >
> > [3] https://github.com/lategoodbye/rpi-zero/issues/43
> [snip]
>
> Yeah, lategoodbye pointed me here