01:03 <robclark> flowriser: if you can ssh to it and get dmesg, CONFIG_DEBUG_DRIVER can sometimes help give an idea why something fails to probe.. you might be able to comment out backlight in dtb (and just rely on fw leaving backlight in a reasonable state), but missing a panel driver would defn cause display driver to not probe

03:36 <bamse> flowriser: the cpufreq complaint about the optional "lmh interrupts" are silenced in v5.17-rc1

03:37 <bamse> flowriser: as an intermediate step for seeing how things are behaving, i would recommend that you generate your own dtb with the mdss node status = "disabled";

03:37 <bamse> flowriser: that will (should) keep you on the efifb

03:37 <bamse> flowriser: ohh and you must boot with clk_ignore_unused and pd_ignore_unused on the commandline

03:55 <steev> i should give 5.17-rc1 a try

04:01 <robclark> rc1 seems to work ok with no issues on lazor.. kinda nice to see rc1 working for a change

04:04 <steev> ah, i still have all my external stuff on top, i should strip it all out and see how rc1 goes

05:13 <WoC> Any suggestions as to a suitable aarch64 laptop for someone who is mainly looking into using it for OpenCL on the GPU ?

05:14 <HdkR> Apple M1 in MacOS supports OpenCL

05:16 <WoC> Right, but replacing MacOS might be quite a challange

05:17 <HdkR> Getting OpenCL on another AArch64 laptop is also quite a challenge

05:17 <WoC> Although I do realize that OpenCL is (tm) Apple

05:17 <WoC> Indeed

05:17 <robclark> clover should work on qcom things... although there certainly is some room for optimizing some things that show up more frequently in cl but not gl

05:18 <WoC> In my case, I do prioritize OpenCL over OpenGL

05:18 <HdkR> robclark: Is clover in a state that is usable? Doesn't blender still completely break under it?

05:19 <WoC> However, given the age of the BSD is MacOS, hopefully I won't have to resort to that

05:20 <robclark> haven't tried blender.. clover in general works, but not really to the level of perf/compliance as gl.. so ymmv ;-)

05:20 <WoC> clover is only useful on a small number of devices and the quality is proportional to how recently the device was released

05:22 <HdkR> robclark: So really the only production quality AArch64 *laptop* with OpenCL is Apple things. Otherwise you're stuck with Android OpenCL stacks :P

05:22 <WoC> which is vendor provided...

05:23 <steev> HdkR: i mean, if you're saying *production* quality, sure

05:23 <HdkR> Personally I wouldn't throw a user at non-production code :D

05:24 <WoC> In other words, never use anything made by amd

05:24 <steev> robclark: speaking of... how do i enable clover?

05:24 <steev> WoC: well that outs qualcomm since adreno = radeon :P

05:25 <WoC> oh, that would explain i could never ger OpenCL working on my phone

05:26 <HdkR> Android phones also have their own quirks there. Like all Pixel phones not shipping OpenCL binaries, and a lot of random vendors also not doing so.

05:26 <HdkR> Also you need to watch out for embedded profile versus full

05:26 <WoC> While AMD has great hardware, they never had any functional software outside windows

05:26 <robclark> steev: https://paste.centos.org/view/da4b4ae9 .. but maybe you want `--buildtype release` instead

05:28 <WoC> afaik only Samsung ships OpenCL runtimes with their phones, even if it's limited to crippleware

05:56 <steev> robclark: ta, it's building now that i'm not an idiot and actually installed libclang-dev. their error messages are... not very conducive to figuring out the missing package

06:17 <steev> HdkR: i'm 1000% no blender expert... barely even a beginner (literally just installed it); it's.... running? i can do video editing with it, at least

06:18 <steev> but it might be doing opengl not opencl there?

06:19 <HdkR> steev: Go to Edit->Preferences->System->Cycles Render Devices->OpenCL

06:19 <HdkR> It should say "No compatible GPUs found for path tracing"

06:20 <HdkR> The viewport you see by default is OpenGL based. It's the Cycles Renderer that will fallback to the CPU path

06:20 <steev> ah, right

06:20 <steev> yeah, that happens

06:21 <steev> the blender output does say that there's no verison info available in libOpenCL.so.1

