02:22 <leezu> hexdump0815, javierm: confirmed that clk_ignore_unused=1 works around the error. I opened https://gitlab.freedesktop.org/drm/msm/-/issues/22 to document the issue and will contact Abhinav to make him aware of the issue.

02:23 <mothenjoyer69> HdkR: "Ah, good to know. I thought it was ready and I knew someone today just had their laptop turn off :D" did you/the person you know end up having the same display failures as Jenneron?

02:25 <leezu> hexdump0815: I had to replace `cp -v vmlinux.kpart-initrd-${kver} vmlinux.kpart-initrd-${kver}.old` with `mv -v vmlinux.kpart-initrd-${kver} vmlinux.kpart-initrd-${kver}.old` in my kernel-and-initrd.sh, otherwise the new initrd with updated kernel commandline wouldn't overwrite the old.

02:36 <HdkR> mothenjoyer69: Nah, that was battery charging problems.

02:41 <leezu> With the clk_ignore_unused workaround, the next issue on 6.1-rc4 is that wifi fails to initialize. On 5.19, the driver prints "ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000" and a few more lines before successfully making the chip available for connection to a network, but on 6.1-rc4 there's no such output and the chip never get's

02:41 <leezu> initialized. Is this a known issue? dmesg at https://gitlab.freedesktop.org/drm/msm/uploads/84c5d5f7dc0334e0a37823a45934a6a0/dmesg-clk_ignore_unused.txt

02:49 <mothenjoyer69> <HdkR> "mothenjoyer69: Nah, that was..." <- I know, sorry I more meant as an unrelated question; trying to find out if the screen failure was specific to Jenneron, or at least that presentation :)

04:12 <robclark> leezu: jfwiw, abhinav__ is in #freedreno and #dri-devel

06:11 <swgws> so, adding the sc8280xp to the qualcomm smmu platform list gets me past the bootloop behavior from before, but now attempting to boot in ACPI mode causes rcu_preempt detected stalls on CPUs/tasks after "arm-smmu-v3 arm-smmu-v3.2.auto option mask 0x0"

06:12 <swgws> and, building a base DTB off the sc8280xp.dtsi still causes the bootloop, even though i _think_ it should have the smmu described properly

07:29 <javierm> leezu: I believe there was already a bug filed there, he is definitely aware of the issue and said that their clock team was looking at it

09:23 <swgws> I rebuilt kernel with ARM_SMMU_QCOM_DEBUG=y to try and get more info and now call trace on rcu stack dump is ending in "acpi_idle_driver+0x0/0x440"

18:33 <aceridus> swgws: I am struggling through a similar process as you with the Galaxy Book Go (sc7180). I am still not entirely clear on whether or not I should focus on the ACPI path vs the DTS path for hardware bring up. I have a functioning kernel with keyboard, usb-a and microSD working, but when it comes to the more challenging items (e.g. trackpad,wifi, etc) I am so far stumped

18:35 <aceridus> swgws: I have a 2023 dev kit on order also, should arrive next Tuesday, so maybe we can end up figuring our way through a few things just bouncing ideas off each other.

18:37 <aceridus> For the record, I would like to hear a few expert, or at least more informed, opinions on whether or not the correct approach on these devices really is DTS files or if we should be improving the ACPI approach. I just don't know where to ask or receive input on the point

18:37 <HdkR> You want to focus on DT because otherwise you'll never get a GPU.

18:38 <aceridus> HdkR: Ok, good to know. Why is that specifically?

18:38 <qzed> I wouldn't say never... but it'd be a LOT of work

18:38 <HdkR> Dunno, people seem to hate ACPI

18:38 <qzed> for ACPI, you'll need to first add support for PEPs to the ACPI kernel framework stuff

18:39 <qzed> then you'll need to implement a PEP driver for your specific SOC

18:39 <aceridus> I got a similar sense from reading various threads

18:39 <qzed> then you'll need to adapt all drivers to also allow ACPI next to DT/OF

18:39 <HdkR> There's also a bunch of inflight work for SC8280XP, so if you're not getting it to come up without GPU then you might need to poke around for steev's active branch or something.

