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

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

[AL13N]

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

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

[AL13N]

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...


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@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?

I looked at what was changed in crtc between 5.16 and 5.17, but not 
much:

2022-02-17	drm/vc4: crtc: Fix runtime_pm reference counting	Maxime 
Ripard	1	-3/+5
2022-02-07	drm/vc4: crtc: Fix redundant variable assignment	Maxime 
Ripard	1	-1/+0
2021-11-05	drm/vc4: crtc: Copy assigned channel to the CRTC	Maxime 
Ripard	1	-2/+2
2021-11-05	drm/vc4: Fix non-blocking commit getting stuck forever	Maxime 
Ripard	1	-1/+4
2021-11-05	drm/vc4: crtc: Drop feed_txp from state	Maxime Ripard	1	-2/+1
2021-11-04	drm/vc4: Increase the core clock based on HVS load	Maxime 
Ripard	1	-0/+15
2021-11-04	drm/vc4: crtc: Add some logging	Maxime Ripard	1	-0/+6
2021-11-04	drm/vc4: crtc: Rework the encoder retrieval code 
(again)	Maxime Ripard	1	-21/+9
2021-11-04	drm/vc4: crtc: Add encoder to vc4_crtc_config_pv 
prototype	Maxime Ripard	1	-4/+3
2021-11-04	drm/vc4: Make vc4_crtc_get_encoder public	Maxime 
Ripard	1	-4/+4
2021-10-25	drm/vc4: crtc: Make sure the HDMI controller is powered when 
disabling	Maxime Ripard	1	-1/+18


I looked at them, but in my layman's knowledge, none of those really 
seemed to have any impact?

So, maybe the problem is someplace else?

Can anyone help to find out where this problem might be? even though 
this is old code, i still have this issue at least on 6.1 ?

Regards,

Maarten

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

[Dave Stevenson]

Hi Maarten

On Tue, 7 Mar 2023 at 16:25, AL13N <alien@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

> 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@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

> I looked at what was changed in crtc between 5.16 and 5.17, but not
> much:
>
> 2022-02-17      drm/vc4: crtc: Fix runtime_pm reference counting        Maxime
> Ripard  1       -3/+5
> 2022-02-07      drm/vc4: crtc: Fix redundant variable assignment        Maxime
> Ripard  1       -1/+0
> 2021-11-05      drm/vc4: crtc: Copy assigned channel to the CRTC        Maxime
> Ripard  1       -2/+2
> 2021-11-05      drm/vc4: Fix non-blocking commit getting stuck forever  Maxime
> Ripard  1       -1/+4
> 2021-11-05      drm/vc4: crtc: Drop feed_txp from state Maxime Ripard   1       -2/+1
> 2021-11-04      drm/vc4: Increase the core clock based on HVS load      Maxime
> Ripard  1       -0/+15
> 2021-11-04      drm/vc4: crtc: Add some logging Maxime Ripard   1       -0/+6
> 2021-11-04      drm/vc4: crtc: Rework the encoder retrieval code
> (again) Maxime Ripard   1       -21/+9
> 2021-11-04      drm/vc4: crtc: Add encoder to vc4_crtc_config_pv
> prototype       Maxime Ripard   1       -4/+3
> 2021-11-04      drm/vc4: Make vc4_crtc_get_encoder public       Maxime
> Ripard  1       -4/+4
> 2021-10-25      drm/vc4: crtc: Make sure the HDMI controller is powered when
> disabling       Maxime Ripard   1       -1/+18
>
>
> I looked at them, but in my layman's knowledge, none of those really
> seemed to have any impact?
>
> So, maybe the problem is someplace else?
>
> Can anyone help to find out where this problem might be? even though
> this is old code, i still have this issue at least on 6.1 ?
>
> Regards,
>
> Maarten

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

[Maxime Ripard]

Hi,

On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
> > AL13N schreef op 2023-03-06 17:34:
> > > 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.

If it's an option, bisecting between 5.16 and 5.17 which commit
introduced the regression would be nice.

> 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

