lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<DC-IRC> [Discord] <microlinux> so, @mecoblock which one I should trust hahaha
<DC-IRC> [Discord] <microlinux> the dtb clearly addresses 1.0 ghz
<DC-IRC> [Discord] <mecoblock> 850* means 850mhz, armbian DT doesn’t have the https://github.com/hbiyik/linux/commit/a173263262cd51bce021859b06b90405cab963d2 yet (4ghz or 1ghz in this case doesn’t make a difference just not leaving it at 850 is important)
<DC-IRC> [Discord] <microlinux> of cpourse I know what 850 means hahahahahahahaa
<DC-IRC> [Discord] <microlinux> but one says 1.0 and the other 850
<DC-IRC> [Discord] <microlinux> okay, will try those clock rates
<DC-IRC> [Discord] <mecoblock> you can use this but set it 1ghz instead of 4ghz, I will do that as PR soon ™️
<DC-IRC> [Discord] <microlinux> oka, I am not goin to touch this opp-1000000000 {
<DC-IRC> [Discord] <microlinux> opp-supported-hw = <0xf9 0xffff>;
<DC-IRC> [Discord] <microlinux> opp-hz = <0x00 0x3b9aca00>;
<DC-IRC> [Discord] <microlinux> opp-microvolt = <0xcf850 0xcf850 0xcf850 0xcf850 0xcf850 0xcf850>;
<DC-IRC> [Discord] <microlinux> opp-microvolt-L1 = <0xcc77c 0xcc77c 0xcf850 0xcc77c 0xcc77c 0xcf850>;
<DC-IRC> [Discord] <microlinux> opp-microvolt-L2 = <0xc96a8 0xc96a8 0xcf850 0xc96a8 0xc96a8 0xcf850>;
<DC-IRC> [Discord] <microlinux> opp-microvolt-L3 = <0xc65d4 0xc65d4 0xcf850 0xc65d4 0xc65d4 0xcf850>;
<DC-IRC> [Discord] <microlinux> opp-microvolt-L4 = <0xc3500 0xc3500 0xcf850 0xc3500 0xc3500 0xcf850>;
<DC-IRC> [Discord] <microlinux> opp-microvolt-L5 = <0xc042c 0xc042c 0xcf850 0xc042c 0xc042c 0xcf850>;
<DC-IRC> [Discord] <microlinux> };
<DC-IRC> [Discord] <microlinux> since armbian is king of kings, we should be able to use 1.0 on rk3588, give me a code hint on pm
<DC-IRC> [Discord] <microlinux> and send the PR
<DC-IRC> [Discord] <microlinux> i do hate when linux and user are being lied, that's all. and devfreq was not telling me the truth all this fucking time
<DC-IRC> [Discord] <microlinux> oh, I know what I have to change @mecoblock
<DC-IRC> [Discord] <microlinux> so, each 0xcf850 for 0xf4240
<DC-IRC> [Discord] <mecoblock> it should just be the one line from the commit?
<DC-IRC> [Discord] <microlinux> the i dont understand
<DC-IRC> [Discord] <microlinux> i show you the armbian opp table for the gpu
<DC-IRC> [Discord] <microlinux> i've shown you the armbian opp table for the gpu
<DC-IRC> [Discord] <mecoblock> just wait then until I PR it to armbian before you break it by throwing more voltage 😅
<DC-IRC> [Discord] <microlinux> okay
<DC-IRC> [Discord] <microlinux> let me know
<DC-IRC> [Discord] <mecoblock> teased yall with the potential performance gains, knew I should’ve posted the article after I merged everything haha
<DC-IRC> [Discord] <kwiboo> @mecoblock for rk3588 mainline gpu optimization, you should probably use `<&scmi_clk SCMI_CLK_GPU>` as `core` clock or similar, to make use of the gpu pvtpll instead of gpll for the higher freq, see https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3588/drivers/scmi/rk3588_clk.c#L945-L991
<DC-IRC> [Discord] <mecoblock> I'm no where near qualified for this change up stream. I barely understand it downstream bc of Boogie's posts related to it.
<DC-IRC> [Discord] <kwiboo> the cpu, gpu and npu is primarily meant to use the pvtpll for higher freq, and with that only the voltage level and silicon quality will regulate how fast the block truly runs at
<DC-IRC> [Discord] <mecoblock> I haven’t even looked into mainline yet and if the bug is also present there. But thank you for giving me some directions so I can read into it
<DC-IRC> [Discord] <kwiboo> upstream device tree for rk3588, rk3568 and rk3576 seem to use the plain gpu clock instead of the scmi gpu clk, for vendor I expect it may be using the scmi clk (and thus the pvtvpll and the pvtpll ring length, silicon quality and the voltage is what actually regulates the speed)
<DC-IRC> [Discord] <kwiboo> for the gpu node submission for rk3528 I will instead use the scmi clk and the performance should probably closer match vendor, i.e. https://github.com/Kwiboo/linux-rockchip/commit/f2c92833ee1209dee879303b37c723f4d1f98c85 should probably look at the other rk35xx upstream clocks at some point 😄
<DC-IRC> [Discord] <kwiboo> took a peek at your vendor kernel rk3588 device tree and the gpu panthor node you are not using using scmi clock, so clock rate changes are required, you should probably just change to use `<&scmi_clk SCMI_CLK_GPU>` instead of `<&cru CLK_GPU>` to match how the libmali node behaves
<DC-IRC> [Discord] <boogieboogieboogie> hello kwiboo, i had checked that but unfortunately the clock is simply ignored when scmi_clk referenced
<DC-IRC> [Discord] <boogieboogieboogie> also in rk3528, i am not even sure mali block has an option to be driven by cru
<DC-IRC> [Discord] <kwiboo> also possible that panthor driver must enable the normal CLK_GPU
<DC-IRC> [Discord] <boogieboogieboogie> only method i coudl find is to force scmi_clock in the &firmware block and disable devfreq
<DC-IRC> [Discord] <boogieboogieboogie> was useless anyway
<DC-IRC> [Discord] <boogieboogieboogie> this is for rk3528 though, 3588 can be driven by cru
<DC-IRC> [Discord] <kwiboo> to my understanding there is a flag that changes the cpu, gpu, npu clock paths to use the pvtpll instead of the normal clock path, the linux dirver is not awear of this flag, so clock rates are not reflected in linux, only for the scmi clock
<DC-IRC> [Discord] <boogieboogieboogie> yeah exactly it is in GRF
<DC-IRC> [Discord] <boogieboogieboogie> i mean select option for gpu core
<DC-IRC> [Discord] <kwiboo> when linux set clock rate for the scmi clock rate, tf-a will check if it should use pvtpll (it has a ring lenght to be configured) and then activates use of pvtpll, for linux part the opp table basically is there to regulate the voltage, as with pvtpll only the voltage will regulate speed
<DC-IRC> [Discord] <boogieboogieboogie> but, i am not so sure if the kernel supposed to select this, when referenced clock is scmi,
<DC-IRC> [Discord] <boogieboogieboogie> atf is supposed to handle this
<DC-IRC> [Discord] <kwiboo> yep, but that only works if the core clock is the scmi clock, else linux will never signal tf-a to change the rate and activate the pvtpll
<DC-IRC> [Discord] <boogieboogieboogie> ook i just read your msg
<DC-IRC> [Discord] <boogieboogieboogie> but it is not selecting for whatever the weird ass reason with rk3588
<DC-IRC> [Discord] <boogieboogieboogie> however, i only tried in bsp backport of panthor
<DC-IRC> [Discord] <boogieboogieboogie> may be rockchip broke someting
<DC-IRC> [Discord] <boogieboogieboogie> i never tried mainline
<DC-IRC> [Discord] <kwiboo> at least for upstream lima it only changes the core clk not the bus clock, have not looked into panthor / panfrost
<DC-IRC> [Discord] <boogieboogieboogie> yeah this is also my experience in bsp, however, when scmi clock was referenced with lima i had same behaviour of not changing the scmi clock. So if you are saying mainline is really changing the core clock with lima when scmi is referenced, then this explains weirdness in rk3588 as well. Simply bsp scmi clocks have issues with devfreq or even the clock driver.
<DC-IRC> [Discord] <boogieboogieboogie> one question, do you know if rk3528 clock can be driven by cru, even the cpu core?
<DC-IRC> [Discord] <boogieboogieboogie> is there such a mux as in rk3588?
<DC-IRC> [Discord] <boogieboogieboogie> is there such a mux in rk3528 as in rk3588?
<DC-IRC> [Discord] <kwiboo> looking at panthor and panfrost only the core clock seem to be regulated, so setting the core clock to the scmi clock should probably work for mainline drivers, however the "normal" clock may also need to be enabled somehow
<DC-IRC> [Discord] <kwiboo> I expect there to be something similar for rk3528, for the 200mhz rate it seem to be running using normal pll, basically what seem to be done for all/most socs, at sleep change to use 200mhz and normal pll, and for the faster rates change to use pvtpll instead and regulate speed using the voltage
<DC-IRC> [Discord] <kwiboo> when I forced use of slower rated 100-300mhz (or similar) the real gpu_clk rate was affected, and anything higher only the scmi clk rate, and that seem to match what is done for the scmi handling in upstream tf-a for rk3568, rk3576 and rk3588
<DC-IRC> [Discord] <boogieboogieboogie> it could be that, may be the CRU source PLL does not have enough dividers so it cant go over a certain frequency and switches to pvtpll by tfa. i had never tried lover than 400 afaik. do you remember which cru PLL clock source was 3528 gpu was using
<DC-IRC> [Discord] <boogieboogieboogie> i guess this:
<DC-IRC> [Discord] <boogieboogieboogie> COMPOSITE_NODIV(ACLK_GPU_ROOT, "aclk_gpu_root", mux_500m_300m_100m_24m_p, CLK_IS_CRITICAL,
<DC-IRC> [Discord] <boogieboogieboogie> RK3528_CLKSEL_CON(76), 0, 2, MFLAGS,
<DC-IRC> [Discord] <boogieboogieboogie> RK3528_CLKGATE_CON(34), 0, GFLAGS),
<DC-IRC> [Discord] <boogieboogieboogie> it is muxed under this, so max cru can do is 500mh
<DC-IRC> [Discord] <boogieboogieboogie> it is muxed under this, so max cru can do is 500mhz
<DC-IRC> [Discord] <kwiboo> yes, something like that, from your https://github.com/hbiyik/linux/commit/4ad98e85e0793b52d0549ebd1af08f10f4f52ecb I can see that your bus clock was referencing the scmi clock, if you change the core clock to scmi clock the devfreq should work
<DC-IRC> [Discord] <boogieboogieboogie> no it does not in bsp, that was the issue
<DC-IRC> [Discord] <boogieboogieboogie> my guess is rockchip clock driver is doing funny when the clock is scmi
<DC-IRC> [Discord] <boogieboogieboogie> i tried that
<DC-IRC> [Discord] <kwiboo> strange, but I do not know much about bsp, I typically only run bsp kernel by accident if a board came with an image preloaded in emmc before I have had a chance to wipe the emmc 😉
<DC-IRC> [Discord] <boogieboogieboogie> would also do the same if theere was a proper rkvdec in mainline
<DC-IRC> [Discord] <kwiboo> hehe :D, at least my very old h264 high10 for rkvdec1 series seem to make some progress, hoping the final few patches will land in time for 6.16
<DC-IRC> [Discord] <boogieboogieboogie> i am doing 4k hdr with vp9 with my wonky rk3528 mutant board
<DC-IRC> [Discord] <kwiboo> nice 🙂
<DC-IRC> [Discord] <boogieboogieboogie> also i have a very big question mark on trusting scmi clocks, as the times pass, those oscillator circuits dont provide the frequency, but tfa still report as it was set. Practically the chip degrades itself silently without a notice
<DC-IRC> [Discord] <boogieboogieboogie> it is just repoting what was set. to me totally scam
<DC-IRC> [Discord] <boogieboogieboogie> lol it even has a comment stating that 🙂
<DC-IRC> [Discord] <boogieboogieboogie> i just noticed
<DC-IRC> [Discord] <kwiboo> hehe, yeah, it probably reports the requested freq so the logic in kernel can work, e.g. the expected voltage can be configured to have somewhat close to the requested freq, based on trim/pvtm etc
<DC-IRC> [Discord] <boogieboogieboogie> i was torturing my rk3528 board for fun, i was using the cpu at 2ghz 2 months ago
<DC-IRC> [Discord] <boogieboogieboogie> today it still reports 2ghz, but when i actually measure it is running max 1.1Ghz
<DC-IRC> [Discord] <boogieboogieboogie> thats not silicon degradation, thats just wrong
<DC-IRC> [Discord] <kwiboo> I guess that with use of the pvtpll's at least the board should be more stable, regardless of quality of silicon, instead of having some unstable boards they are now instead running slower
<DC-IRC> [Discord] <boogieboogieboogie> this is marketing story, or they just slow down the soc, to compansate bad silicon or to sell mote
<DC-IRC> [Discord] <boogieboogieboogie> this is marketing story, or they just slow down the soc, to compansate bad silicon or to sell more
<DC-IRC> [Discord] <boogieboogieboogie> for some cores there is no way to tell if it is degraded or not without hooking a freq analyzer..
<DC-IRC> [Discord] <boogieboogieboogie> for cpu it is somehow easy to detect by instruction counting
<DC-IRC> [Discord] <dams0869> Hi, I have these messages appearing by the thousands in `dmesg`, does this impact performance in your opinion ? (rock5b mainline kernel)
<DC-IRC> [Discord] <boogieboogieboogie> nope drm planes having fun, it is harmless unless you see some visual malfunction
<DC-IRC> [Discord] <mecoblock> h264 high10 as in 10bit h264? The "most" cursed encoding option 😂
<DC-IRC> [Discord] <kwiboo> Yep, original v1 was sent in 2020, collabora is now helping getting it upstream, v9 will hopefully be merged soon: https://lore.kernel.org/linux-media/20250417-b4-rkvdec_h264_high10_and_422_support-v9-0-0e8738ccb46b@collabora.com/
<DC-IRC> [Discord] <mecoblock> Did you work on it for a specific usecase? 10bit H264 is always a headache if you ask me (afaik it is more like a hacky implementation than a real standard right?)
<DC-IRC> [Discord] <kwiboo> hi10 and 422 are valid h264 profiles, no real personal use-case, it was just next logical step for rkvdec driver, introduce basics for 10-bit formats handling, before adding hevc format support (that also included 10-bit format use)
<DC-IRC> [Discord] <kwiboo> a v2 of rkvdec1 hevc https://lore.kernel.org/linux-media/20231105233630.3927502-1-jonas@kwiboo.se/ can be sent after the h264 hi10 parts has been merged, slow progress 😄
<DC-IRC> [Discord] <mecoblock> https://github.com/armbian/linux-rockchip/pull/353 armbian for full rk3588 performance 💪