04:03 <steev> damn this disappearing seccomp

07:31 <martiert> I think I see why I can't mount my installer disk on booting it now. The kernel logs out: `qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb0-sbu-mux`, and the same with usb1-sbu-mux. Is this something people have seen before?

09:35 <jhovold> martiert: those device link errors are a known issue but should not prevent you from using usb

11:27 <martiert> damn, I was hoping those were the answer :P Guess I'll just have to dig more then

13:13 <juergh> bluerise: I suspect your upgrade pulled in a new linux-firmware from the archive which doesn't have the a690 firmware. I'm in the process of updating the package in the x13s PPA.

13:16 <juergh> Ugh. alsa-ucm-conf also upgrades and looses the x13s patches. But I haven't gotten audio to work on Ubuntu yet anyways so not a big loss...

13:30 <ndec> juergh: do you still have the 'long delay' in the installer? Do you know what the problem is, and is it something we can help with?

13:32 <juergh> ndec: It might be the installer trying to reach the internet and eventually timing out. But I haven't really looked into it.

13:34 <ndec> ok, i haven't tried the installer image yet.. i still want to do that at some point. are you planning to build more images?

13:37 <juergh> I think so but am unsure about the timing. We're all a bit in a crunch atm with the Lunar release right around the corner.

13:38 <ndec> ok!

15:25 <steev> juergh: that shouldn't be too long though, upstream accepted the x13s patches

15:25 <steev> for alsa-ucm-conf i mean

16:01 <juergh> steev: ah cool.

16:04 <juergh> I still need to figure out why alsa doesn't see any device on ubuntu though

16:05 <danielt> juergh: I'd love to hear if you figure out what brings it to life (I'm not seeing in my Debian system either).

16:05 <juergh> bluerise: Packages in the PPA are updated and I just upgraded Ubuntu on my x13s and it's still functional.

16:27 <steev> juergh: https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/commit/65b44204ea88105ed77cc68224fae440d475acca is needed for both mics, but otherwise, audio *should* work, unless there's something missing in the kernel config

16:30 <steev> on top of what is in alsa-ucm-conf upstream that is

16:49 <steev> and if you're feeling froggish, you could also try the 2 newest commits from https://git.linaro.org/people/srinivas.kandagatla/alsa-ucm-conf.git/log/?h=x13s which set default volumes

17:18 <bluerise> juergh: thanks! I'll run an upgrade and see what happens :)

18:35 <clover[m]> Steev are you still getting demon voice on mic?

18:35 <steev> i haven't tried recently, so maybe?

20:13 <steev> srinik: on the c630, i'm not getting audio, and we get a bunch of multimediaX -22's; https://paste.debian.net/hidden/3a25c211/

20:13 <steev> this is with today's next

20:16 <steev> the branch i'm using is https://github.com/steev/linux/tree/c630-next-20230330 with http://sprunge.us/kYYp4U as my kernel config

20:21 <steev> i think it might be related to the patchset that adds all the missing multimedias so maybe it's just some ucm stuff needed?

21:21 <bluerise> juergh: worked for me :)

21:53 <bluerise> there's still no one working on the windows dev kit with device trees, right?

22:16 <steev> not yet that i've seen

22:17 <bluerise> also hard to work on when the ACPI tables are bad and there's no other info available *shrug*

22:18 <steev> you could try asking microsoft politely for the schematics?

22:21 <bluerise> Are they known to share?

22:22 <qzed> doubtful, but if you can find some contact and get somewhere, feel free to let me know, would be quite useful for some of the surface stuff as well xD

22:23 <bluerise> :D

22:24 <bluerise> don't worry, we'll spend a year one a machine to make it work halfway, and then a new version shows up. in perpetuity.

22:26 <qzed> yeah... I still believe that it might be easier in the long run to implement PEP support and deal with that ACPI stuff than having to write DTs for every model...

22:26 <qzed> but then again that is a ton of work and you'd need all the clock and regulator stuff anyway because their bloody ACPI doesn't do that

22:27 <qzed> also is this just qualcomm or does every ARM SoC manufacturer do this?

22:27 <bluerise> someone told me the windows drivers ship the actual acpi tables and they have an ACPI parser... so it's essentially ACPI overlays

22:29 <qzed> so from what I understand you essentially have some tables in ACPI that tell which devices need which regulators/clocks, then the PEP driver parses that and injects PM methods for the ACPI devices (or more directly in the windows PM API) and handles the PM stuff when anything requests it

22:29 <qzed> and besides all that there's still a ton of stuff like hardware addresses hard-coded in some drivers...

22:30 <bluerise> I was actually surprised when NXP released edk2 with ACPI to run windows on the i.MX8MQ

22:31 <qzed> (e.g. search for G0MD in https://raw.githubusercontent.com/linux-surface/acpidumps/master/surface_pro_x_sq2/dsdt.dsl, which seems to show the resources/states for the GPU, or part of it)

22:31 <bluerise> ah yeah

22:32 <qzed> I wanted to look into this at some point and maybe try to get some prototype working... but no time at the moment

22:33 <qzed> and as I've said, even when that would work, tons of drivers need changes or some hard-coded addresses... which means you'd have to adjust drivers for each SoC generation and probably write half a DT again...

22:34 <bluerise> Guess I'm in my ARM midlife crisis now. Sounds like too much work ;)

22:34 <bluerise> the MNT Pocket Reform tempts me

22:34 <bluerise> I just hope I'll get the CM4 adapter soon so that I can use the RK356x instead of an i.MX8M*