00:12 <steev> i haven't pushed a branch with the big performance increase just yet, so you might want to hold off

00:15 <steev> actually, i have pushed a branch, i just didn't push it to the one most people use

03:19 <clover[m]> Extremely secret branch of steev only accessible to the initiated

03:22 <steev> i announced it in here and people tested... just that SOME people insist on things being tagged

03:22 <HdkR> A branch name is already a tag

03:22 <HdkR> It's fine

03:23 <steev> it's also pretty apparent what it is because it has bwmon in the name

03:23 <steev> https://github.com/steev/linux/tree/lenovo-x13s-6.0-bwmon

03:24 <clover[m]> Lol

04:22 <steev> :)

04:23 <steev> for real though, the thinkpad x13s is my daily driver at this point, even without the gpu working

04:23 <steev> i only switch to the c630 when the battery dies on the thinkpad because it doesn't last near as long :'(

04:29 <HdkR> steev: I hear if you enable the GPU for compositing then battery life increases ;)

04:30 <steev> i've heard that too... sadly, i don't have the skillset to be able to

04:31 <bamse> steev: last night i unplugged the power cable to my desk due to the thunderstorm...the x13s was dead when i got back after 11 hours...the flex 5g had 68% left (both idling with lid open)

04:31 <steev> bamse: yep :(

04:31 <bamse> and we're still idling the x13s around 40C...

04:32 <bamse> gpu would help when running btm to look at the temperature though ;)

04:35 <steev> i'm probably not being very nice by always using alacritty and llvmpipe too

04:40 <bamse> right

04:40 <bamse> i feel the need for gpu support every time i ssh into my threadripper and builds the kernel...alacritty causes a significant load on the x13s when scrolling the build log :)

04:46 <steev> luckily, people smarter than me are working on it ;)

07:32 <hexdump0815> in case anyone else has a smasung galaxy book go around and want to help getting it forward here is a debian bookworm image, which should boot fine on it: https://github.com/hexdump0815/imagebuilder/releases/tag/221101-01

14:10 <dgilmore> I applied a couple of patches to https://github.com/aarch64-laptops/edk2 to get DtbLoader.efi built, however I am stuck with an error trying to build Shell.efi

16:51 <steev> dgilmore: :D

16:52 <steev> sadly, i haven't built them myself so i can't guide much, i think robclark might be interested in the dtbloader patches if they're required since he was the author, iirc

17:10 <dgilmore> o/ steev okay

17:11 <dgilmore> it may be that I am using gcc 12

17:22 <aceridus> hexdump0815: Thanks for posting the bookworm image, I am able to boot it just fine. I have pushed an update to enable the microSDHC card slot: https://github.com/amcduffee/linux/commit/88750d4ec3e0abff8b5670382148103ba78693e3. I poked around in the EFI shell and it doesn't look like the machine will support booting from SDHC, unfortunately.

17:28 <robclark> steev, dgilmore: actually Leif wrote it.. but yeah, it is probably edk2 vs new compiler, I guess

17:34 <bamse> there was a bunch of things that one had to fix to get it building with a new compiler, things that can all be cherry-picked from upstream edk2

17:37 <bamse> i don't know if one is supposed to rebase/merge this kind of projects?

17:48 <dgilmore> thanks robclark

17:49 <dgilmore> I decided it is time to get Fedora on my yoga c630, it is going to need to load the dtb

17:50 <steev> welcome to the future

19:36 <hexdump0815> aceridus: cool - i can confirm that the sd card works well for me too - just moved my system over to it :) (still booting from usb though)

19:37 <hexdump0815> i'm getting this one bootup which as it seems is related to it: https://pastebin.com/raw/j48Wd7S6

19:38 <hexdump0815> btw. i just noticed that we are getting cpu freq scaling and the soc thermal sensors already for free from sc7180.dtsi :)

19:41 <aceridus> I have seen that stack trace too

19:41 <hexdump0815> i also noticed that sc7180.dtsi does not seem to contain entries for ufs storage (7c chromebooks have emmc instead) but maybe the dtsi for the sm7125 (which seems to be close to sc7180) might give some inspiration: https://github.com/map220v/sm7125-mainline/blob/a72q-6.0/arch/arm64/boot/dts/qcom/sm7125.dtsi

