Message-ID: <bed5f370-113f-4109-b8f4-870dd15e93ce@timsurber.de>
Date: Sun, 19 Jan 2025 03:14:28 +0100
From: Tim Surber <me@...surber.de>
To: Dmitry Osipenko <dmitry.osipenko@...labora.com>,
 Shreeya Patel <shreeya.patel@...labora.com>, heiko@...ech.de,
 mchehab@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, mturquette@...libre.com, sboyd@...nel.org,
 p.zabel@...gutronix.de, jose.abreu@...opsys.com, nelson.costa@...opsys.com,
 shawn.wen@...k-chips.com, nicolas.dufresne@...labora.com,
 hverkuil@...all.nl, hverkuil-cisco@...all.nl
Cc: kernel@...labora.com, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org
Subject: Re: [RESEND PATCH v5 0/4] Add Synopsys DesignWare HDMI RX Controller

Hi Dmitry,

I enabled the debug output and ran some tests again.


This is with the source (Windows / Nvidia GPU) set to 1920 x 1080 / 59 
Hz and 4:4:4 chroma. I use the default EDID.

# gst-launch-1.0 -v v4l2src device=/dev/video2 ! fakesink
# dmesg
hdmirx_hdmi_irq_handler: en_fiq
[  226.901822] fdee0000.hdmi_receiver: wait_reg_bit_status:  i:0, time: 10ms
[  226.938715] fdee0000.hdmi_receiver: wait_reg_bit_status:  i:36, time: 
50ms
[  226.938730] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
scdc_regbank_st:0x0
[  226.938738] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
HDMITX less than 3.4Gbps
[  226.946675] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  226.946689] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
scdc_regbank_st:0x0
[  226.946698] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
HDMITX less than 3.4Gbps
[  226.954724] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  226.954738] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
scdc_regbank_st:0x0
[  226.954746] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
HDMITX less than 3.4Gbps
[  226.962824] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  226.962838] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
scdc_regbank_st:0x0
[  226.962846] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config: 
HDMITX less than 3.4Gbps
[  226.962856] fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal 
lock ok, i:3
[  227.036484] fdee0000.hdmi_receiver: pkt_2_int_handler: pk2_st:0x800
[  227.036504] fdee0000.hdmi_receiver: pkt_2_int_handler: AVIIF_RCV_IRQ
[  227.036512] fdee0000.hdmi_receiver: hdmirx_hdmi_irq_handler: en_fiq
[  227.092219] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV444
[  227.092233] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[  227.092251] fdee0000.hdmi_receiver: hdmirx_format_change: queue 
res_chg_event
[  227.092261] fdee0000.hdmi_receiver: hdmirx_set_ddr_store_fmt: 
pix_fmt: YUV444, DMA_CONFIG1:0x12006001
[  227.092272] fdee0000.hdmi_receiver: hdmirx_interrupts_setup: enable
[  231.039033] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  231.039061] fdee0000.hdmi_receiver: get timings from dma
[  231.039068] fdee0000.hdmi_receiver: act:1920x1080p, total:2200x1125, 
fps:86, pixclk:214076000
[  231.039080] fdee0000.hdmi_receiver: hfp:84, hact:1920, hs:48, 
hbp:148, vfp:4, vact:1080, vs:5, vbp:36
[  231.039092] fdee0000.hdmi_receiver: tmds_clk:214076000, pix_clk:214076000
[  231.039100] fdee0000.hdmi_receiver: interlace:0, fmt:2, color:24, 
mode:hdmi
[  231.039108] fdee0000.hdmi_receiver: deframer_st:0x11


It seems that YUV444 is recognized - but not always - sometimes it does 
not register changes in the source and it tries to establish a pipeline 
still with RGB.

This is with the source set to RGB.
# gst-launch-1.0 -v v4l2src device=/dev/video2 ! fakesink

[  869.317467] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  869.317491] fdee0000.hdmi_receiver: get timings from dma
[  869.317497] fdee0000.hdmi_receiver: act:1920x1080p, total:2200x1125, 
fps:86, pixclk:214072000
[  869.317506] fdee0000.hdmi_receiver: hfp:84, hact:1920, hs:48, 
hbp:148, vfp:4, vact:1080, vs:5, vbp:36
[  869.317515] fdee0000.hdmi_receiver: tmds_clk:214072000, pix_clk:214072000
[  869.317521] fdee0000.hdmi_receiver: interlace:0, fmt:0, color:24, 
mode:hdmi
[  869.317528] fdee0000.hdmi_receiver: deframer_st:0x11
[  869.317534] fdee0000.hdmi_receiver: query_dv_timings: 1920x1080p86.49 
(2200x1125)
[  869.317556] fdee0000.hdmi_receiver: s_dv_timings: 1920x1080p86.49 
(2200x1125)
[  869.317574] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.317581] fdee0000.hdmi_receiver: hdmirx_set_fmt: req(1920, 1080), 
out(1920, 1080), fmt:0x33524742
[  869.317637] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.317650] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.317881] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.318092] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.318287] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total 
imagesize: 6220800
[  869.318298] fdee0000.hdmi_receiver: hdmirx_set_fmt: req(1920, 1080), 
out(1920, 1080), fmt:0x33524742
[  869.318836] fdee0000.hdmi_receiver: vid-cap-mplane: count 4, size 6220800
[  869.321814] fdee0000.hdmi_receiver: hdmirx_start_streaming: 
start_stream cur_buf y_addr:0xe10c0000, uv_addr:0xe10c0000
[  869.321831] fdee0000.hdmi_receiver: hdmirx_start_streaming: enable dma
[  869.331693] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:546
[  869.331708] fdee0000.hdmi_receiver: line_flag_int_handler: last have 
no dma_idle_irq
[  869.339684] fdee0000.hdmi_receiver: dma_irq st1:0x80, st13:0
[  869.348380] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:547


