00:01 <leland[m]> <abby> "probably something to ask the..." <- Read through the error log, reflashed my USB drive and it's working! Feels like a big upgrade

09:27 <JensGlathe[m]> wow a million temperature sensors on x1e

12:13 <\[m]> so super well done thermal management as a consequence?

12:23 <JensGlathe[m]> no idea yet

13:20 <hexdump0815> JensGlathe[m]: one for each transistor on the chip :) ... i think on apple silicon it is similar and they had/have problems to find the relevant ones among them ...

13:22 <hexdump0815> JensGlathe[m]: they = asahi project

13:34 <JosDehaes[m]> hexdump0815: yes, me too, as I worked on btop++ for macOS 😅

14:47 <JensGlathe[m]> Has anybody looked into the fdts in the adsp and cdsp .elf files? Lots of pinctrl, charger and battery definitions as dt - probably also by model?

14:58 <Jasper[m]> Well, they also run Linux

15:07 <JensGlathe[m]> looks like it

15:07 <JensGlathe[m]> its Linux all the way down

15:10 <travmurav[m]> ugh

15:10 <travmurav[m]> if you mean hexagons then there is no chance they run linux

15:10 <JensGlathe[m]> I mean hexagons

15:11 <Jasper[m]> travmurav[m]: Oh, thought they did

15:11 <travmurav[m]> iirc it's the qcom specific (rtos/etc) firmware as usual but I think they wanted to change how the firmware is built and move oem configs outside of the code, so they use (oem signed) fdt

15:11 <travmurav[m]> Jasper: where did you see qcom willing to share any source code around hexagon os :P

15:11 <travmurav[m]> they just use the fdt format afaik

15:12 <Jasper[m]> travmurav[m]: ... oh, yeah that makes sense

15:12 <Jasper[m]> They did have some code somewhere to run it on there no?

15:12 <travmurav[m]> it's a company that created a dedicated subsidiary just so that it can touch GPL code outside of the main one

15:13 <travmurav[m]> there is sdk for hexagon userspace apps afaik

15:13 <travmurav[m]> so fastcv stuff etc

15:17 <jannau> `z

15:35 <freekurt[m]> <JensGlathe[m]> "no problem. There's always hubs,..." <- What is the name of this Display? It sounds cool.

16:21 <JensGlathe[m]> iiyama ProLite XUB2792QSN-B5

16:41 <JensGlathe[m]> Beware, one detail (but acceptable imo): The hub data over the same cable is one aux line, resulting in USB2 speed for KB / mouse / ethernet (but each direction) / whatever you connect over the hub USB connectors. It's the same on Windows, and it looks like a common limitation when using DP altmode. Theoretically it would be doable to wire for 2 lines dp / 2 lines USB-3, but the software doesn't seem to know how - and it could

16:41 <JensGlathe[m]> even be that the same issue persists in the display hub itself, both sides need to wire their repeaters/muxes this way.

16:41 <JensGlathe[m]> I guess I tested this mux thing on a PC, and it was USB2 regardless

17:11 <JensGlathe[m]> battmgr is up

17:12 <JensGlathe[m]> qcom_q6v5_pas is loading these odd .elf files

17:52 <jhovold> Here's an updated wip branch for the X13s:

17:52 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.11

17:52 <jhovold> Changes include:

17:53 <jhovold> - fix usb phy runtime suspend null derefs

17:53 <jhovold> - fix serial receiver enable race

17:53 <jhovold> Here's an updated wip branch for x1e80100:

17:53 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.11

17:53 <jhovold> Changes include:

17:53 <jhovold> - fix pcie phy clocks

17:53 <jhovold> - fix usb phy runtime suspend null derefs

17:53 <jhovold> - fix serial receiver enable race

17:53 <jhovold> Known issues:

17:53 <jhovold> - usb-c dp altmode is quite broken

18:13 <steev> blergh

18:14 <steev> https://patchwork.kernel.org/project/linux-wireless/list/?series=890077 at least they *seem* to be working on monitor mode for ath11k - definitely doesn't work here. i just get -95 trying to add a monitor device

18:29 <JensGlathe[m]> that msdu_done thing?

18:37 <steev> no, it's for monitor mode

18:38 <steev> jhovold: should something change with the "fix serial receiver enable race"? because since switching... i just get timeouts here

18:39 <steev> https://www.irccloud.com/pastebin/RiZzjrP6/

18:43 <steev> and hciconfig -a shows the 00:00:00:00:5A:AD address

18:48 <steev> hm, actually let me try backing out bartosz pwrseq stuff

18:52 <steev> nope, it's not the pwrseq

19:14 <jhovold> steev: thanks for testing, I'll try to take closer look tomorrow before heading to vienna

19:16 <jhovold> everything seems to work on the x13s, but I only tested the dma paths lightly

19:17 <jhovold> if you have the time perhaps, you can try backing out those serial patches one at a time and see which one is the likely cultprit

19:19 <jhovold> ok, I can reproduce it here as well, sorry about the breakage

19:31 <steev> it's all good :)

19:31 <steev> gives me something to do in between reading about linux capabilities (and my inability to find things about inheritance)

19:52 <Earth2> hello

20:39 <abelvesa> jhovold: I've just tested your branch on my t14s and I can get pretty stable "usb-c dp altmode" (dp-only)

20:39 <abelvesa> jhovold: I even have 2 1080p monitors connected at the same time

20:41 <abelvesa> jhovold: yes, the link training failures are still there, but those are dp driver related, not altmode, AFAIU

20:45 <abelvesa> jhovold: TBH, my test setup is gnome with X

20:46 <abelvesa> jhovold: switching to wayland seems to break the second monitor, but the other one still works

20:59 <abelvesa> jhovold: anyway, will test on CRD as well tomorrow

23:34 <agl> steev: Do you generate a x13s kernel of 6.11? Or can I use 6.11 from the kernel.org web site?

23:35 <steev> i'm waiting for v2 of some patches in johan's tree that aren't quite right before releasing a 6.11

23:35 <agl> ok