00:52 <jenneron[m]> bamse: does glink need anything in userspace? I can't get display to work with these modules included in initramfs

00:52 <jenneron[m]> also, display doesn't work if I place adsp firmware, but it's probably another problem

01:04 <jenneron[m]> dmesg using glink in initramfs https://dpaste.com/DH8Y4HN6Q

01:50 <harvestz[m]> Does anyone know what optional extensions Snapdragon 8cx Gen 3 Compute Platform has? Or better yet, where to find detailed documentation?

02:26 <harvestz[m]> ^^ just made a Qualcomm account and didn't find it there but did find: https://developer.arm.com/documentation/101433/r1p2/Functional-description/Introduction/Supported-standards-and-specifications?lang=en

02:26 <harvestz[m]> Arm® Cortex-X1 Core Technical Reference Manual

02:47 <HdkR> If you're looking for CPU extensions then yes that is what you're looking for

02:56 <HdkR> It's basically ARMv8.2 plus a smattering of random things

03:10 <harvestz[m]> Awesome, first time trying real development on a cpu that has more than 35 instructions haha. I do however stare at arm disassembly for work often

03:17 <steev> jenneron[m]: you need the pd-mapper service at a minimum

03:19 <steev> jenneron[m]: also see https://github.com/steev/linux/commit/ac42c7b4372621b1c5f2b438850a871a027dd11e for jhovold's take on getting display working in initramfs

03:38 <bamse> jenneron[m]: nah, edp doesn't depend on anything...to get the plug detct to work for external display you need the pd-mapper userspace tool though

03:39 <bamse> jenneron[m]: but you need a ton of modules in your ramdisk...so to debug think i typically comment out the schedule_delayed_work() in regulator_init_complete() and just rely on efifb

03:39 <bamse> jenneron[m]: the regulator thing makes it so that the backlight regulator doesn't turn off after 30 seconds...

03:40 <bamse> and yes, this could be improved :)

03:53 <jenneron[m]> bamse: my installation reaches rootfs in less than 30 seconds and it doesn't work

03:53 <jenneron[m]> can be related to this error https://dpaste.com/DH8Y4HN6Q#line-420

03:57 <bamse> that's certainly a possibility...and it should most definitely not do that

04:04 <bamse> it's however not obvious which mutex_lock() call that is...

04:05 <bamse> ahh, yes it is...lr is _devm_...release_client()

04:06 <bamse> hmm...i'll take another look tomorrow morning

04:06 <bamse> jenneron[m]: thanks for the report

04:27 <steev> i should check on the status of things on the flex5g these days

06:20 <harvestz[m]> I'm getting about 10% of the download speed using Linaro's debian install guide, rip. My upload speed is what I get on other devices on my network though

06:20 <steev> yeah, i am really hoping the wifi crew comes through soon

14:22 <alfredo> Hi,

14:22 <alfredo> sorry to bother you, but I think you may be able to help me. Specifically, I already asked about kernel support for the snapdragon 8cx gen 1 aka SC8180x and gen 2 aka SC8180xp SoC on the debian arm mailing list and they told me to contact the kernel maintainer https://lists.debian.org/debian-arm/2023/01/msg00031.html.

14:22 <alfredo> From what I understand it seems that SC8180x is supported while I can't find anything on SC8180xp (maybe they are the same SoC except for the CPU frequency).

14:22 <alfredo> They and I are trying to figure out why there is no device tree for both SC8180x and SC8180xp.

14:23 <alfredo> I am no expert, but in /boot/config-* in the binary package of the debian linux kernel image there is:

14:23 <alfredo> # CONFIG_PINCTRL_SC8180X is not set.

14:23 <alfredo> # CONFIG_PINCTRL_SC8280XP is not set

14:23 <alfredo> # CONFIG_INTERCONNECT_QCOM_SC8180X is not set

14:23 <alfredo> # CONFIG_INTERCONNECT_QCOM_SC8280XP is not set

14:23 <alfredo> Whereas in this commit https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/?id=d1d48fd18abcec95383b54bbb4530367f2168f4f and in this https://lore.kernel.org/linux-arm-kernel/20220916124214.3881948-1-vkoul@kernel.org/ are enabled.

14:23 <alfredo> Thank you for your time.

15:44 <steev> alfredo: it's not just a matter of adding in a "sc8180x" dts file - each individual device needs their own dts file; that said, the sc8180x in particular, does not yet have full support in the upstream kernel, no. the way it usually works is that you need the underlying drivers in since it doesn't all go in via one tree, so that's why 8180X pinctrl/interconnect are there already, but there's still more out of tree/in flight/in flux

15:56 <alfredo> Thank you for your reply. Do you know if anyone is working on drivers for sc8180x or sc8180xp? Unfortunately I am not a kernel developer and don't know if I can help in any way.

15:57 <steev> well, the surfacec pro x is/has an sc8180x model, so it is, some of the work is being done there; but that's not going to be a 1:1 translation to the ideapad 5g

15:58 <steev> harvestz[m]: try doing audio testing when getting youtube videos at 10K/s

15:59 <steev> it sucks, then it becomes, is the issue the audio driver, or because youtube hasn't given me enough to buffer yet

16:12 <ardb> steev: qzed shawnguo: with the EFI fixes currently in -next, resetsystem should no longer crash

16:13 <ardb> hopefully, this means that it will automatically fall back to PSCI reboot/powerdown

16:13 <jenneron[m]> steev: isn't surface pro x sc8180xp?

16:13 <jenneron[m]> like 8cx gen 2

16:19 <steev> jenneron[m]: maybe? i'm not sure, i have the flex5g myself which is just 8180x

16:19 <jhovold> ardb: is that with the fixes in your urgent branch?

16:20 <ardb> jhovold: yes