Observe the reported fps of 86 in the above log file. Also gstreamer 
reports a framerate of 214072/2475 - also around 86.

I could sometimes also create the "Device wants 1 planes" using RGB - 
replugging fixed it, but could never fix it in YUV444.

Next week I have time for more testing.

Best regards,
Tim

On 1/14/25 12:37, Dmitry Osipenko wrote:
> On 1/9/25 02:17, Tim Surber wrote:
>> Hi,
>>
>> I tested your patch with the command
>>
>> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
>>
>> If this worked I moved on to a visual test using
>>
>> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! queue ! v4l2convert !
>> waylandsink
>>
>> I used a Windows PC  with a Nvidia GTX 4060 as my source for the
>> following tests.
>>
>> | Format       | Result                                      |
>> | ------------ | ------------------------------------------- |
>> | 4k60p RGB    | Recognized as 1080p / 120 fps - no output   |
>> | 4k60p 4:2:2  | Recognized as 1080p / 120 fps - no output   |
>> | 4k60p 4:4:4  | Error: Device wants 1 planes                |
>> | 4k30p RGB    | ok                                          |
>> | 4k30p 4:2:2  | ok                                          |
>> | 4k30p 4:4:4  | Error: Device wants 1 planes                |
>> | FHD60p RGB   | ok                                          |
>> | FHD60p 4:2:2 | ok                                          |
>> | FHD60p 4:4:4 | Error: Device wants 1 planes                |
>>
>>
>> When testing 4:4:4 chroma I got the following error:
>>
>> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
>> /sys/v4l2/gstv4l2object.c(4344): gst_v4l2_object_set_format_full (): /
>> GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> Device wants 1 planes
>>
>> I could record and convert (with errors) the files with 4:4:4 chroma
>> using the command Shreeya posted, but the resulting video had wrong
>> colors and was flashing.
>>
>> I was not able to test 4:2:0 chroma. I tried to generate an custom EDID
>> with support for it but I could not select it in the graphics driver in
>> the source, maybe this is just an issue with my setup.
> 
> Thanks a lot for the testing, very appreciate it! Good that RGB works
> for you with no problems.
> 
> Testing YUV formats isn't trivial. Personally I've a custom setup with a
> modified display driver of RPi to test them. See more below.
> 
>> I also observed that the the framerate is reported wrong, for example
>> setting the source to FHD60p RGB resulted in the following:
>>
>> # v4l2-ctl --all -L --list-formats-ext -d /dev/video0
>> Active width: 1920
>>      Active height: 1080
>>      Total width: 2200
>>      Total height: 1125
>>      Frame format: progressive
>>      Polarities: -vsync -hsync
>>      Pixelclock: 214076000 Hz (86.50 frames per second)
>>
>> This wrong framerate reporting seemed to happen across all framerates
>> and resolutions. Gstreamer Pipeline negotation showed the same results.
> 
> I've re-tested YUV444 4k capture using RPi4, works flawlessly. Note for
> gst-launch-1.0 you used video1 and video0 device is used by v4l2-ctl
> command above, maybe you're using wrong device. Please post a complete
> output of the v4l2-ctl command.
> 
> The command I used to test YUV444 capture:
> 
> # v4l2-ctl --verbose -d /dev/video1
> --set-fmt-video=width=3840,height=2160,pixelformat=NV24 --stream-mmap=4
> --stream-skip=3 --stream-count=3300 --stream-to=hdmi.raw --stream-poll
> 
> The I converted captured data to a video file and played it:
> 
> # ffmpeg -f rawvideo -vcodec rawvideo -s 3840x2160 -r 30 -pix_fmt nv24
> -y -i hdmi.raw output.mkv && mpv output.mkv -loop 0
> 
> Don't see any problems with a reported framerate:
> 
> DV timings:
>          Active width: 3840
>          Active height: 2160
>          Total width: 4400
>          Total height: 2250
>          Frame format: progressive
>          Polarities: -vsync -hsync
>          Pixelclock: 296992000 Hz (30.00 frames per second)
> 
> Note the timing data reported by v4l2-ctl updates after launching the
> capture. It's not updated dynamically when you changing mode on the source.
> 
> Lastly, please run `echo 3 >
> /sys/module/synopsys_hdmirx/parameters/debug`.  Watch the kmsg log.
> Check that it says "hdmirx_get_pix_fmt: pix_fmt: YUV444" when you
> connecting HDMI cable to a YUV444 source and see other related messages.
> If it says RGB, then your source is transmitting RGB.
> 
>> During my testing I got sometimes an error
>>
>>
>> # dmesg
>> dma alloc of size 24883200 failed
>>
>>
>> I'm not sure when this happened and how to reproduce it.
> 
> This comes from v4l core, should be harmless as long as capture works.
> It's a known noisy msg, you may ignore it for today.
> 
>> Then I tried to use an AppleTV 4k as source. I don't know what
>> resolution it tried to negotiate but I got this error in addition to the
>> previous "Device wants 1 planes" and no connection:
>>
>> # dmesg
>> fdee0000.hdmi_receiver: hdmirx_query_dv_timings: signal is not locked
>> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
>> tmds_clk_ratio:0
>> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
>> dma_st10:0x10
>> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
>> tmds_clk_ratio:0
>> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
>> dma_st10:0x14
> 
> "Device wants 1 planes" sounds like you're using a wrong v4l video
> device. Please double check. Though, the "signal not lock" means it
> doesn't work anyways, please make sure you're using the default driver
> EDID and not a custom one.
> 

Powered by blists - more mailing lists