06:22 <steev> strings /usr/local/lib/aarch64-linux-gnu/libOpenCL.so.1 | grep 22.0.0

06:22 <steev> 22.0.0-devel

06:22 <steev> Mesa 22.0.0-devel (git-2002e87cc3)

06:22 <steev> i blame blender?

06:23 <WoC> Which version of Blender ?

06:23 <WoC> Be aware, you no longer has OpenCL in Blender 3.

06:23 <WoC> 3.x

06:24 <steev> oh, yeah, just saw that in the bug :)

06:24 <steev> https://developer.blender.org/T73734 at the bottom :)

06:25 <WoC> Right, drop AMD, get a real NV

06:25 <WoC> CUDA ftw

06:26 <WoC> It's not likely AMD will ever fix anything ever, unless they are actually forced to

06:59 <steev> kinda hard to "drop" it when it's built in to the cpu

07:13 <WoC> Good thing that you can add a real gpu

07:14 <WoC> Maybe not be as fast as on ThunderBolt, but still do-able

07:14 <WoC> Unless it's some AMD/ATI "GPU"

07:48 <steev> bamse: 5.17-rc1 on the c630, https://paste.debian.net/1228182/ line 82, havent seen that one before

08:06 <flowriser> bamse, I will kiss you right now. Booting with clk_ignore_unused and pd_ignore and disabling mdss node kept me on efifb

08:13 <flowriser> leaving mdss enabled and booting with clk_ignore and pd_ignore on keeps me on efifb as well

08:20 <flowriser> bamse, turns out only clk_ignore is needed for me to stay in efifb

12:34 <flowriser> Making some headway here, now I think I have a missing kernel module cause I get: "RTNETLINK1 answers: No such file or directory" then I get "acpid: error talking to the kernel via netlink" when booting via a dt

17:39 <bamse> steev: me neither, that seems to be a new one

17:39 <bamse> flowriser: allow me to decline that kiss, but i'm happy to see that you're up and running :)

17:41 <bamse> flowriser: i made an attempt at starting to solve the clk_ignore_unused issues, but it (running without clk_ignore_unused) is simply broken by design and needs to be replaced with something new and clever, but all efforts of coming up with a generic solution for that has failed to far

17:57 <steev> bamse: ah, is that what is going on with the cache rcg?

18:18 <flowriser> What is Qualcomm FGBCL? Why the hell is everything so obscure with qualcomm

18:41 <steev> power management

18:44 <steev> i'm assuming it's FG BCL

18:45 <flowriser> BCL = battery charge level, but what does FG stand for? :D

18:47 <flowriser> I am going manually through the acpi dump files and annotating everything in order to find where the hid over i2c keyboard is hiding

18:47 <steev> front gate?

18:48 <steev> i'm just randomly guessing as well :)

18:52 <flowriser> Also what I noticed is that the dsl file contains spiX, uartX, i2cX on the same registers/interrupts (under qupv3), does this mean one can arbitrarily choose either one of them? What would happen if you enabled both uart and i2c on the same reg/intrerupts?

18:55 <bamse> steev: nah, it's related but there was another patch for that

18:56 <bamse> steev: many of our rcgs can be controlled by both hardware and software, and as such we can't actually query their current state reliably

18:57 <bamse> steev: as such, we can't implement is_enabled() and hence when clk_disable_unused() kicks in we don't know if the rcg is on or off, but in the current implementation we'll happily turn off the parent clock

18:57 <bamse> steev: which locks up the rcg

18:57 <steev> ah, right

18:58 <bamse> flowriser: i don't know if bcl standard for battery charge level somewhere, but i think it's typically something like "battery current limit"

18:59 <bamse> flowriser: it's a hardware block in the pmic that measures current, battery level (and temperature?) and if levels exceeds some configured thresholds it will signal the OSM in the SoC about that

18:59 <bamse> flowriser: the OSM being the hardware behind the qcom-cpufreq-hw driver

19:00 <bamse> flowriser: that way cpu frequency is automatically limited based on e.g. how much current the pmic is allowed to pull from the battery

19:01 <bamse> flowriser: and the cpufreq irqs that you mentioned the other day, that's the OSM (or LMH) notifying you about such an event

19:04 <flowriser> bamse, thanks so much for the explanations! Definitely puts some context around how everything works together