18:40 <aceridus> qzed: What is a PEP? Also, there is no way that will happen by me cause I am hardly a kernel developer, but know enough to realize that is all but impossible without access to proper schematics and specs, right? And we can't get those, right?

18:40 <robclark> qzed: random idea.. since we anyways need a PEP for ACPI boot, why not just have a PEP with an embedded dtb :-P

18:40 <qzed> thb... people may hate on ACPI, but in the long run it's the only viable way, since I don't see MS adapting DTs and I don't see many vendors doing the extra work and provide a DT just in case you want to install linux

18:40 <robclark> PEP == Platform Extension Plugin

18:40 <robclark> it is basically a "SoC driver"

18:41 <robclark> which knows how to map device power states to clk/interconnect/gdsc settings

18:41 <qzed> robclark: hmm, fun thought but I'm not sure if it's necessary to encode a full DT in that

18:41 <qzed> at least in the qcom ACPI tables there seems to be some descriptions as to what needs to be turned on for what device in what power state

18:42 <aceridus> But even going the ACPI route, adding PEPs and drivers isn't going to be possible unless qcom and/or microsoft provide access to schematics and tech docs, right?

18:42 <robclark> I guess DT is a combination of SoC and board details.. so maybe a PEP should only have details to describe the SoC

18:43 <qzed> yeah, ideally you have one PEP for the SoC, but I think in practice you'll need to support having more than one PEP

18:43 <qzed> the SPX seems to use an extra PEP just for PCIe

18:43 <qzed> so I'm not sure if that is then device specific (because there seem to be multiple ways the PCIe lanes can be configured)

18:45 <qzed> I think most of the device specific stuff should be covered in ACPI though (at least for qcom devices)

18:46 <qzed> see https://raw.githubusercontent.com/linux-surface/acpidumps/master/surface_pro_x_sq2/dsdt.dsl G0MD

18:48 <aceridus> So, I still want to move the galaxy book go forward more at some point. I am hoping to get the WiFi working next, but pulling DT nodes from sc7180-trogdor.dtsi isn't enough by itself. It seems from looking at the relevant Windows driver that there is one or more .mbn files that I am guessing need to be loaded for the WiFi to work, but I don't see the Linux side driver wanting or trying to load any firmware files. Am I missing something?

18:49 <qzed> the mbn are usually remoteproc firmware, I think

18:50 <qzed> and for wifi there's a wifi remoteproc that you need to set up and feed with the firmware

18:51 <qzed> mpss, I think

18:52 <aceridus> I see, it seems odd that the WiFi driver just fails silently about these things. It sure would be nice if it complained in a meaningful way about these missing dependencies...

18:56 <aceridus> I have mpss_mem and wlan_mem reservations in my DT, but I don't know if they are at the correct location nor if they are the correct size. Is there a way for me to figure that out from Windows? I pulled them from sc7180-trogdor.dtsi which is for Chromebooks, so I presume they might be incorrect

18:56 <broonie> aceridus: If the driver isn't binding there's likely to be information in the deferred probe stuff saying why.

18:57 <broonie> People get irritated with deferred probe errors so they're not terribly visible by default, but it does cause problems with things silently failing unless you know to go look (dunno if that's what's happening here though)

18:58 <qzed> aceridus: Windows registry has some entries for regions, also windows device manager can show a couple of those in its memory map

18:59 <qzed> see also my notes at https://github.com/linux-surface/kernel/blob/spx/v6.0/arch/arm64/boot/dts/qcom/sc8180x-surface-pro-x.dts#L63-L143

19:00 <aceridus> broonie: Thanks for the tip, where can I find the deferred probe errors? I am currently only seeing aa00000.video-codec in /sys/kernel/debug/devices_deferred, so nothing WiFi related

19:00 <broonie> It'd be in there if it was deferred.

19:00 <broonie> I forget where the logs go.

19:02 <aceridus> qzed: Thanks, but I don't see in your comments where in the registry you found the region definitions?

19:03 <qzed> I have no idea any more, sorry. You could search for the MPSS

19:03 <qzed> let me actually try to find those again... I think those were all under the PIL somewhere

19:04 <qzed> (PIL is the firmware image loader)

19:05 <aceridus> qzed: Is that short for Platform Image Loader or something like that?

