12:49 <krzk> konradybcio: lumag: any idea how to debug cdba being quiet on my own setup? Logs shown only: cdba-server[9330]: user cdba opening board e850-1

12:50 <strongtz[m]> Could someone from qcom(?) take a look at this ufsphy driver patch? Or am I supposed to resend it?

12:50 <strongtz[m]> https://patchwork.kernel.org/project/linux-arm-msm/patch/20250613-sc7280-ufsphy-g4-fix-v1-1-1bf60744f5ac@radxa.com/

12:51 <krzk> konradybcio: lumag: ~1 year ago worked... I updated cdba client and server to latest, adjusted .cdba config, validate does not pass because of fastboot ID length, but I assume the cdba would print some failure here

12:51 <krzk> if fastboot was the issue

12:52 <krzk> konradybcio: lumag: I really wished cdba was more verbose :/

12:54 <krzk> I see the code just does strdup on fastboot config value, so I assume that longer than 8 should not be a problem (i'll send a pull req to fix schema for that)

13:44 <krzk> I think device does not come on fastboot by default, so maybe something is incomplete in config

13:44 <krzk> Last time was 1 or 2 years ago...

14:01 <krzk> ehhh, I have my answer... this stupid e850 board has pin 6 on LS connector routed to RST, not volume up which would be a fastboot enter, so basically qcomlt debug board cannot force it to entire fastboot.

14:02 <krzk> Damn, what Samsung/Winlink crap

15:21 <konradybcio> krzk maybe if you erase boot it'll go into fastboot on its own

20:43 <lumag> konradybcio, z3ntu: bug report for 8974:

20:43 <lumag> [ 10.140049] ocmem fdd00000.sram: error -ENOENT: Unable to get core clock

20:43 <lumag> [ 10.140119] ocmem fdd00000.sram: probe with driver ocmem failed with error -2

20:43 <lumag> I'm going to send a patch for interconnects, but I'm not sure what should be the fix for ocmem

20:43 <konradybcio> ah, good we broke gpu anyway /s

20:44 <lumag> also, modem crashes constantly (apq8074)

20:46 <lumag> konradybcio: yep...

20:46 <lumag> I'll afk for a week, then I might have time for the IOMMU...

21:00 <lumag> z3ntu: and modem crashes even without your patches (yes, I changed it to load mba.b00 locally)

21:04 <konradybcio> I'd happily say goodbye to 8974 8994 8996 and their direct derivatives but guess it'll be another 5-10 years..

21:04 <konradybcio> These platforms have a loot of quirks :/

21:05 <konradybcio> well, happily is not exactly what i meant.. rather, it'd make things easier

22:18 <lumag> konradybcio: hei, don't touch 8996!

22:43 <lumag> robclark: and 8974 is not completely broken. The driver needs to allocate DMA buffer for DSI commands, but now it crashes without VM

22:43 <lumag> s/not/now/

22:46 <robclark> yeah, iommu support is now a hard(er) req, it was kinda hard to avoid

22:47 <robclark> a bit sad, but time to get iommu working (and have a gpu) or write off some of these older platforms

22:50 <robclark> (and I don't like writing off older platforms as much as downstream/closed stack does.. but we have a big backlog and need to pick our battles so to speak)

22:52 <robclark> "well, happily is not exactly what i meant.. rather, it'd make things easier" -> yeah, exactly

22:53 <lumag> robclark: then we need to drop all 'falling back to contig buffer' messages.

22:54 <robclark> I won't claim I didn't miss some.. there is a lot of old things not in CI or not easily accessible to me to test

22:55 <robclark> but yeah, iommu is required now.. AFAIU it is only a few older platforms impacted

22:55 <robclark> patches welcome