07:54 <CounterPillow> Where's the test file? If it's H.264 I can think of two scenarios where software decoding works out and hwdec doesn't at no fault to either detlev or mpp: 1. H.264 level 6, which has an incompatible change to motion vector lengths, or a 4:4:4 file encoded with an old x264 version and the SEI isn't acted on to enable a workaround for a bug that encoder had.

07:55 <CounterPillow> (that , should be a ", 2." I lost my train of thought)

12:34 <ndufresne4> CounterPillow: if you have broken files, mind sending them to me? On GST side we are missing profiles and level restrictions, which would allow discarding the HW decoder for 4:4:4 encoded files (it's not supported)

12:42 <CounterPillow> ndufresne4: for the broken old x264 4:4:4 output, https://trac.ffmpeg.org/ticket/6717 has one in the attachment it seems

12:54 <CounterPillow> for the level 6 stuff, JEEB of ffmpeg says he'll try to get me a sample.

12:59 <CounterPillow> ndufresne4: got a sample, content warning: very anime

12:59 <CounterPillow> <JEEB> CounterPillow: https://megumin.fushizen.eu/videos/mmd_renders/yukarin_conqueror_sample.mp4 at 28-29 secs towards the bottom left of the screen as well as of the character

13:56 <diederik> new kernel warning on Rock 5B with kernel 6.16-rc4: "[ 2.396543] clk_unregister: unregistering prepared clock: usb480m_phy2" ; more dmesg output @ https://paste.sr.ht/~diederik/38d8caa1ea0826c7b88330779a5a885ceb019029

13:57 <diederik> Is this an 'escalation' of "[ 2.864213] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after" which I had with previous kernel versions?

14:11 <diederik> Just a(nother) reboot and now I don't get a stack trace, but I do have the ehci_hcd warning again

15:23 <sre0> diederik: looks like a race condition between the USB PHY driver probe and the EHCI/OHCI controller driver probe

15:25 <sre> I guess what you are seeing is the USB PHY driver probing, registering its clock at some point. Then the USB controller driver probes and uses this clock. Then the PHY driver reaches an error in its probe routine and tries to unroll.

15:34 <diederik> sre: ok. fwiw I see that warning on most/all my rockchip devices. Usually, but not always.

15:36 <sre> First time I have seen it. My guess is, that the usb phy driver returns -EPROBE_DEFER somewhere after registering the output clock, as there is no other error printed.

15:38 <diederik> I've been seeing it for a while now (several kernel releases). The stack trace was new though

15:40 <sre> Usually this is solved by moving the resource registration at the end of the probe routine. But the PHY provider basically has the same issue, so this is a bit tricky :)

15:41 <sre> You could try moving the rockchip_usb2phy_clk480m_register() call before the devm_of_phy_provider_register() call in drivers/phy/rockchip/phy-rockchip-inno-usb2.c

15:50 <diederik> Seems to have started with kernel 6.13 (on my Q64-A at least)

15:55 <sre> diederik: If my educated guess is right, this is a race condition, so it might have been "introduced" by a kernel config or compiler change on your side resulting in slightly changed timings

15:57 <diederik> I assumed it was a race condition as it doesn't happen always. It's not a compiler change as I've been on GCC for quite a while now. But it can indeed be a kernel config change which brought the issue to light

15:59 <diederik> It's present on "6.13-arm64", but not on "6.13-rc2+unreleased-arm64-cknow" or "6.13+unreleased-arm64-cknow" and I'm not sure if I can still figure out what exactly changed between those versions

16:01 <sre> Aaprt from the suggested code move, you could also have a look at the debug kernel messages from the PHY driver. It is using dev_err_probe(), which logs -EPROBE_DEFER messages via dev_dbg().

16:02 <diederik> maybe this is another instance where the difference is with ``=y`` vs ``=m`` (ref: https://lore.kernel.org/linux-rockchip/20250628180914.1177177-2-pZ010001011111@proton.me/)

16:03 <diederik> That's seems easier to try as I should be able to get that via dynamic debug

16:10 <diederik> Currently working on some other things, but I've taken notes. Thanks :)

21:01 <CyReVolt> Turns out that Rockchip's TRM part 2 for the RK3568 actually has lots of details on DRAM init and training, with most registers of the controller and the PHY listed and explained, just some missing (AFAICT).