19:05 <qzed> I think Peripheral Image loader

19:06 <aceridus> Is that a new component of Windows for arm64 or does it also exist in the x86 world?

19:06 <qzed> it's a qualcomm specific driver

19:07 <aceridus> I see, it is starting to make a little more sense now.

19:11 <qzed> you can also look in Windows/System32/DriverStore/FileRepository

19:11 <qzed> there search for "pilext"

19:12 <qzed> also "subextmpss"

19:13 <aceridus> I recall seeing items named that in the driver store. I guess the driver inf files are what create the entries in the registry containing the region information?

19:13 <qzed> correct

19:13 <qzed> in the driver inf files it's just split out over multiple

19:14 <qzed> found it in the registry

19:14 <qzed> search for "MemoryAlignment"

19:15 <qzed> you should then find some path like QCOMxxxx/<...>/DeviceParameters/SubsystemLoad"

19:15 <qzed> all the nodes below that are descriptors for memory regions

19:16 <qzed> specifically their requirements, some may be fixed, some may have only an alignment requirement

19:16 <qzed> + size (reservation)

19:16 <qzed> mpss is in MODEM, at least on the SPX

19:17 <aceridus> broonie: I only see a couple WiFi related message in dmesg: https://dpaste.com/CA954GSY9. No interfaces show up though, so I don't really know where to look now to figure out what those drivers need. I am only guessing it is the memory regions and .mbn firmware that qzed is helping me figure out right now

19:18 <qzed> you also need to boot up the remoteprocs and set a bunch of things up via user-space services

19:18 <qzed> in case you're not aware of that

19:18 <aceridus> qzed: I remember reading previous discussions about these points. I guess the driver is allowed to move the non-fixed ones around as long as the size and alignment constraints are met?

19:18 <qzed> aceridus: as far as I understand, yes

19:20 <aceridus> qzed: Ok, the user space stuff shouldn't be necessary until I can see an interface under /sys/class/net/ though, right?

19:20 <qzed> hmm I think you'll need that for that to show up

19:20 <qzed> you can maybe use https://github.com/linux-surface/surface-pro-x/wiki/WiFi as a start

19:20 <qzed> although you may need different jsn files for pd-mapper

19:21 <qzed> you'll have to check the service outputs with regards to what fails

19:22 <aceridus> Ok, that link helps a lot. No way I would have figured that all out by myself, haha

19:22 <qzed> yeah, it's a bit of a journey to get wifi working

19:24 <qzed> I'm assuming that it's one of those SoC-type wifi things, right? not that it's some PCIe card and I'm completely sending you off in the wrong direction

19:25 <aceridus> It is the sc7180 based Galaxy Book Go, so yes, I am guessing the WiFi is provided by the qcom modem layers?

19:26 <qzed> I'd assume so, that seems to be standard. It's just because the thinkpad x13s had wifi via some PCIe card

19:27 <swgws> given acpi status, I'm guessing shifting to trying to fix the DT files is probably more productive - anyone have resources on how I can try and fix the smmu descriptor in the DT / determine why the machine isn't picking it up?

19:41 <aceridus> swgws: What version of the kernel are you trying to boot? What about the DTB file you are loading, you said you built a base one from sc8280xp.dtsi?

19:47 <swgws> I'm on qzed's spx branch of 6.0 - I've tried using the thinkpad-x13s dts and a base one from sc8280xp.dtsi, but I just get here and reboot in both cases - https://user-images.githubusercontent.com/2041026/200714923-db4f830c-b612-4f6e-8596-ac822a544eef.png

19:48 <aceridus> I only experienced boot looping on the galaxy book go when I tried to boot in ACPI mode. I don't recall ever having boot loops when booting with a DTB, so maybe you aren't getting the DTB loaded correctly at boot?

19:49 <aceridus> Can you share your GRUB config?

19:49 <swgws> sure, one sec

19:51 <qzed> swgws: you might also want to have a look at what steev is cooking up in his sc8280xp branches: https://github.com/steev/linux

19:52 <steev> disclaimer: most of that is not my work, i just have various hacks

19:52 <steev> on top of the proper work