19:42 <hexdump0815> maybe Leandro[m] has experience with that from the samsung a52/a72?

19:42 <aceridus> I have been pulling nodes from sc7180-trogdor.dtsi, which has worked well so far

19:43 <aceridus> I am tempted to try WiFi next, but it needs firmware, so I doubt it will be as simple as pulled DTS nodes over

19:44 <aceridus> Enough nodes have worked it might be interesting to see what works if my dts directly includes sc7180-trogdor.dtsi

19:45 <hexdump0815> another good inspiration might be the dts and maybe even the patches in https://gitlab.com/TravMurav/pmaports/-/tree/aspire1/device/testing/linux-postmarketos-qcom-sc7180

19:46 <hexdump0815> travmurav[m] has most stuff working on its aspire 1 - its definitely a different device, but maybe looking at it cannot be wrong

19:49 <hexdump0815> i assume that the simple stuff like sd card might transfer over quite well from trogdor as most vendors will just do it the default way, but things like real display support might need more experimentation

20:02 <aceridus> I will see how much I can decipher, but the harder items like GPU and/or WiFi that require firmware blobs and in-depth testing/troubleshooting are likely above my pay grade. Hopefully what I have done to get these devices to an operational state for on-device development will encourage some help from the big guns that know how to do that stuff.

20:06 <hexdump0815> maybe we can just copy some firmware files from windows - not sure if it might work for gpu and or wifi and or bt

20:07 <hexdump0815> qzed: i think you dealt a lot with this -right? not sure anymore, were you able to use some firmware directly from the windows filesystem or did you have to extract some out of the windows drivers? i think i remember something like the latter

20:09 <hexdump0815> aceridus: the acer aspire 1 dts references some firmware filenames - might be worth trying to search for them on the windows side maybe

20:10 <qzed> unfortunately I don't really remember where I got the wifi firmware from...

20:10 <qzed> but the GPU firmware is stored inside the dxk[whatever] driver

20:11 <hexdump0815> also in the github issue for the galaxy book go it was mentioned that ufs storage worked with acpi instead of dtb as described in the issue - this might be an idea to access/backup the windows filesystem

20:12 <qzed> at least the SQE and GMU firmwares... I think the zap shader thing is actually available in the file system somewhere

21:01 <robclark> for sqe and gmu fw, you should be able to use what is in linux-firmware.. only zap is signed and needs to come from windows partition

21:03 <qzed> right, you should be able to make it work with whatever is already upstream, getting the sqe and gmu from the driver directly is just a bonus I guess

21:21 <Leandro[m]> <hexdump0815> "maybe Leandro has experience..." <- Hey yea that's what we use

21:35 <Leandro[m]> I could check some stuff soon, what do you need?

22:17 <hexdump0815> Leandro[m]: i just wanted to know if ufs is working well on a52/72 - looks like yes ... and maybe: is sm7125 in the end the same silicon as sc7180 or are there real differences?

22:22 <steev> aceridus: assuming the wifi firmware is just ath10k, it MIGHT just work with the WCN3990 stuff in the firmware package(s) for your distro (or gotten from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/WCN3990/hw1.0 )

22:25 <steev> assuming you have the dts bits

22:48 <aceridus> steev: Let me give that a try

22:56 <aceridus> Anyone able to help me understand what the 'Bus arbitration lost, clock line undriveable' error means on the geni_i2c device for the keyboard? It happens, I think, while idle and spams syslog with messages, but doesn't cause the keyboard to stop working...

23:07 <aceridus> Ok, patching a I2C_HID_QUIRK_BAD_INPUT_SIZE quirk into the i2c-hid-core.c driver file gets rid of the flood of 'incomplete report' messages at boot. However, I do not know that this is the correct solution and I am not sure what to macro the VID/PID values to either if it were a correct solution... patch: https://dpaste.com/84BH7NV7E

23:09 <aceridus> It does not fix the keyboard spuriously generating characters and I am still waiting to see if the bus arbitration issue still exists (I expect it does). So, I feel like the real problem is something else being misconfigured via DT or ??? that is the real cause of all these symptoms