We can easily test that: could you try booting with video=HDMI-A-1:D (or
HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
helps?

> > 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@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.

tbf, the downstream kernel has pretty much the same code here, so the
issue is very likely to affect it too.

I would just assume that your TV has some unusual behaviour that throws
the driver off, and most people won't.

Maxime

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

[AL13N]

Maxime Ripard schreef op 2023-03-08 13:35:
> Hi,
> 
> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>> > AL13N schreef op 2023-03-06 17:34:
>> > > 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.
> 
> If it's an option, bisecting between 5.16 and 5.17 which commit
> introduced the regression would be nice.
> 
>> 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
> 
> We can easily test that: could you try booting with video=HDMI-A-1:D 
> (or
> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
> helps?

in kernel 6.1 or kernel 5.17 ?

>> > 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@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.
> 
> tbf, the downstream kernel has pretty much the same code here, so the
> issue is very likely to affect it too.
> 
> I would just assume that your TV has some unusual behaviour that throws
> the driver off, and most people won't.

IC, the TV also has an option somewhere to choose EDID 2.0, i thought i 
chose that but if that decode says 1.3, maybe i didn't... Is it worth it 
to retry this?

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

[AL13N]

AL13N schreef op 2023-03-08 22:16:
> Maxime Ripard schreef op 2023-03-08 13:35:
>> Hi,
>> 
>> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>>> > AL13N schreef op 2023-03-06 17:34:
>>> > > 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.
>> 
>> If it's an option, bisecting between 5.16 and 5.17 which commit
>> introduced the regression would be nice.
>> 
>>> 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
>> 
>> We can easily test that: could you try booting with video=HDMI-A-1:D 
>> (or
>> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>> helps?
> 
> in kernel 6.1 or kernel 5.17 ?

in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the 
hdmi farthest from the power)

and I did see BAD stuff here too:


[drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
Registered IR keymap rc-cec
rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[drm] forcing HDMI-A-2 connector on
Registered IR keymap rc-cec
rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
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 1
EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
        [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
vc4-drm gpu: [drm] Cannot find any crtc or sizes
EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
vc4-drm gpu: [drm] Cannot find any crtc or sizes


a bit puzzling why it does EDID block twice and it's twice checksum 
invalid?
I also see forcing connector on.

earlier, i did try to make an edid file from a modeline that worked on 
5.16 and pass it using drm_kms_helper.edid_firmware= ; but that didn't 
work, there only was some kind of warning that i should use something 
else...

reading through all your messages, does this mean, that i should be able 
to boot if we were to "fix" this edid file? and pass it? or is this 
something that needs change in kernel?

> 
>>> > 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@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.
>> 
>> tbf, the downstream kernel has pretty much the same code here, so the
>> issue is very likely to affect it too.
>> 
>> I would just assume that your TV has some unusual behaviour that 
>> throws
>> the driver off, and most people won't.
> 
> IC, the TV also has an option somewhere to choose EDID 2.0, i thought
> i chose that but if that decode says 1.3, maybe i didn't... Is it
> worth it to retry this?

actually, the TV was set to EDID 2.0 the other option was 1.4 (?)

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

[AL13N]

Dave Stevenson schreef op 2023-03-07 18:10:
> Hi Maarten
> 
> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@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)


>> 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@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

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

[Dave Stevenson]

On Thu, 9 Mar 2023 at 11:26, AL13N <alien@rmail.be> wrote:
>
> Dave Stevenson schreef op 2023-03-07 18:10:
> > Hi Maarten
> >
> > On Tue, 7 Mar 2023 at 16:25, AL13N <alien@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@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

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

[Dave Stevenson]

On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>
> AL13N schreef op 2023-03-08 22:16:
> > Maxime Ripard schreef op 2023-03-08 13:35:
> >> Hi,
> >>
> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
> >>> > AL13N schreef op 2023-03-06 17:34:
> >>> > > 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.
> >>
> >> If it's an option, bisecting between 5.16 and 5.17 which commit
> >> introduced the regression would be nice.
> >>
> >>> 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
> >>
> >> We can easily test that: could you try booting with video=HDMI-A-1:D
> >> (or
> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
> >> helps?
> >
> > in kernel 6.1 or kernel 5.17 ?
>
> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
> hdmi farthest from the power)
>
> and I did see BAD stuff here too:
>
>
> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> Registered IR keymap rc-cec
> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
> [drm] forcing HDMI-A-2 connector on
> Registered IR keymap rc-cec
> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
> 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 1
> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>         [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
> vc4-drm gpu: [drm] Cannot find any crtc or sizes
> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>
>
> a bit puzzling why it does EDID block twice and it's twice checksum
> invalid?
> I also see forcing connector on.
>
> earlier, i did try to make an edid file from a modeline that worked on
> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that didn't
> work, there only was some kind of warning that i should use something
> else...

It always helps to actually quote warnings or errors.
Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
use drm.edid_firmware instead.", in which case do as it tells you and
use "drm.edid_firmware=<filename>".

> reading through all your messages, does this mean, that i should be able
> to boot if we were to "fix" this edid file? and pass it? or is this
> something that needs change in kernel?

At present you have 2 issues
- the monitor or cable doesn't handle the hotplug line correctly
- the monitor doesn't provide a valid EDID.

The first you can workaround with "video=HDMI-A-2:D".

The second you can work around by capturing the EDID, fixing it, and
then using "drm.edid_firmware=<filename>".
The first fix is to just fixup the checksum (edid-decode even tells
you the correct value as 0xEB). That doesn't solve the fact that the
EDID contains other rubbish like being an analog display which may
cause further issues. The simplest fix for reporting as an analog
display is to change byte 20 from 0x00 to 0x80, and then correct the
checksum again.

The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
In order to support 4k60 it needs to support HDMI2.0 and enabling
scrambling via SCDC. That should also be signalled in the EDID Sink
Capability Data Structure block but isn't, so 4k60 support may be
compromised.

Sorry, all of this comes back to the monitor vendor shipping rubbish.
None of this is the fault of the vc4 driver, and it only worked under
5.16 by chance.

> >
> >>> > 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@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.
> >>
> >> tbf, the downstream kernel has pretty much the same code here, so the
> >> issue is very likely to affect it too.
> >>
> >> I would just assume that your TV has some unusual behaviour that
> >> throws
> >> the driver off, and most people won't.
> >
> > IC, the TV also has an option somewhere to choose EDID 2.0, i thought
> > i chose that but if that decode says 1.3, maybe i didn't... Is it
> > worth it to retry this?
>
> actually, the TV was set to EDID 2.0 the other option was 1.4 (?)

I would guess that the HDMI 1.4 setting drops the 4k60 mode as HDMI1.4
maxes out at 4k30. It's impossible for us to say if it fixes any of
the other issues with the EDID.

  Dave

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

[AL13N]

Dave Stevenson schreef op 2023-03-09 13:59:
> On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>> 
>> AL13N schreef op 2023-03-08 22:16:
>> > Maxime Ripard schreef op 2023-03-08 13:35:
>> >> Hi,
>> >>
>> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>> >>> > AL13N schreef op 2023-03-06 17:34:
>> >>> > > 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.
>> >>
>> >> If it's an option, bisecting between 5.16 and 5.17 which commit
>> >> introduced the regression would be nice.
>> >>
>> >>> 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
>> >>
>> >> We can easily test that: could you try booting with video=HDMI-A-1:D
>> >> (or
>> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>> >> helps?
>> >
>> > in kernel 6.1 or kernel 5.17 ?
>> 
>> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
>> hdmi farthest from the power)
>> 
>> and I did see BAD stuff here too:
>> 
>> 
>> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
>> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>> Registered IR keymap rc-cec
>> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
>> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
>> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
>> [drm] forcing HDMI-A-2 connector on
>> Registered IR keymap rc-cec
>> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
>> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
>> 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 1
>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>>         [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
>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>> 
>> 
>> a bit puzzling why it does EDID block twice and it's twice checksum
>> invalid?
>> I also see forcing connector on.
>> 
>> earlier, i did try to make an edid file from a modeline that worked on
>> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that didn't
>> work, there only was some kind of warning that i should use something
>> else...
> 
> It always helps to actually quote warnings or errors.
> Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
> use drm.edid_firmware instead.", in which case do as it tells you and
> use "drm.edid_firmware=<filename>".

oh, i interpreted this as "it works for now, but will be removed later" 
? are you saying it really doesn't work and i should retest with 
"drm.edid_firmware=" ?

>> reading through all your messages, does this mean, that i should be 
>> able
>> to boot if we were to "fix" this edid file? and pass it? or is this
>> something that needs change in kernel?
> 
> At present you have 2 issues
> - the monitor or cable doesn't handle the hotplug line correctly
> - the monitor doesn't provide a valid EDID.
> 
> The first you can workaround with "video=HDMI-A-2:D".

I thought the video= had to be turned off for drm.edid_firmware= to work 
well?
rpi4 config.txt has a disable_fw_kms_setup=1 that disables the video 
tags that are auto-added to cmdline (this option is commented atm)
there is also a hdmi_force_hotplug=1 option that is turned on atm

> The second you can work around by capturing the EDID, fixing it, and
> then using "drm.edid_firmware=<filename>".
> The first fix is to just fixup the checksum (edid-decode even tells
> you the correct value as 0xEB). That doesn't solve the fact that the
> EDID contains other rubbish like being an analog display which may
> cause further issues. The simplest fix for reporting as an analog
> display is to change byte 20 from 0x00 to 0x80, and then correct the
> checksum again.
> 
> The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
> In order to support 4k60 it needs to support HDMI2.0 and enabling
> scrambling via SCDC. That should also be signalled in the EDID Sink
> Capability Data Structure block but isn't, so 4k60 support may be
> compromised.

the rpi4 also has in config.txt a hdmi_enable_4kp60=1, which i have not 
turned on atm; i don't know if that has any impact here...

> Sorry, all of this comes back to the monitor vendor shipping rubbish.
> None of this is the fault of the vc4 driver, and it only worked under
> 5.16 by chance.

do the config.txt directives on the rpi4 have any impact here? I always 
figured these options only changed the cmdline video= parameters, it 
can't really have any impact to the edid, no?

also, i assume there's lots of monitors/TVs that have rubbish EDID 
files, how is this generally handled: are you guys trying to cater to 
these weird EDID's or is it like: "nope, bad EDID, they should fix it, 
no screen for now"?

>> >
>> >>> > 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@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.
>> >>
>> >> tbf, the downstream kernel has pretty much the same code here, so the
>> >> issue is very likely to affect it too.
>> >>
>> >> I would just assume that your TV has some unusual behaviour that
>> >> throws
>> >> the driver off, and most people won't.
>> >
>> > IC, the TV also has an option somewhere to choose EDID 2.0, i thought
>> > i chose that but if that decode says 1.3, maybe i didn't... Is it
>> > worth it to retry this?
>> 
>> actually, the TV was set to EDID 2.0 the other option was 1.4 (?)
> 
> I would guess that the HDMI 1.4 setting drops the 4k60 mode as HDMI1.4
> maxes out at 4k30. It's impossible for us to say if it fixes any of
> the other issues with the EDID.

So, the edid needs to be changed to:
  - not be analog
  - set to 2.0
  - add scrambling capability on SCDC
  - fix checksum

I'm wondering if the config.txt actually changes these values without 
fixing checksum and that is the cause? but that seems very unlikely...

thanks a lot for the responses, maybe I should just try to fix the EDID 
and then just supply it to the company in question, I was in contact 
with them asking for the EDID file earlier (to see if they have an 
updated file someplace).

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

[AL13N]

AL13N schreef op 2023-03-10 10:10:
> Dave Stevenson schreef op 2023-03-09 13:59:
>> On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>>> 
>>> AL13N schreef op 2023-03-08 22:16:
>>> > Maxime Ripard schreef op 2023-03-08 13:35:
>>> >> Hi,
>>> >>
>>> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>>> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>>> >>> > AL13N schreef op 2023-03-06 17:34:
>>> >>> > > 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)

after looking at this in a bit more detail;

i was puzzled by the extension blocks, because in the data, the 0xaa is 
the very next byte, maybe this 0xaa is the first byte of this extension 
block and the binary output here assumes no extension block? or the 
extension blocks could be after the checksum, i donno...

Also, there seem to be 4 descriptors, but DTD 3 and 4 are not shown 
here? maybe something bad is there too, and is ignored, but there seems 
to be partial data there.

It would be great to capture the original edid data, but i just get 
nothing when i cat the specific /sys stuff, i also tried these read edid 
programs, but nothing...

>>> >>> 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.
>>> >>
>>> >> If it's an option, bisecting between 5.16 and 5.17 which commit
>>> >> introduced the regression would be nice.
>>> >>
>>> >>> 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
>>> >>
>>> >> We can easily test that: could you try booting with video=HDMI-A-1:D
>>> >> (or
>>> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>>> >> helps?
>>> >
>>> > in kernel 6.1 or kernel 5.17 ?
>>> 
>>> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
>>> hdmi farthest from the power)
>>> 
>>> and I did see BAD stuff here too:
>>> 
>>> 
>>> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
>>> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>>> Registered IR keymap rc-cec
>>> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
>>> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
>>> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
>>> [drm] forcing HDMI-A-2 connector on
>>> Registered IR keymap rc-cec
>>> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
>>> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
>>> 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 1
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>>>         [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
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> 
>>> 
>>> a bit puzzling why it does EDID block twice and it's twice checksum
>>> invalid?
>>> I also see forcing connector on.
>>> 
>>> earlier, i did try to make an edid file from a modeline that worked 
>>> on
>>> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that 
>>> didn't
>>> work, there only was some kind of warning that i should use something
>>> else...
>> 
>> It always helps to actually quote warnings or errors.
>> Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
>> use drm.edid_firmware instead.", in which case do as it tells you and
>> use "drm.edid_firmware=<filename>".
> 
> oh, i interpreted this as "it works for now, but will be removed
> later" ? are you saying it really doesn't work and i should retest
> with "drm.edid_firmware=" ?
> 
>>> reading through all your messages, does this mean, that i should be 
>>> able
>>> to boot if we were to "fix" this edid file? and pass it? or is this
>>> something that needs change in kernel?
>> 
>> At present you have 2 issues
>> - the monitor or cable doesn't handle the hotplug line correctly
>> - the monitor doesn't provide a valid EDID.
>> 
>> The first you can workaround with "video=HDMI-A-2:D".

Well, i should be clear to say that i did have no video at all with or 
without the video= option, i guess i just got further and/or have more 
debug, not sure that still fixed it?

> I thought the video= had to be turned off for drm.edid_firmware= to 
> work well?
> rpi4 config.txt has a disable_fw_kms_setup=1 that disables the video
> tags that are auto-added to cmdline (this option is commented atm)
> there is also a hdmi_force_hotplug=1 option that is turned on atm
> 
>> The second you can work around by capturing the EDID, fixing it, and
>> then using "drm.edid_firmware=<filename>".
>> The first fix is to just fixup the checksum (edid-decode even tells
>> you the correct value as 0xEB). That doesn't solve the fact that the
>> EDID contains other rubbish like being an analog display which may
>> cause further issues. The simplest fix for reporting as an analog
>> display is to change byte 20 from 0x00 to 0x80, and then correct the
>> checksum again.
>> 
>> The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
>> In order to support 4k60 it needs to support HDMI2.0 and enabling
>> scrambling via SCDC. That should also be signalled in the EDID Sink
>> Capability Data Structure block but isn't, so 4k60 support may be
>> compromised.
> 
> the rpi4 also has in config.txt a hdmi_enable_4kp60=1, which i have
> not turned on atm; i don't know if that has any impact here...
> 
>> Sorry, all of this comes back to the monitor vendor shipping rubbish.
>> None of this is the fault of the vc4 driver, and it only worked under
>> 5.16 by chance.
> 
> do the config.txt directives on the rpi4 have any impact here? I
> always figured these options only changed the cmdline video=
> parameters, it can't really have any impact to the edid, no?
> 
> also, i assume there's lots of monitors/TVs that have rubbish EDID
> files, how is this generally handled: are you guys trying to cater to
> these weird EDID's or is it like: "nope, bad EDID, they should fix it,
> no screen for now"?
> 
>>> >
>>> >>> > 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@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.
>>> >>
>>> >> tbf, the downstream kernel has pretty much the same code here, so the
>>> >> issue is very likely to affect it too.
>>> >>
>>> >> I would just assume that your TV has some unusual behaviour that
>>> >> throws
>>> >> the driver off, and most people won't.
>>> >
>>> > IC, the TV also has an option somewhere to choose EDID 2.0, i thought
>>> > i chose that but if that decode says 1.3, maybe i didn't... Is it
>>> > worth it to retry this?
>>> 
>>> actually, the TV was set to EDID 2.0 the other option was 1.4 (?)
>> 
>> I would guess that the HDMI 1.4 setting drops the 4k60 mode as HDMI1.4
>> maxes out at 4k30. It's impossible for us to say if it fixes any of
>> the other issues with the EDID.
> 
> So, the edid needs to be changed to:
>  - not be analog
>  - set to 2.0
>  - add scrambling capability on SCDC
>  - fix checksum
> 
> I'm wondering if the config.txt actually changes these values without
> fixing checksum and that is the cause? but that seems very unlikely...
> 
> thanks a lot for the responses, maybe I should just try to fix the
> EDID and then just supply it to the company in question, I was in
> contact with them asking for the EDID file earlier (to see if they
> have an updated file someplace).

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

[AL13N]

Dave Stevenson schreef op 2023-03-09 13:59:
> On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>> 
>> AL13N schreef op 2023-03-08 22:16:
>> > Maxime Ripard schreef op 2023-03-08 13:35:
>> >> Hi,
>> >>
>> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>> >>> > AL13N schreef op 2023-03-06 17:34:
>> >>> > > 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.
>> >>
>> >> If it's an option, bisecting between 5.16 and 5.17 which commit
>> >> introduced the regression would be nice.
>> >>
>> >>> 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
>> >>
>> >> We can easily test that: could you try booting with video=HDMI-A-1:D
>> >> (or
>> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>> >> helps?
>> >
>> > in kernel 6.1 or kernel 5.17 ?
>> 
>> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
>> hdmi farthest from the power)
>> 
>> and I did see BAD stuff here too:
>> 
>> 
>> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
>> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>> Registered IR keymap rc-cec
>> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
>> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
>> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
>> [drm] forcing HDMI-A-2 connector on
>> Registered IR keymap rc-cec
>> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
>> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
>> 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 1
>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>>         [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
>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>> 
>> 
>> a bit puzzling why it does EDID block twice and it's twice checksum
>> invalid?
>> I also see forcing connector on.
>> 
>> earlier, i did try to make an edid file from a modeline that worked on
>> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that didn't
>> work, there only was some kind of warning that i should use something
>> else...
> 
> It always helps to actually quote warnings or errors.
> Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
> use drm.edid_firmware instead.", in which case do as it tells you and
> use "drm.edid_firmware=<filename>".
> 
>> reading through all your messages, does this mean, that i should be 
>> able
>> to boot if we were to "fix" this edid file? and pass it? or is this
>> something that needs change in kernel?
> 
> At present you have 2 issues
> - the monitor or cable doesn't handle the hotplug line correctly
> - the monitor doesn't provide a valid EDID.
> 
> The first you can workaround with "video=HDMI-A-2:D".

ok i retried 6.1 (with edid) and without hdmi_hotplug_force=1 and no 
rainbow, so i guess that is the reason why this video= parameter is 
needed, after all

> The second you can work around by capturing the EDID, fixing it, and
> then using "drm.edid_firmware=<filename>".
> The first fix is to just fixup the checksum (edid-decode even tells
> you the correct value as 0xEB). That doesn't solve the fact that the
> EDID contains other rubbish like being an analog display which may
> cause further issues. The simplest fix for reporting as an analog
> display is to change byte 20 from 0x00 to 0x80, and then correct the
> checksum again.
> 
> The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
> In order to support 4k60 it needs to support HDMI2.0 and enabling
> scrambling via SCDC. That should also be signalled in the EDID Sink
> Capability Data Structure block but isn't, so 4k60 support may be
> compromised.
> 
> Sorry, all of this comes back to the monitor vendor shipping rubbish.
> None of this is the fault of the vc4 driver, and it only worked under
> 5.16 by chance.

Ok, so i changed the EDID based on what you said, but me knowing 
nothing:
(since i didn't have the extension data, i removed the extension)...

00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
0b 1f 01 03 80 23 01 78 0a cf 74 a3 57 4c b0 23
09 48 4c 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 00 85

i did this with:
hdmi_enable_4kp60=1
disable_fw_kms_setup=1
hdmi_force_hotplug=1
disable_overscan=1
display_auto_detect=1
arm_boost=1
otg_mode=1
max_framebuffers=2
arm_64bit=1

commandline args:
Kernel command line: coherent_pool=1M 8250.nr_uarts=0 
snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  
smsc95xx.macaddr=01:23:34:56:78:9A vc_mem.mem_base=0x3ec00000 
vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 rw 
ip=eth0:dhcp nameserver=10.A.B.1 
root=10.A.B.12:/data/nfs/aarch64/rpi4-mediabox-latest:nfsvers=3 
drm.edid_firmware=edid/salora-edid-fix.bin video=HDMI-A-1:D 
radeon.runpm=0 splash=silent quiet rootwait 
plymouth.ignore-serial-consoles
Unknown kernel command line parameters "nameserver=10.A.B.1 
splash=silent", will be passed to user space.

and I have 1080p@60Hz, this is the drm output:

[drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[drm] forcing HDMI-A-1 connector on
Registered IR keymap rc-cec
rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
Registered IR keymap rc-cec
rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
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 1
[drm] Got external EDID base block and 0 extensions from 
"edid/salora-edid-fix.bin" for connector "HDMI-A-1"
vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough 
to support 4k @ 60Hz.
vc4-drm gpu: [drm] Please change your config.txt file to add 
hdmi_enable_4kp60.
Console: switching to colour frame buffer device 240x67
vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[drm] Got external EDID base block and 0 extensions from 
"edid/salora-edid-fix.bin" for connector "HDMI-A-1"
[drm] Got external EDID base block and 0 extensions from 
"edid/salora-edid-fix.bin" for connector "HDMI-A-1"
[drm] Got external EDID base block and 0 extensions from 
"edid/salora-edid-fix.bin" for connector "HDMI-A-1"
[drm] Got external EDID base block and 0 extensions from 
"edid/salora-edid-fix.bin" for connector "HDMI-A-1"

weird that it asks to add the 4kp60, while i had added that? and the 
edid also contains that?

do i need to change the edid file further to get 4kp60 ?

[snip]

Thanks in advance,

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

[Dave Stevenson]

On Fri, 10 Mar 2023 at 09:10, AL13N <alien@rmail.be> wrote:
>
> Dave Stevenson schreef op 2023-03-09 13:59:
> > On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
> >>
> >> AL13N schreef op 2023-03-08 22:16:
> >> > Maxime Ripard schreef op 2023-03-08 13:35:
> >> >> Hi,
> >> >>
> >> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
> >> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
> >> >>> > AL13N schreef op 2023-03-06 17:34:
> >> >>> > > 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.
> >> >>> > >
<snip>
> >>
> >> a bit puzzling why it does EDID block twice and it's twice checksum
> >> invalid?
> >> I also see forcing connector on.
> >>
> >> earlier, i did try to make an edid file from a modeline that worked on
> >> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that didn't
> >> work, there only was some kind of warning that i should use something
> >> else...
> >
> > It always helps to actually quote warnings or errors.
> > Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
> > use drm.edid_firmware instead.", in which case do as it tells you and
> > use "drm.edid_firmware=<filename>".
>
> oh, i interpreted this as "it works for now, but will be removed later"
> ? are you saying it really doesn't work and i should retest with
> "drm.edid_firmware=" ?

Reporting that you got a warning or error message which you then
ignored doesn't help the debug process.
Seeing it's been deprecated since 5.4 in 2017, it would be a fair
candidate to disappear.

> >> reading through all your messages, does this mean, that i should be
> >> able
> >> to boot if we were to "fix" this edid file? and pass it? or is this
> >> something that needs change in kernel?
> >
> > At present you have 2 issues
> > - the monitor or cable doesn't handle the hotplug line correctly
> > - the monitor doesn't provide a valid EDID.
> >
> > The first you can workaround with "video=HDMI-A-2:D".
>
> I thought the video= had to be turned off for drm.edid_firmware= to work
> well?

No - they do 2 different jobs.
video=HDMI-A-2:D will force the connector to report connected, and
therefore trigger a read of the EDID.
drm.edid_firmware means that the EDID used will be read from that file
rather than over the DDC link.

> rpi4 config.txt has a disable_fw_kms_setup=1 that disables the video
> tags that are auto-added to cmdline (this option is commented atm)
> there is also a hdmi_force_hotplug=1 option that is turned on atm

hdmi_force_hotplug=1 only affects the firmware, not the vc4 kernel driver.

> > The second you can work around by capturing the EDID, fixing it, and
> > then using "drm.edid_firmware=<filename>".
> > The first fix is to just fixup the checksum (edid-decode even tells
> > you the correct value as 0xEB). That doesn't solve the fact that the
> > EDID contains other rubbish like being an analog display which may
> > cause further issues. The simplest fix for reporting as an analog
> > display is to change byte 20 from 0x00 to 0x80, and then correct the
> > checksum again.
> >
> > The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
> > In order to support 4k60 it needs to support HDMI2.0 and enabling
> > scrambling via SCDC. That should also be signalled in the EDID Sink
> > Capability Data Structure block but isn't, so 4k60 support may be
> > compromised.
>
> the rpi4 also has in config.txt a hdmi_enable_4kp60=1, which i have not
> turned on atm; i don't know if that has any impact here...

Without that then any mode that requires a pixel clock above the
340MHz limit of HDMI 1.4 will be filtered out. 4k60 will therefore not
be available to you on your system.

> > Sorry, all of this comes back to the monitor vendor shipping rubbish.
> > None of this is the fault of the vc4 driver, and it only worked under
> > 5.16 by chance.
>
> do the config.txt directives on the rpi4 have any impact here? I always
> figured these options only changed the cmdline video= parameters, it
> can't really have any impact to the edid, no?

Most of them only affect the firmware. The firmware does try to pass
some information across to the kernel to set some defaults, but it
can't do everything.

> also, i assume there's lots of monitors/TVs that have rubbish EDID
> files, how is this generally handled: are you guys trying to cater to
> these weird EDID's or is it like: "nope, bad EDID, they should fix it,
> no screen for now"?

Actually reputable display manufacturers do a very good job on
providing good EDIDs. There is very little excuse to ship a product
with an invalid checksum in the EDID.

Behaviour depends how bad the EDID is, and note that bad hotplug
behaviour is a separate issue to the bad EDID.
vc4 is now using the same EDID parsing code as the majority of the DRM
drivers. Your EDID is bad enough that I suspect it will cause grief on
many Linux systems, not just vc4 (I was going to test that, but my
test rig appears to be playing up at present).

DRM relies on the EDID being reasonable. There may be some corner
cases that cause some grief (declaring a display as being analog for
one), but actually they seem to be relatively rare.

> >> >
> >> >>> > 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@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.
> >> >>
> >> >> tbf, the downstream kernel has pretty much the same code here, so the
> >> >> issue is very likely to affect it too.
> >> >>
> >> >> I would just assume that your TV has some unusual behaviour that
> >> >> throws
> >> >> the driver off, and most people won't.
> >> >
> >> > IC, the TV also has an option somewhere to choose EDID 2.0, i thought
> >> > i chose that but if that decode says 1.3, maybe i didn't... Is it
> >> > worth it to retry this?
> >>
> >> actually, the TV was set to EDID 2.0 the other option was 1.4 (?)
> >
> > I would guess that the HDMI 1.4 setting drops the 4k60 mode as HDMI1.4
> > maxes out at 4k30. It's impossible for us to say if it fixes any of
> > the other issues with the EDID.
>
> So, the edid needs to be changed to:
>   - not be analog
>   - set to 2.0
>   - add scrambling capability on SCDC
>   - fix checksum
>
> I'm wondering if the config.txt actually changes these values without
> fixing checksum and that is the cause? but that seems very unlikely...
>
> thanks a lot for the responses, maybe I should just try to fix the EDID
> and then just supply it to the company in question, I was in contact
> with them asking for the EDID file earlier (to see if they have an
> updated file someplace).

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

[AL13N]

AL13N schreef op 2023-03-10 13:38:
> Dave Stevenson schreef op 2023-03-09 13:59:
>> On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>>> 
>>> AL13N schreef op 2023-03-08 22:16:
>>> > Maxime Ripard schreef op 2023-03-08 13:35:
>>> >> Hi,
>>> >>
>>> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>>> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>>> >>> > AL13N schreef op 2023-03-06 17:34:
>>> >>> > > 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.
>>> >>
>>> >> If it's an option, bisecting between 5.16 and 5.17 which commit
>>> >> introduced the regression would be nice.
>>> >>
>>> >>> 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
>>> >>
>>> >> We can easily test that: could you try booting with video=HDMI-A-1:D
>>> >> (or
>>> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>>> >> helps?
>>> >
>>> > in kernel 6.1 or kernel 5.17 ?
>>> 
>>> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
>>> hdmi farthest from the power)
>>> 
>>> and I did see BAD stuff here too:
>>> 
>>> 
>>> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
>>> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>>> Registered IR keymap rc-cec
>>> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
>>> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
>>> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
>>> [drm] forcing HDMI-A-2 connector on
>>> Registered IR keymap rc-cec
>>> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
>>> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
>>> 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 1
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>>>         [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
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> 
>>> 
>>> a bit puzzling why it does EDID block twice and it's twice checksum
>>> invalid?
>>> I also see forcing connector on.
>>> 
>>> earlier, i did try to make an edid file from a modeline that worked 
>>> on
>>> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that 
>>> didn't
>>> work, there only was some kind of warning that i should use something
>>> else...
>> 
>> It always helps to actually quote warnings or errors.
>> Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
>> use drm.edid_firmware instead.", in which case do as it tells you and
>> use "drm.edid_firmware=<filename>".
>> 
>>> reading through all your messages, does this mean, that i should be 
>>> able
>>> to boot if we were to "fix" this edid file? and pass it? or is this
>>> something that needs change in kernel?
>> 
>> At present you have 2 issues
>> - the monitor or cable doesn't handle the hotplug line correctly
>> - the monitor doesn't provide a valid EDID.
>> 
>> The first you can workaround with "video=HDMI-A-2:D".
> 
> ok i retried 6.1 (with edid) and without hdmi_hotplug_force=1 and no
> rainbow, so i guess that is the reason why this video= parameter is
> needed, after all
> 
>> The second you can work around by capturing the EDID, fixing it, and
>> then using "drm.edid_firmware=<filename>".
>> The first fix is to just fixup the checksum (edid-decode even tells
>> you the correct value as 0xEB). That doesn't solve the fact that the
>> EDID contains other rubbish like being an analog display which may
>> cause further issues. The simplest fix for reporting as an analog
>> display is to change byte 20 from 0x00 to 0x80, and then correct the
>> checksum again.
>> 
>> The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
>> In order to support 4k60 it needs to support HDMI2.0 and enabling
>> scrambling via SCDC. That should also be signalled in the EDID Sink
>> Capability Data Structure block but isn't, so 4k60 support may be
>> compromised.
>> 
>> Sorry, all of this comes back to the monitor vendor shipping rubbish.
>> None of this is the fault of the vc4 driver, and it only worked under
>> 5.16 by chance.
> 
> Ok, so i changed the EDID based on what you said, but me knowing 
> nothing:
> (since i didn't have the extension data, i removed the extension)...
> 
> 00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
> 0b 1f 01 03 80 23 01 78 0a cf 74 a3 57 4c b0 23
> 09 48 4c 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
> 8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
> 58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
> 41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
> 00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 00 85
> 
> i did this with:
> hdmi_enable_4kp60=1
> disable_fw_kms_setup=1
> hdmi_force_hotplug=1
> disable_overscan=1
> display_auto_detect=1
> arm_boost=1
> otg_mode=1
> max_framebuffers=2
> arm_64bit=1
> 
> commandline args:
> Kernel command line: coherent_pool=1M 8250.nr_uarts=0
> snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1
> smsc95xx.macaddr=01:23:34:56:78:9A vc_mem.mem_base=0x3ec00000
> vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 rw
> ip=eth0:dhcp nameserver=10.A.B.1
> root=10.A.B.12:/data/nfs/aarch64/rpi4-mediabox-latest:nfsvers=3
> drm.edid_firmware=edid/salora-edid-fix.bin video=HDMI-A-1:D
> radeon.runpm=0 splash=silent quiet rootwait
> plymouth.ignore-serial-consoles
> Unknown kernel command line parameters "nameserver=10.A.B.1
> splash=silent", will be passed to user space.
> 
> and I have 1080p@60Hz, this is the drm output:
> 
> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> [drm] forcing HDMI-A-1 connector on
> Registered IR keymap rc-cec
> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
> Registered IR keymap rc-cec
> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
> 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 1
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough
> to support 4k @ 60Hz.
> vc4-drm gpu: [drm] Please change your config.txt file to add 
> hdmi_enable_4kp60.
> Console: switching to colour frame buffer device 240x67
> vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> 
> weird that it asks to add the 4kp60, while i had added that? and the
> edid also contains that?
> 
> do i need to change the edid file further to get 4kp60 ?
> 
> [snip]
> 
> Thanks in advance,


I donno if this is related or not, but since 6.1 has v3d, i'm assuming 
the opengl compositor will be faster and not draw too much cpu?

I did try youtube video, but that on 1080p fullscreen, takes all the CPU 
and seems to have dropped frames still?

does rpi4B actually have video decoding hardware? and is this related to 
drm? because netflix did not work at all, which requires drm, but is 
this a different a different drm than this driver?

Sorry for the maybe unrelated questions, if they are, maybe you can 
refer me to somewhere?

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

[Dave Stevenson]

On Fri, 10 Mar 2023 at 12:59, AL13N <alien@rmail.be> wrote:
>
>
> I donno if this is related or not, but since 6.1 has v3d, i'm assuming
> the opengl compositor will be faster and not draw too much cpu?
>
> I did try youtube video, but that on 1080p fullscreen, takes all the CPU
> and seems to have dropped frames still?

Does your browser actually use sensible EGL calls to pass dmabufs
around the system? Chromium with Ozone sort of does, but that's about
it.
It's another thing that is implemented in Raspberry Pi OS.

> does rpi4B actually have video decoding hardware?

I've already referred you to https://github.com/lategoodbye/rpi-zero/issues/43
> VCHIQ codecs - Unknown

It is present in our vendor kernel, but not upstreamed. You've chosen
to run mainline.

> and is this related to
> drm? because netflix did not work at all, which requires drm, but is
> this a different a different drm than this driver?

Digital Rights Management != Direct Rendering Manager.

Netflix on an unsecured platform will only work through something like
Widevine for software decode.

  Dave

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

[AL13N]

Dave Stevenson schreef op 2023-03-10 14:10:
> On Fri, 10 Mar 2023 at 12:59, AL13N <alien@rmail.be> wrote:
>> 
>> 
>> I donno if this is related or not, but since 6.1 has v3d, i'm assuming
>> the opengl compositor will be faster and not draw too much cpu?
>> 
>> I did try youtube video, but that on 1080p fullscreen, takes all the 
>> CPU
>> and seems to have dropped frames still?
> 
> Does your browser actually use sensible EGL calls to pass dmabufs
> around the system? Chromium with Ozone sort of does, but that's about
> it.
> It's another thing that is implemented in Raspberry Pi OS.

I'm on KDE, disabled compositor, used firefox, used the h264fi plugin to 
force h264, set in about:config the layers.acceleration-force to true. I 
do notice v3d_bin and v3d_render being active, but definately the RDD 
process is using a lot of CPU, so likely no video decoding...

I don't have chromium on this aarch64, there seemed to be some issue 
compiling it, so distro set exclusivearch on... I'll try to rebuild 
this... Ozone, meaning the theme, because it uses EGL? maybe this means 
that on plasma, i should turn the opengl compositor back on, it may 
help(?)

>> does rpi4B actually have video decoding hardware?
> 
> I've already referred you to 
> https://github.com/lategoodbye/rpi-zero/issues/43
>> VCHIQ codecs - Unknown
> 
> It is present in our vendor kernel, but not upstreamed. You've chosen
> to run mainline.

Ah, this is the crucial piece it seems... i remember the cec-client also 
needing vchiq_arm (there was an url someplace where you could build 
this), i need to take a look at this.

>> and is this related to
>> drm? because netflix did not work at all, which requires drm, but is
>> this a different a different drm than this driver?
> 
> Digital Rights Management != Direct Rendering Manager.
> 
> Netflix on an unsecured platform will only work through something like
> Widevine for software decode.

I did find a widevine .so library built for aarch64 someplace, but that 
library alone doesn't seem to be enough, i need to find some widevine 
addon files, someplace? but widevine didn't seem to be available for 
aarch64, only armv7 ?

>   Dave

Thanks for clarifying all this! That makes everything a ton clearer...

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

[AL13N]

AL13N schreef op 2023-03-10 13:38:
> Dave Stevenson schreef op 2023-03-09 13:59:
>> On Wed, 8 Mar 2023 at 22:46, AL13N <alien@rmail.be> wrote:
>>> 
>>> AL13N schreef op 2023-03-08 22:16:
>>> > Maxime Ripard schreef op 2023-03-08 13:35:
>>> >> Hi,
>>> >>
>>> >> On Tue, Mar 07, 2023 at 05:10:16PM +0000, Dave Stevenson wrote:
>>> >>> On Tue, 7 Mar 2023 at 16:25, AL13N <alien@rmail.be> wrote:
>>> >>> > AL13N schreef op 2023-03-06 17:34:
>>> >>> > > 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.
>>> >>
>>> >> If it's an option, bisecting between 5.16 and 5.17 which commit
>>> >> introduced the regression would be nice.
>>> >>
>>> >>> 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
>>> >>
>>> >> We can easily test that: could you try booting with video=HDMI-A-1:D
>>> >> (or
>>> >> HDMI-A-2, depending on whether you use HDMI0 or HDMI1) and see if it
>>> >> helps?
>>> >
>>> > in kernel 6.1 or kernel 5.17 ?
>>> 
>>> in 6.1 at least i booted with video=HDMI-A-2:D (i'm plugged into the
>>> hdmi farthest from the power)
>>> 
>>> and I did see BAD stuff here too:
>>> 
>>> 
>>> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
>>> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
>>> Registered IR keymap rc-cec
>>> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
>>> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
>>> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
>>> [drm] forcing HDMI-A-2 connector on
>>> Registered IR keymap rc-cec
>>> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
>>> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
>>> 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 1
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 235
>>>         [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
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
>>> vc4-drm gpu: [drm] Cannot find any crtc or sizes
>>> 
>>> 
>>> a bit puzzling why it does EDID block twice and it's twice checksum
>>> invalid?
>>> I also see forcing connector on.
>>> 
>>> earlier, i did try to make an edid file from a modeline that worked 
>>> on
>>> 5.16 and pass it using drm_kms_helper.edid_firmware= ; but that 
>>> didn't
>>> work, there only was some kind of warning that i should use something
>>> else...
>> 
>> It always helps to actually quote warnings or errors.
>> Almost certainly "drm_kms_helper.edid_firmware is deprecated, please
>> use drm.edid_firmware instead.", in which case do as it tells you and
>> use "drm.edid_firmware=<filename>".
>> 
>>> reading through all your messages, does this mean, that i should be 
>>> able
>>> to boot if we were to "fix" this edid file? and pass it? or is this
>>> something that needs change in kernel?
>> 
>> At present you have 2 issues
>> - the monitor or cable doesn't handle the hotplug line correctly
>> - the monitor doesn't provide a valid EDID.
>> 
>> The first you can workaround with "video=HDMI-A-2:D".
> 
> ok i retried 6.1 (with edid) and without hdmi_hotplug_force=1 and no
> rainbow, so i guess that is the reason why this video= parameter is
> needed, after all
> 
>> The second you can work around by capturing the EDID, fixing it, and
>> then using "drm.edid_firmware=<filename>".
>> The first fix is to just fixup the checksum (edid-decode even tells
>> you the correct value as 0xEB). That doesn't solve the fact that the
>> EDID contains other rubbish like being an analog display which may
>> cause further issues. The simplest fix for reporting as an analog
>> display is to change byte 20 from 0x00 to 0x80, and then correct the
>> checksum again.
>> 
>> The EDID advertises 4k60, 1080p60, and GTF 2288x1432 @ 61Hz.
>> In order to support 4k60 it needs to support HDMI2.0 and enabling
>> scrambling via SCDC. That should also be signalled in the EDID Sink
>> Capability Data Structure block but isn't, so 4k60 support may be
>> compromised.
>> 
>> Sorry, all of this comes back to the monitor vendor shipping rubbish.
>> None of this is the fault of the vc4 driver, and it only worked under
>> 5.16 by chance.
> 
> Ok, so i changed the EDID based on what you said, but me knowing 
> nothing:
> (since i didn't have the extension data, i removed the extension)...
> 
> 00 ff ff ff ff ff ff 00 36 74 00 00 00 00 00 00
> 0b 1f 01 03 80 23 01 78 0a cf 74 a3 57 4c b0 23
> 09 48 4c 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
> 8a 00 c4 8e 21 00 00 1e 02 3a 80 18 71 38 2d 40
> 58 2c 45 00 c4 8e 21 00 00 1e 00 00 00 fc 00 53
> 41 4c 4f 52 41 0a 20 20 20 20 20 20 00 00 00 fd
> 00 3b 46 1f 8c 3c 00 0a 20 20 20 20 20 20 00 85
> 
> i did this with:
> hdmi_enable_4kp60=1
> disable_fw_kms_setup=1
> hdmi_force_hotplug=1
> disable_overscan=1
> display_auto_detect=1
> arm_boost=1
> otg_mode=1
> max_framebuffers=2
> arm_64bit=1
> 
> commandline args:
> Kernel command line: coherent_pool=1M 8250.nr_uarts=0
> snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1
> smsc95xx.macaddr=01:23:34:56:78:9A vc_mem.mem_base=0x3ec00000
> vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 rw
> ip=eth0:dhcp nameserver=10.A.B.1
> root=10.A.B.12:/data/nfs/aarch64/rpi4-mediabox-latest:nfsvers=3
> drm.edid_firmware=edid/salora-edid-fix.bin video=HDMI-A-1:D
> radeon.runpm=0 splash=silent quiet rootwait
> plymouth.ignore-serial-consoles
> Unknown kernel command line parameters "nameserver=10.A.B.1
> splash=silent", will be passed to user space.
> 
> and I have 1080p@60Hz, this is the drm output:
> 
> [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 0
> vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
> [drm] forcing HDMI-A-1 connector on
> Registered IR keymap rc-cec
> rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
> input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
> vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
> Registered IR keymap rc-cec
> rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
> input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
> 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 1
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough
> to support 4k @ 60Hz.
> vc4-drm gpu: [drm] Please change your config.txt file to add 
> hdmi_enable_4kp60.
> Console: switching to colour frame buffer device 240x67
> vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> [drm] Got external EDID base block and 0 extensions from
> "edid/salora-edid-fix.bin" for connector "HDMI-A-1"
> 
> weird that it asks to add the 4kp60, while i had added that? and the
> edid also contains that?

Do you have any idea on how to get the 4k@60Hz to work on this new EDID 
above, if 2.0 is required, Do I need to have this extension block, I 
tried looking for the EDID2.0 structure, but i only found references 
saying it's obsoleted? this is the X log part:

[    29.802] (II) modeset(0): EDID for output HDMI-1
[    29.803] (II) modeset(0): Manufacturer: MST  Model: 0  Serial#: 0
[    29.803] (II) modeset(0): Year: 2021  Week: 11
[    29.803] (II) modeset(0): EDID Version: 1.3
[    29.803] (II) modeset(0): Digital Display Input
[    29.803] (II) modeset(0): Max Image Size [cm]: horiz.: 35  vert.: 1
[    29.803] (II) modeset(0): Gamma: 2.20
[    29.803] (II) modeset(0): No DPMS capabilities specified
[    29.803] (II) modeset(0): Supported color encodings: RGB 4:4:4 YCrCb 
4:4:4
[    29.803] (II) modeset(0): First detailed timing is preferred mode
[    29.803] (II) modeset(0): redX: 0.640 redY: 0.340   greenX: 0.300 
greenY: 0.690
[    29.803] (II) modeset(0): blueX: 0.138 blueY: 0.038   whiteX: 0.282 
whiteY: 0.297
[    29.803] (II) modeset(0): Manufacturer's mask: 0
[    29.803] (II) modeset(0): Supported detailed timing:
[    29.803] (II) modeset(0): clock: 594.0 MHz   Image Size:  708 x 398 
mm
[    29.803] (II) modeset(0): h_active: 3840  h_sync: 4016  h_sync_end 
4104 h_blank_end 4400 h_border: 0
[    29.803] (II) modeset(0): v_active: 2160  v_sync: 2168  v_sync_end 
2178 v_blanking: 2250 v_border: 0
[    29.803] (II) modeset(0): Supported detailed timing:
[    29.803] (II) modeset(0): clock: 148.5 MHz   Image Size:  708 x 398 
mm
[    29.803] (II) modeset(0): h_active: 1920  h_sync: 2008  h_sync_end 
2052 h_blank_end 2200 h_border: 0
[    29.803] (II) modeset(0): v_active: 1080  v_sync: 1084  v_sync_end 
1089 v_blanking: 1125 v_border: 0
[    29.803] (II) modeset(0): Monitor name: SALORA
[    29.803] (II) modeset(0): Ranges: V min: 59 V max: 70 Hz, H min: 31 
H max: 140 kHz, PixClock max 605 MHz
[    29.803] (II) modeset(0): EDID (in hex):
[    29.803] (II) modeset(0):   00ffffffffffff003674000000000000
[    29.803] (II) modeset(0):   0b1f0103802301780acf74a3574cb023
[    29.803] (II) modeset(0):   09484c00000001010101010101010101
[    29.803] (II) modeset(0):   01010101010108e80030f2705a80b058
[    29.803] (II) modeset(0):   8a00c48e2100001e023a801871382d40
[    29.803] (II) modeset(0):   582c4500c48e2100001e000000fc0053
[    29.803] (II) modeset(0):   414c4f52410a202020202020000000fd
[    29.803] (II) modeset(0):   003b461f8c3c000a2020202020200085
[    29.804] (II) modeset(0): Printing probed modes for output HDMI-1
[    29.804] (II) modeset(0): Modeline "1920x1080"x60.0  148.50  1920 
2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)