19:54 <steev> the lenovo-x13s branches are probably more complete as well, the ones that start with sc8280xp are typically based on -next, versus the lenovo... ones being based on torvalds/stable

20:00 <swgws> Here's my grub config - https://pastebin.com/b44PUCS7

20:01 <swgws> another thing to point out I guess - unless I set console=efifb I get no output after bootconsole disabled

20:02 <swgws> I _believe_ the dtb is getting loaded correctly, it seems to correctly initialize a bunch of thermal sensors and PCI (I get a bunch of errors in ACPI mode that aren't present) - but the SMMU in particular isn't working

20:05 <aceridus> Yea, your grub config looks fine to me

20:10 <swgws> steev: do you have the acpi dump files from the lenovo thinkpad x13s somewhere? I want to compare with mine and see if I can find something

20:11 <steev> you know, i don't think we do

20:11 <steev> clover[m]: did you happen to dump them and put them in your repo that you were doing info collectings?

20:12 <clover[m]> Yep they are in the wiki

20:16 <steev> linky for swgws

20:30 <aceridus> qzed: I found the memory regions in the registry. Where is the memory map information in the device manager?

20:36 <qzed> aceridus: view -> resources by type, then under memory in the tree/pane

20:38 <aceridus> qzed: Brilliant! How have I not known about this for all these years...lol

20:39 <qzed> unfortunately a bunch of things don't show up there

20:39 <qzed> I think it's only what's explicitly specified in ACPI

20:42 <hexdump0815> leezu: did you have to add clk_ignore_unused directly to the kernel config to make it work or was it the mv vs. cp when building the kernel plus initrd kpart image which prevented the changed kernel cmdline args to work?

20:44 <hexdump0815> leezu: the mv vs. cp problem i do not really understand - for me it worked all the time with cp and looking at the script for me it should simply work properly with cp as well

20:45 <swgws> clover[m]: can I get a link to that wiki?

20:45 <clover[m]> sorry was on a walk in the park: https://github.com/ironrobin/archiso-x13s/wiki/ACPI-dump-from-Windows

20:48 <hexdump0815> aceridus: did you have a look at the aspire 1 dts from travmurav[m] ? (https://gitlab.com/TravMurav/pmaports/-/tree/aspire1/device/testing/linux-postmarketos-qcom-sc7180 - patch 5 there) - it might be quite an options to cross check against as it is a very far working sc7180 woa dts and mem regions might just be the same maybe?

20:49 <hexdump0815> swgws: do you have an acpi dump of the win dev kit online somewhere?

20:50 <qzed> hexdump0815: https://github.com/linux-surface/acpidumps/tree/master/windows_dev_kit_2023

20:50 <hexdump0815> qzed: oh - thanks

20:51 <swgws> beat me to the link :)

20:53 <aceridus> hexdump0815: Let me start referencing that also

20:57 <hexdump0815> aceridus: my assumption would be that the more soc generic stuff like wifi might be very similar across different sc7180 devices and some hardware further away like kbd, trackpad, display panel etc. might differ

21:03 <leezu> hexdump0815: I realize the mv vs cp was required as my /boot is too full. I will add a set -e to make the failure obvious

21:05 <leezu> I only verified the clk_ignore_unused worked when added directly to the kernel config. But likely my attempt with adding it to the standard cmdline args just failed as the new image wasn't written due to the lack of space

21:05 <hexdump0815> leezu: yes that little script is not very robust :)

21:09 <aceridus> I generally agree. It appears I have all of the same regulators and memory regions for the WiFi as compared to the aspire1 dts, so something else must be missing...

21:10 <hexdump0815> aceridus: btw. not sure if you saw this (i think you were offline at that time) - my failed try to get ufs (internal storage) working: https://oftc.irclog.whitequark.org/aarch64-laptops/2022-11-05#31594544

21:11 <aceridus> Maybe I need the remoteproc_mpss node for WiFi to work? Not sure, it feels like sheer luck to find these dependencies because whatever is there and working (or not) doesn't seem to emit any errors about missing deps...

21:12 <steev> ah right, i always forget clover=ironrobin

21:15 <clover[m]> clover is a pointer :P

21:22 <clover[m]> clover->ironrobin... and many other names