11:52 <Guest16> Hello!

11:52 <Guest16> I'm attempting to get cpufreq-dt up  and running on RK3566(Radxa Zero 3W) but cpufreq-dt defers due to CPU Clocks being unavailable.

11:52 <Guest16> https://bin.bloat.cat/?addb0ad540966ae0#F8op6PnfTJUCRUTpXPHgP3DKCM1DQ77ZwUwaMtk7MscE

11:52 <Guest16> I get this

11:52 <Guest16> ```

11:52 <Guest16> [    2.548026] scmi_protocol scmi_dev.1: Timeout waiting for a free TX channel !

11:52 <Guest16> ```

11:52 <Guest16> Im using Linux 6.12.35 and TF-A v2.12.

11:52 <Guest16> Is there any way i can debug the reason why SCMI TX fails? I've seen issues with SCMI on rkbin BL31/2 but I am using TF-A

11:52 <Guest16> Thanks!

11:57 <diederik> Do you have SCMI support enabled in your kernel?

12:06 <Guest16> diederik yeah. i have CONFIG_ARM_SCMI_PROTOCOL set to y

12:06 <robmur01> that's the kernel SCMI driver probing, so yes. Probably something off with the DT description or the firmware itself

12:07 <Guest16> hmm alright, although the scmi defns are from the mainline rk356x-base.dtsi so I wouldnt expect anything to be off

12:08 <robmur01> from the look of that function, it's waiting for firmware to write to shared memory, and not seeing it

12:09 <Guest16> ah interesting. could this need the iommu or something? apologies if i dont make much sense

12:09 <robmur01> so most likely either the DT and firmware disagree about the shmem location, or firmware's just broken

12:09 <diederik> If you grep your config for ARM_SCMI, what does it return?

12:10 <Guest16> https://bin.bloat.cat/?5c8826ee4f1fff8b#EmSsTM1CsWrCf5UFhgWvrpMhPfiT245EfeAB3NJYCJR1

12:10 <Guest16> would it be time to take a look at TF-A  and uboot?

12:12 <diederik> how could I forget ... TF-A may be the problem: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31265

12:13 <qschulz> CyReVolt: mmm somehow your multiline message appeared just fine (as multiple mesages), so I'm wondering what makes the matrix bridge use a link instead of posting the whole message on IRC?

12:14 <diederik> not sure if it's relevant, but I have CONFIG_ARM_SCMI_POWER_CONTROL also enabled (and IIO_SCMI and PINCTRL_SCMI)

12:15 <Guest16> diederik thanks! will take a look at that!

12:15 <Guest16> qschulz i honestly have no idea what you are talking about. sorry if i am not supposed to send multilines. i am not that brushed up with irc ettiquete

12:15 <robmur01> diederik: if it's failing to even get the version for the base protocol, it's not worth worrying about other protocols yet

12:16 <diederik> robmur01: yeah, makes sense. Thanks :)

12:16 <robmur01> the question at this point is "does this firmware even implement SCMI?"

12:16 <qschulz> Guest16: this was a message to CyReVolt about their message yesterday :)

12:18 <diederik> Guest16: ``dmesg | grep -i scmi`` on my Quartz64-A (rk3566): https://paste.debian.net/1389145/

12:18 <Guest16> qschulz oops!

12:19 <Guest16> diederik thanks! do you use TF-A and the patch?

12:20 <diederik> reasonably sure I'm not on that device (but use rkbin blob) ...

12:21 <Guest16> ahh you use the rkbin bl31/2? makes sense!

12:22 <diederik> But (a while ago) I did use/try it on my PineTab2 which is also rk3566: https://paste.sr.ht/~diederik/f04fd93b898db196019cfd4638ea1133a94b3967

12:24 <diederik> And 'TF-SCMI' is upstream TF-A + the patch I linked earlier

12:25 <Guest16> got it!

12:35 <Guest16> diederik thanks! cpufreq-dt works now!

12:37 <diederik> \o/

13:09 <Ermine> seems like this dmabuf-chache thing invented by rockchip is safe to turn off

16:17 <CyReVolt> sre: sorry, I cannot receive your IRC DM. If you're also on Matrix, or some other channel, please try that. =)

19:51 <warpme> detlevc: fyi: i got another 3576 device to play with vdpu383 (rock4d). And this device has symptoms like my first one (green lines on majority playbacks). By curiosity i tried video pipeline without dmabuf (ffmpeg out is mem copied to egl buf) and... all plays nicely. This tells me (so far) issue of "green lines" is maybe not of decoder issue but rather by dma transfers between decoder out and egl bufs? (or in this area)....

19:56 <warpme> more nad more i suspect i.e. memory timing issues impacting dma memory arbitration between multiple requestors (or something like this....)

19:57 <detlevc> warpme: I've also not discarded an issue on the display side or in between. It is still early days for some drivers

19:58 <detlevc> warpme memory timing seems unlikely, I'v been doing tests with gstreamer with 4k@60fp videos and all was smooth

20:02 <warpme> hmm - 4k@60 - i assume it was direct-to-plane (wasn't that decoded frame was on display plane mem so no any dma transfers?)