16:20 <ardb> i haven't tested but the resetsystem call should be caught by the exception handling code and return an error

16:22 <jhovold> which commit would that be? I can give it a spin here with two sc8280xp machines that crash when attempting to reset through efi.

16:22 <ardb> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8a9a1a18731eb123e35f48176380a18b9782845e

16:24 <jhovold> thanks, testing now

16:25 <alfredo> Yes, surface pro x has sc8180xp which is an overclocked version of 8180x of flex5g.

16:25 <jenneron[m]> sc8180xp is also 8cx gen 2

16:27 <jhovold> ardb: still broken with this Qualcomm firmware I'm afraid

16:27 <ardb> jhovold: so the crash is not being handled?

16:28 <jhovold> the machine appears to hang for a while, before we get a dump from the hypervisor

16:28 <jhovold> we're not falling back to psci

16:28 <ardb> do you see the line emitted by 'pr_err(FW_BUG "Unable to handle %s in EFI runtime service\n", msg);'?

16:29 <jhovold> no, the last line is:

16:29 <jhovold> [ 75.752903] reboot: Restarting system

16:30 <ardb> ok let me experiment a bit locally to see why it is not being caught

16:32 <ardb> jhovold: but does the crash look different from usual?

16:33 <jhovold> I don't think so. It's been this way since I got the machine, reboot/reset did not work and I had to clear the reset-service bit to get it to fall back to psci

16:34 <jhovold> ardb: note that I only cherry-picked the commit you linked to above

16:35 <ardb> jhovold: ok

16:36 <ardb> so it doesn't actually crash, it just hangs in the firmware until the hypervisor takes over?

16:36 <jhovold> yeah, that's what it looks like

16:36 <ardb> ugh ok, then this change is not going to help, unfortunately

16:38 <jhovold> recent x13s firmware has got all the service mask bits cleared, so it's no longer an issue there

16:39 <ardb> ok

16:39 <ardb> still disappointing

16:39 <jhovold> I still need that hack for the reference design, and for anyone like me who hasn't updated the fw on x13s yet

16:40 <ardb> are you using the DtbLoader?

16:40 <jhovold> yeah, i got my hopes up there for a while :)

16:41 <jhovold> no, grub is loading the dtb here

16:41 <ardb> ah ok

16:55 <bamse> jenneron[m]: realized today that the crash you saw in pmic_glink was reported and it's been corrected in the version i posted last week

17:01 <qzed> ardb: so I think the crash is being caught on my SPX, at least there's nothing on the TTY and it seems to shut down alright

17:02 <qzed> that's with today's -next

17:02 <ardb> qzed: that is a change from before?

17:03 <qzed> yeah, before I'd get a crash like in the image here: https://github.com/linux-surface/surface-pro-x/issues/41#issuecomment-1384552391

17:03 <ardb> ah right - yes that was what I was expecting

17:03 <ardb> good to know

17:04 <bamse> alfredo: it's been a while since i tested sc8180x, but there are dts patches in flight and with that used the lenovo flex 5g as my daily dev machine all the way until the x13s got good enough

17:04 <ardb> apparently ResetSystem is broken in various ways :-(

17:24 <alfredo> bamse: this is a good news. I hope to see that patches on the mainline kernel soon :)

17:28 <bamse> alfredo: looking at my last sc8180x tree, i have a bunch of things that has landed, the dts files, support for battery and external displays, some defconfig updates and 2 hacks

17:28 <bamse> alfredo: i think one of the hacks has been properly implemented upstream, and the other one should be fairly straight forward

17:41 <qzed> ardb: I've masked out the fallback do_kernel_restart() to keep the log on the screen (i.e. force the "reboot failed" message) and this is what I get now: https://github.com/linux-surface/surface-pro-x/issues/41#issuecomment-1400728977

17:42 <ardb> ok that looks as expected

17:42 <ardb> and the fallback does work, right?

17:43 <qzed> yes

17:43 <ardb> excellent

17:43 <qzed> so I assume we're not going to try and load in the missing page?

17:43 <ardb> nope that seems like a lot of work for little gain

17:44 <qzed> okay

17:48 <alfredo> bamse: thank you very much for your efforts. I hope to be able to use my device with GNU/linux as soon as possible :)

17:49 <steev> someone will still need to write a dts for that device

17:50 <bamse> that is indeed true, steev

17:54 <alfredo> steev: I am currently no longer a C/C++ developer, but have been in the past. I'm not sure it's within my grasp, I never dealt with the kernel.

17:59 <steev> you're in good company :)

18:00 <gwolf> alfredo: FWIW you are the person who was asking about the Ideapad 5G in debian-arm, right?

18:00 <gwolf> I won't direct you to this IRC channel then 😉

18:09 <jenneron[m]> bamse: can you send the link to that last version?

18:09 <jenneron[m]> is it for sc8180x? I might miss that

18:10 <steev> it's for all https://lore.kernel.org/all/20230113041132.4189268-2-quic_bjorande@quicinc.com/

18:10 <jenneron[m]> oh I see

18:10 <steev> well, all that use glink

18:10 <steev> the c630 wouldn't use it

18:10 <jenneron[m]> I thought it's in guthub tree

18:10 <jenneron[m]> github*

18:11 <steev> i don't think i've pushed the v2 yet (but i DID do -l this time so it includes the links now when i do stuff)

18:11 <jenneron[m]> do you also have tree for flex 5g?

18:11 <steev> yeah but it's really old

18:11 <jenneron[m]> I see

18:12 <steev> The spx stuff is likely the newest things

18:13 <steev> But I haven’t checked

18:40 <alfredo> gwolf: right

18:41 <gwolf> Well, this is the best place to get that kind of help. Welcome :-]

18:41 <alfredo> gwolf: thank you