<Kwiboo>
naoki: for the usbdp_phy1 on rock 5b, instead of storing we should probably be able to remove it and its related nodes from the u-boot.dtsi, I think they already are part of dts/upstream since the v6.10-dts update
<naoki>
oops
<naoki>
Kwiboo: for rock-5b, if we cherry-pick v6.11-rc1-dts, we can remove some sfc node. should I do this?
<naoki>
s/some sfc node/some sfc props/
<Kwiboo>
sure, the bootph props still must remain, but remaining sfc props can be removed
<Kwiboo>
this can also be done for rock-3a, main sfc props was already merged with v6.10-dts
stikonas has quit [Quit: Konversation terminated!]
<naoki>
Kwiboo: are pcie3x2_reset_h related props required for rock 3a?
<Kwiboo>
naoki: yes it is required, without it the board freeze when running "pci enum" and nothing is mounted in M.2 M-key slot
<Kwiboo>
should really be properly fixed in upstream linux
<naoki>
btw I noticed uart6 is placed strange area in rock 3a ;)
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<naoki>
oh... cherry-picking dts changes for rock-5b is difficult... it needs many base file changes such as rk3588-base.dtsi
SystemError has quit [Remote host closed the connection]
<naoki>
so I'll send minimal change ;)
SystemError has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
SystemError has quit [Remote host closed the connection]
SystemError has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
franoosh has quit [Changing host]
franoosh has joined #linux-rockchip
paulk has quit [Ping timeout: 245 seconds]
paulk has joined #linux-rockchip
paulk has joined #linux-rockchip
alpernebbi has quit [Ping timeout: 255 seconds]
warpme has joined #linux-rockchip
SystemError has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
Livio has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
<qschulz>
naoki: just cherry-pick all patches then :)
stikonas has quit [Quit: Konversation terminated!]
raster has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 276 seconds]
kevery1 is now known as kevery
gnuiyl has quit [Remote host closed the connection]
psydroid2 has joined #linux-rockchip
naoki has quit [Quit: naoki]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<minute>
i got the dsi2 driver to compile in mainline yesterday but got > [ 289.482016] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
<minute>
so maybe missing some clock?
<minute>
ah, the hang occurs in dw_mipi_dsi2_transfer
<minute>
it looks like it attempts to transfer before the encoder or the phy are enabled
<minute>
ok, checking for power status in the transfer function makes it boot. the interface is not starting because > platform display-subsystem: deferred probe pending: (reason unknown)
Livio has quit [Ping timeout: 252 seconds]
erg_ has joined #linux-rockchip
franoosh has quit [Ping timeout: 252 seconds]
erg_ has quit [Remote host closed the connection]
erg_ has joined #linux-rockchip
erg__ has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]
franoosh has joined #linux-rockchip
erg__ has quit [Read error: Connection reset by peer]
franoosh has quit [Read error: Connection reset by peer]
erg_ has joined #linux-rockchip
erg_ has quit [Read error: Connection reset by peer]
jmabsd has joined #linux-rockchip
<jmabsd>
Hi all - first thank you for your help debugging the bricked Debian Rock 5 B the other day.
<jmabsd>
And then a specs thing: On the Rock 5 B, what chip is the onboard ethernet NIC actually, is it a 2.5 gigabit per second Realtek 8125?
<jmabsd>
Let me share with you a weird experience: The Intel 225 model 2.5 gigabit NIC, that's the IGC driver, it has problems with the speed auto-negotiation, that are so bad problems that when the bug hits, the whole NIC stops working until you power cycled. What a disaster.
<qschulz>
5GTs, and themn you have the throughput table in GBps
<qschulz>
still theoretical
<jmabsd>
qschulz: my limited knowledge on the topic is that SFP+ only heats up when you use cupper transmitters. for optical they are cool.
<jmabsd>
each 10GBASE-T (cupper) transmitter will consume a few watts, was it 3 or 4 or more I don't remember - enough to maybe overpower a passively cooled switch.
<qschulz>
jmabsd: you also need to take into account if whatever provides power to the m.2 actually can actually provide that amount of power
<qschulz>
jmabsd: not all USB-C port can deliver 100W for example, so you need to know what's behind, same for m.2 I assume
<qschulz>
(well, USB-C you have negotiation so wrong example :) )
<jmabsd>
qschulz: yeah the USBC power supply to the Rock 5B must be strong enough indeed.
<jmabsd>
I think count ~10 watts for the NIC.
<qschulz>
jmabsd: not only that, the regulator that provides power to the m.2 too
<jmabsd>
if I recall right the Rock 5B will power-negotiate the USBC to the highest volatage available up to 20V.
<jmabsd>
it will then voltage-step down to 5 volt etc. internally.
<jmabsd>
i thiink the voltage stepper is not a constraint
<qschulz>
the m.2 e-key is fed VCC3V3_WF
<qschulz>
it comes from an SY8113B, datasheet says 3A max output current
<jmabsd>
so max 9W?
<jmabsd>
for each M.2?
<jmabsd>
the 5B has two
<qschulz>
this SY8113B is fed VCC_5V0
<qschulz>
which comes from the output of MP8759
<qschulz>
and seems to be shared between VCC5V0_USB and VCC5V0_SYS and is written ">8A"
<jmabsd>
qschulz: The M.2 PCI:es, both of them, consume... both 3.0V and 5.0V?
<qschulz>
so I assume 5V 8A to share between those three power rails
<jmabsd>
which
<jmabsd>
so there's 9W of 3V, and 40W of 5V, internal voltage stepping
<jmabsd>
sounds OK
<qschulz>
only 3.3v on both m.2 it seems
<qschulz>
from two different power rails
<qschulz>
VCC3V3_PCIE30 and VCC3V3_WF
<qschulz>
both from a different SY8113B fed the same VCC_5V0
<qschulz>
so individually likely something like 3.3V*3A max though you have to be careful about the combined max of VCC5V0_USB, VCC5V0_SYS and VCC_5V0
<minute>
qschulz: oh wow @ SPLL, thanks. i do use vendor uboot though
<minute>
i will try to see if i can read the speed of this clock
<qschulz>
minute: any reason for not using upstream U-Boot?
<minute>
qschulz: just didn't get to it yet
<minute>
qschulz: i.e. no reason to flash a different uboot
<qschulz>
minute: hehe, first thing I did was to get rid of Rockchip's U-Boot :)
<minute>
is vp3 of vop2 supposed to work? i tried to change to dsi1_in_vp3 but now i get > Bogus possible_crtcs: [ENCODER:80:DSI-80] possible_crtcs=0x0 (full crtc mask=0x1)
<qschulz>
minute: there's another patch in the series of the patch for the kernel you mentioned earlier
<qschulz>
though Heiko said it shouldn't be needed apparently
<minute>
./kernel/debug/clk/spll/clk_rate says 702mhz so that should be fine
<minute>
qschulz: ohhh thanks for mentioning that... that's about vp3
<jmabsd>
so you can have one SSD with 16gbit and one ethernet with 16gbit bandwidth there. that's enough for full 10gbps speed.
<jmabsd>
better yet would have been if they put a PCIe switch on the PCB, I think they did not.
<qschulz>
jmabsd: why would it be better?
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #linux-rockchip
dsimic has quit [Ping timeout: 255 seconds]
dsimic has joined #linux-rockchip
franoosh has joined #linux-rockchip
<minute>
ok, can't figure this out, giving up for now (dsi)
dsimic has quit [Quit: Reconnecting]
dsimic has joined #linux-rockchip
jmabsd has quit [Quit: Client closed]
franoosh has quit [Ping timeout: 272 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SystemError has quit [Remote host closed the connection]
testaccount has joined #linux-rockchip
testaccount has quit [Client Quit]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
warpme has joined #linux-rockchip
Stat_headcrabed has joined #linux-rockchip
warpme has quit [Client Quit]
<Kwiboo>
diederik: I started off a little bit late, but ffmpeg patches was sent earlier today at https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-August/332034.html, testing an updated rkvdec series for h264 hi10 and hevc now, will likely be delayed until tomorrow before it is on ML
<diederik>
cool!
<linkmauve>
Kwiboo, awesome! <3
<linkmauve>
I’ll test it on cedrus. :)
testaccount has joined #linux-rockchip
vagrantc has joined #linux-rockchip
testaccount has quit [Client Quit]
<CounterPillow>
Kwiboo: thank you!
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<dsimic>
Kwiboo: nice!
<linkmauve>
Kwiboo, possibly a missing dependency on udev, I get many such errors which I don’t get on master:
<linkmauve>
/usr/bin/ld: libavcodec/libavcodec.so: undefined reference to `udev_enumerate_scan_devices'
<linkmauve>
Weird, --enable-libudev wasn’t enough to get further.
<linkmauve>
And besides it’s already there in configure under v4l2_request_deps, hmm…
<diederik>
The ones before that was to 'upgrade' to a later upstream snapshot
<linkmauve>
I have already added --enable-libudev to my PKGBUILD and I do have the devel headers as my distribution doesn’t split that, so it can’t be it either, hmm…
<Kwiboo>
linkmauve: tested a fully clean build of ffmpeg? I had similar issue before and I think a clean build sorted it out
<linkmauve>
Kwiboo, yes, same issue after I rm’d the build directory; I’m still using ccache though but that’s highly unlikely to cause any such issue.
<Kwiboo>
or it could be that the required kernel headers is missing and there is no hwaccels being enabled -> automatic depends in ffmpeg configure make linking freaks out
<Kwiboo>
check build log or configure output, should list at least one of the v4l2_request hwaccels to work
<linkmauve>
/usr/include/linux/media.h and /usr/include/linux/videodev2.h are there, I’m building on a board with no media device or video device but that should only matter at runtime, not at buildtime.
<linkmauve>
#define CONFIG_V4L2_REQUEST 1
<linkmauve>
“External libraries providing hardware acceleration:” lists v4l2_request, but that’s the only occurence.
<Kwiboo>
could be that /usr/include/linux/videodev2.h is too old, is V4L2_CID_STATELESS_MPEG2_SEQUENCE defined ?
<linkmauve>
Ah no! I’m still on the version provided with linux 6.10…
<linkmauve>
Kwiboo, oh, this is provided by /usr/include/linux/v4l2-controls.h false alert.
<linkmauve>
I have up to AV1 declared in that file.
<Kwiboo>
hum, then I do not know, if possible please try without ccache and see if that sort it out
<Kwiboo>
I have had issues with pkg-config not being installed, kernel headers being too old (prior to v5.11), the hwaccels not being linked in and thus no -ludev for linker, and what seemed to be freaky cacheing issues when switching branches
<linkmauve>
It took 1:45 to fail instead of 39s, but the end result was the same. :(
<linkmauve>
Without ccache.
<Kwiboo>
could be that the codec specific hwaccels is not enabled, does "grep V4L2REQUEST ffbuild/config.mak" show anything?
<linkmauve>
!CONFIG_H264_V4L2REQUEST_HWACCEL=yes
<linkmauve>
!CONFIG_MPEG2_V4L2REQUEST_HWACCEL=yes
<linkmauve>
!CONFIG_HEVC_V4L2REQUEST_HWACCEL=yes
SystemError has joined #linux-rockchip
<linkmauve>
With --enable-hwaccel=mpeg2_v4l2request --enable-hwaccel=h264_v4l2request --enable-hwaccel=hevc_v4l2request it seems to work, thanks!
<Kwiboo>
hum, maybe I broke something just before sending patches, will take a closer look :-D
<linkmauve>
When either of these three is disabled, the udev dependency isn’t pulled in, sounds like it.
<Kwiboo>
Yeah, that was an issue I noticed earlier, will have to look for a better configure solution for next revision
stikonas has joined #linux-rockchip
<linkmauve>
How do you enable hwaccel in ffplay without vulkan? I’m still on a Mali-400 which won’t do that like ever.
<Kwiboo>
I do not think it is possible using ffplay, not something I have tested, I have used kod-gbm or mpv to do playback testing
<Kwiboo>
or use ffmpeg cmd to do decoding into null fmt or md5 when using fluster
<linkmauve>
mpv doesn’t need any special patch? I’ll compile it right away then. :)
<diederik>
Given I had some issues wrt drmprime, that version/PR surely does look interesting :)
<linkmauve>
Ok, with ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime I achieve 106 fps for 30% of CPU usage, vs. 40 fps with 370% of CPU usage. :)
<Kwiboo>
I am interested to know how much, if any, the reworked multiple pending request affect fps
warpme has joined #linux-rockchip
<linkmauve>
Oh nice, VP8 is also supported.
<linkmauve>
I’m building it.
warpme has quit [Ping timeout: 260 seconds]
<linkmauve>
Kwiboo, what is the commandline I should use? It says Unrecognized hwaccel: v4l2request. Supported hwaccels: drm vulkan
<Kwiboo>
yeah, the older versions should support vp8 and vp9, ffmpeg may need to run with: -init_hw_device drm:/dev/dri/renderD128 -hwaccel drm -hwaccel_output_format drm_prime
<linkmauve>
That still uses software decoding.
<Kwiboo>
do you have /dev/dri/renderD128 else any other /dev/dri/* device should work
<linkmauve>
Yes, /dev/dri/renderD128
<linkmauve>
It’s lima I think.
<linkmauve>
The other two card* are lima and sun4i-drm.
<linkmauve>
But they also result in software decoding.
<linkmauve>
The first one is on 6.0.1 with those patches, the second one on master with your patches.
<linkmauve>
Haha… !CONFIG_V4L2_REQUEST=yes
<Kwiboo>
hehe, yeah, the old version requires --enable-v4l2-request :)
<linkmauve>
Kwiboo, 96 fps with 20% of CPU time!
<linkmauve>
That sounds a tiny bit more efficient.
<linkmauve>
I can reproduce, master has more throughput and consumes significantly more CPU time.
<linkmauve>
My sample video decodes in 55s with 19% CPU on 6.0 + these patches, and in 49.5s with 29% CPU on master + your patches.
<linkmauve>
It’s a 3:45 music video encoded in H.264 by Youtube.
<linkmauve>
55.6s*
<Kwiboo>
great new version has more throughput, something that I hoped, it is possible that use of: -thread 1 (or any other number of threads) may change cpu usage and fps?
<Kwiboo>
or it could be -threads
<Kwiboo>
the old version will issue decoding of one frame, wait on it to compleate, then request decoding of next frame
<linkmauve>
With -threads 1, on master + your patches, I get 107 fps (down from 111 fps approximately) but using only 16% of CPU time.
<linkmauve>
Now the video decoded in 51.6s.
<Kwiboo>
the new version will request decoding of up to 4 frames before waiting for a frame to complete, so should have more throughput at the cost of higher cpu usage
<linkmauve>
The old version gets to 101 fps with -threads 1, using 14% of CPU time, and decoded the video in 54.7s.
<linkmauve>
From 107 to 111 fps I’m not sure it’s worth it to lower CPU usage by half.
<Kwiboo>
thanks for testing, so new code can get more throughput at cost of cpu usage, for normal playback I think it should be negiable as a video player typically only keep a few pre-decoded frames as buffer
<linkmauve>
To double the CPU usage*.
<Kwiboo>
yeah, it is up to the application using ffmpeg library to select how many threads to use, kodi probably default to number of cores similar to ffmpeg cmd
<Kwiboo>
not sure what mpv use by defailt
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 244 seconds]
naoki has joined #linux-rockchip
Livio has joined #linux-rockchip
warpme has joined #linux-rockchip
warpme has quit [Ping timeout: 272 seconds]
Livio has quit [Ping timeout: 272 seconds]
raster has quit [Quit: Gettin' stinky!]
warpme has joined #linux-rockchip
SystemError has quit [Remote host closed the connection]