16:07 <diederik> TFW after almost a year old patch set, now in version 9, the question arises: "How are these compiled? I don't see any makefile references" *facepalm*

16:23 <qschulz> Kwiboo: I think sjg1's point is that he's not changing the current behavior for external TPL, so there's no need for him to fix this in that patch

17:25 <Kwiboo> qschulz: sure, but if you add a helper, claim it to do one thing, and it does that thing wrong, I think it should be fixed, regardless of current behavior

22:19 <naoki> Kwiboo: led default-state = "on" is for u-boot? I was thinking to add it to all radxa boards

22:33 <Kwiboo> naoki: if I remember correctly that should be the default, but u-boot only act if the property is defined, u-boot should possible be fixed, for now I just add it to have the led turn on in u-boot

22:36 <naoki> since power led is always on regardless of software state, I'm thinking to tell "u-boot is running but kernel is not running"

22:39 <naoki> hmm, in u-boot, very few deconfig enable CONFIG_LED_GPIO ;)

22:41 <naoki> probably I will make patches for adding default-state to dts in linux and CONFIG_LED_GPIO in u-boot for Radxa boards

22:41 <Kwiboo> yeah, I know, I did not enable it on earlier board, have started to do it on newer boards I can test, have not gotten back to try and enable on boards with a gpio-leds compatible

22:41 <Kwiboo> please do :-)

22:42 <naoki> (I need to ask radxa people to change LED behavior)

22:44 <naoki> btw there is no ethernet for generic rk35xx in u-boot, ethernet(phy reset) doesn't work well on linux, right?

22:50 <diederik> I have to verify whether it's still the case with master/2024.07-rc5, but I had massive packet loss on Q64-A and -B since (u-boot) commit 25f56459aebced8e4bb7d01061dcb1b765b197e2

22:56 <naoki> I mainly use ROCK 5B for my work, but sometimes I use 5A/3A too. I didn't notice packet loss but I'll test it

22:56 <naoki> btw cpufreq for rk3588 is landed on linux-next, cpu is extremely hot ;)

22:57 <naoki> (and cpu freq is down to 1.2GHz lol)

22:59 <diederik> it could be specific to Q64-A and -B

23:10 <Kwiboo> diederik: I really need to start using my boards ;-), hoping to circle back to your issue in near future, at the moment my focus has mainly shifted back on linux media and completing rkvdec high10 and hevc support

23:13 <diederik> Kwiboo: Keep focussing on that :-D

23:14 <diederik> I hope to test your 4k patch set soon (tm) (Already compiled a kernel with it)

23:14 <Kwiboo> need to send out an RFC to linux-iommu list on how to best handle that rkvdec reset and disable the iommu after decoding fails, something along the lines of https://github.com/Kwiboo/linux-rockchip/compare/6da640232631...bf332524d880 seem to help re-enable the mmu

23:16 <diederik> Kwiboo: is it ok if I send you privately a RFC patch set (it's small)?

23:17 <Kwiboo> diederik: sure, I may not have any time too look too close until later this weekend

23:17 <diederik> That's ok, thanks :)

23:30 <naoki> diederik: at least there is no problem with iperf3 on ROCK 5A/3A

23:30 <naoki> (btw my ROCK 3A doesn't detect microSD card... maybe my 3A is broken...?)

23:32 <diederik> nice :) IME there was no need to do a test with iperf3, just ping made it really obvious (usually between 30 and 80% packet loss, so you can't miss that)

23:32 <naoki> diederik: ah, tested with u-boot v2024.07-rc5 and linux-next 20240625

23:33 <naoki> ping on u-boot works too

23:33 <diederik> I still need to do it, but it was present since (IIRC) 2023.10 and my last test was with 2024.04