01:00 <aceridus> Just wanted to pop in and see if anyone knows more about whether or not there is ongoing effort to get Linux running on Snapdragon 7c Gen 2, specifically the Galaxy Book Go. I see a couple of issues on the official aarch64-laptops GitHub about keyboard/mouse not working or the installer image missing the requisite DTB files, but no mention of a verified resolution. I am curious if there is still active development being done for 7c Gen2?

01:03 <jenneron[m]> iirc the last one who tried to port it just bought a chromebook instead

01:07 <aceridus> Hmm, not a good sign. I have one in front of me and would love to get Linux up and going on it. I am plenty comfortable with Linux and building things, including kernels, from source. However, it gets above my understanding at about the kernel driver level and connecting/defining the hardware via DT.

01:17 <robclark> chromebooks will defn be the easiest option as far as upstream kernel since, other than mipi camera, everything should already work upstream (including needed dt).. I guess 7c windows laptops shouldn't be *too* hard to get running but there is a shortage of folks working on dt vs the # of laptops currently.. at least all the driver enablement is in place for 7c things (all the gens)

01:20 <jenneron[m]> well, galaxy book go should not be that hard, keyboard and touchpad are hid over i2c, camera should be on usb

01:20 <jenneron[m]> i've looked at its dsdt when i was choosing a laptop to replace my galaxy book s

01:21 <jenneron[m]> (most likely the replacement won't be galaxy book go though, there are sdm850 laptops for the same price)

01:26 <jenneron[m]> there is a concerning thing about galaxy book go, its eDP bridge, i'm not sure there is driver in mainlne, i haven't looked into that

01:40 <aceridus> I am going to give it my best effort if for no other reason than to just challenge myself so I can learn a bit. If anyone more knowledgeable on the driver/dst front is willing to help me our or give some guidance it would be much appreciated!

01:42 <aceridus> Before I get into changing things with a Linux installer any idea what is the best way to grab a backup of the internal storage just in case? I guess if the installer iso boots I could dd an image?

01:42 <jenneron[m]> aceridus: copy-paste chromebook dts and edit it according to your dsdt

01:42 <jenneron[m]> especially make sure regulators are correct

01:43 <jenneron[m]> https://raw.githubusercontent.com/aarch64-laptops/build/1019f47e48a54f3f1ca075c3dc67e81471e3806b/misc/samsung-galaxy-book-go/acpi/dsdt.dsl

01:45 <robclark> jenneron[m]: there are a limited # of different dsi->eDP bridges.. I think most of the windows things (like c630) used the ti bridge, at some point due to supply chain chromebooks switched to parade bridge.. I guess the 7c windows laptops _probably_ use one of those two as well

01:45 <robclark> both are supported upstream

01:46 <jenneron[m]> that's good for someone trying to port it

01:49 <aceridus> Ok, let me see if I can make sense of that. I am not very good with device tree in general since most of my development experience is in user land. I have been poking my head further into it though in recent years. I just don't grok the design of DST files as it related to hardware. I have some limited exposure to PCB design and layout at my current job, but I am not a hardware guy! When you say make sure regulators are correct how do you su

02:37 <jenneron[m]> aceridus: read the table which 've sent

02:37 <jenneron[m]> there are pieces of code like https://dpaste.com/BUVM73KJF

02:37 <jenneron[m]> this means that 0x002D2A80 is a hex value of voltage of ldo19a regulator

02:38 <jenneron[m]> make sure your dts regulators match DSDT before testing kernel

02:39 <jenneron[m]> also, not that there may be several such fragments for same regulator, in this case there are voltage constraints for it

02:39 <jenneron[m]> note*

02:52 <aceridus> Ok, I see what you are saying in regards to that small chunk. Getting all of them verified/mapped over to dts will be quite a larger task (I am guessing) due to where they need to be placed in the DTS hierarchy?

02:53 <aceridus> Anyhow, I am still trying to find a starting place which currently involves using v0.4 of the aarch64-laptops/debian-cdimage iso. It boots and I see the main installer screen, but the keyboard & mouse don't work. I can see that the installer kernel is a few years old at this point and there appears to be a lot more upstreamed sc7180 dts bits on mainline, so I feel like trying to get an iso with a newer kernel might be a help?

02:54 <jenneron[m]> no

02:54 <jenneron[m]> there is no dts for galaxy book go, so no updates for it

02:54 <jenneron[m]> still, use the latest version of kernel

02:55 <jenneron[m]> speaking of "where they need to be placed in the DTS", as i've already said, copy-paste some chromebook dts and modify it

02:55 <jenneron[m]> rename the copy to sc7180-samsung-galaxy-book-go.dts i guess

02:57 <aceridus> Yea, I am willing to try iterating on it that way once I get a Linux environment to test the dts changes. Is doing an install via the iso the right way to get said environment?

02:59 <jenneron[m]> use any arm64 rootfs

02:59 <jenneron[m]> I don't use those installers

03:01 <aceridus> Good idea.

03:24 <bamse> steev: just noticed that i forgot my flex 5g running...it's now reached 50 days...on wifi

03:24 <steev> oh wow

03:25 <steev> i think mine is 50 days powered off :'(

03:30 <bamse> i've been using it on and off...but it's probably 2 weeks since last time

04:45 <steev> i'm still using your old next branch because i was having issues with newer but i don't recall what

04:53 <steev> woo, 6.1 rc1

04:53 <steev> good times to be had

05:30 <steev> or not... i have no idea what i did on the thinkpad

17:23 <clover[m]> borked?

17:48 <steev> yeah, not sure what i'm missing, pcie isn't coming up

17:48 <steev> probably something applied in -next but not in 6.1

18:25 <clover[m]> is this why linus got mad at devs for pushing stuff last minute? lol

18:26 <broonie> Well, the merge window closed now - open season for applying everything people were working on in the past 2+ weeks.

18:32 <amstan> \o/

18:35 <ardb> steev: were you seeing suspend/resume issues with 6.0.1 as well on c630?

18:35 <ardb> in my case, magic SysRq notably still works so i could sync, unmount and reset

18:36 <steev> ardb: i didn't actually test 6.0.1; but the 6.0.2 issue was due to the revert in dwc3

18:36 <ardb> which is not in 6.0.1?

18:36 <steev> it is not

18:36 <ardb> right so separate issue then

18:37 <ardb> it only happened once so far

18:38 <steev> admittedly i'm using a not quite vanilla 6.0.2; but you probably want to grab https://lore.kernel.org/all/20221017233510.53336-1-andriy.shevchenko@linux.intel.com/ if you don't have it

19:08 <ardb> steev: do i only need that patch if i have the external DP patches applied?

19:08 <ardb> those didn't work for me btw but i didn't spend any time trying to figure out why

19:19 <ardb> or might it be the reason i had problems? i don't remember now what the issue was to begin with :-(

19:21 <ardb> no i tried with 6.0.0 so that can't be it

20:07 <steev> no; my experience is that the dp portion of the patches is what breaks suspend

20:07 <steev> so personally i have that part reverted

20:08 <steev> oh, wait, actually i reverted my hack

20:08 <steev> i haven't attempted to suspend *after* using dp though

20:09 <clover[m]> That breaks on thinkpad

20:12 <steev> oh

20:13 <steev> i think i reverted the hack trying to get the usb bit working, not realizing it was the revert in 6.0.2 and not mine that broke things

20:17 <ardb> clear as mud :-)

20:26 <steev> yep :)

20:27 <steev> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.0.y&id=53c2e5d5b5ca92b06c02b5461f555181d56484be was the commit that broke things for me with 6.0.2 - Andy sent a fixed patch as well that i linked above, that basically undoes the revert, cuz i guess revert: revert: is frowned upon?

20:44 <aceridus> Ok, so I have a home made bootable USB for my galaxy book go using a 6.1.0-rc1 kernel. It drops to an initramfs shell where the keyboard and USB ports are non-functional, so an external keyboard isn't an option yet. I have yet to provide a dtb to the kernel via GRUB and this is likely to be the hardest leap for me to make...

20:45 <clover[m]> Nice

20:45 <aceridus> Is it safe for me to create a new sc7180-samsung-galaxy-book-go.dts and only include the base arch/arm64/boot/dts/qcom/sc7180.dtsi in it? Or are there any risks to the hardware from say voltage regulators getting initialized incorrectly?

20:46 <aceridus> I am very much not a device tree guy, I am flying quite blind through this entire process!

20:48 <robclark> I'd guess your not likely to break anything... no guarantees but if boards were that easy to burn up we'd have a lot more smoldering piles of former-board laying around here ;-)

20:48 <robclark> but, if you haven't already, I'd probably try to make sure ACPI boot works first

20:51 <aceridus> Any tips on how to do that? I certainly have no problem trying to figure that out, but the first major barrier is no keyboard which makes it hard to look around and troubleshoot

20:52 <robclark> if you don't load a dtb then it should acpi boot

20:53 <robclark> in _theory_ efifb should keep display going, at least until smmu driver probes

20:54 <ardb> you can use earlycon=efifb to get console output really early

20:54 <ardb> and don't forget efi=novamap

20:54 <aceridus> Which is the current boot mode because I have yet to provide a dtb. The problem is the keyboard and mouse don't work. As discussed in an aarch64-laptops issue already I had to set CONFIG_ARM_SMMU=n to avoid getting a black screen and then a reboot

20:55 <aceridus> ardb: I have both of those set already

20:55 <ardb> ok

20:55 <robclark> looks like there are only a couple acpi-id's listed in arm-smmu-qcom.c so hopefully it is same id on 7c and you automatically get the special handling for smmu driver not to trash the smmu context that efifb is already using

21:04 <aceridus> Yea, based on https://github.com/aarch64-laptops/debian-cdimage/issues/21 it seems like the smmu might be getting trashed somehow, but I don't really understand anything about these things. It is hard to see errors too because the screen goes black when smmu support is enabled.

21:14 <robclark> not sure if you can get usb-eth dongle working (assuming usb isn't completely dead)... but as far as smmu, my first guess is we need a new entry in the table here: https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c#L445

21:21 <aceridus> As far as I can tell the USB is completely non-functional. I tried a logitech wireless keyboard with a USB adapter both via the type-a port and the type-c port with a c-to-a adapter. No luck on any of the available USB ports. I can try a wired keyboard just to be extra sure.

21:22 <aceridus> I can try adding a new entry to that table, but where do I look for the correct values to populate it with?

21:30 <aceridus> Someone already extracted a dsdt.dsl for the machine in the past, I am going to try a new table entry with values from there.

21:52 <aceridus> Adding another entry didn't work, although I suspect it wasn't necessary because I can see a brief flash of arm-smmu messages before the screen goes black. So, it seems like it is already trying to use ACPI when it explodes

21:56 <aceridus> I am trying to figure a way to more easily see the messages so I can try to isolate what the smmu driver doesn't like. As mentioned before, and as suggested in the bug, disabling the SMMU prevents the black screen and reboot, but results in a booted system without a functioning keyboard. So, the smmu driver is the likely culprit, just can't seem the error messages for long enough to know why

21:57 <steev> it's silly, but it works....

21:57 <steev> i record it with video and then play back in slow mo

21:57 <robclark> I guess the names should show up in the dumped ACPI tables..

21:57 <robclark> AFAIU lack of entry in that table won't stop arm smmu from trying to probe, it just means that arm-smmu will break the display in the process ;-)

21:58 <robclark> looks like shawnguo added the existing arm-smmu-qcom entries, maybe he remembers how to find them

22:33 <aceridus> robclark: Looks like you are correct, a few added debug messages and a video capture show me that the driver did not find a match in the qcom_acpi_platlist table, but despite that it kept on going and might be playing with memory that leads to the crash and reboot

22:54 <aceridus> Ok, I added a correct table entry to qcom_acpi_platlist and now the machine boots all the way and drops me into an (initramfs) shell even with the SMMU config flags enabled. So, some progress, but the keyboard still doesn't work and the ramdisk can't find the root filesystem on the USB stick. Wired USB keyboard also doesn't work.

23:26 <robclark> I won't claim to know much about usb, but does lsusb show anything? I guess there is probably a hub external to the SoC (assuming that laptop has more than a single usb connector)

23:31 <aceridus> Trust me, I would love to see what lsusb has to say, but as of yet I can't get a working keyboard to issue any commands.

23:44 <aceridus> I just re-built the kernel based on the laptops_defconfig from the aarch64-laptops/linux repo and still no keyboard. I am seeing a message "platform arm-smmu.0.auto: deferred probe pending", so although not crashing it seems the smmu isn't configuring fully?

23:45 <jenneron[m]> aceridus: I would just write a DT instead of fixing it

23:49 <aceridus> Yea, I am not sure how to approach that though because DT largely doesn't make sense to me. I don't understand the DTS syntax fully nor how it really corresponds to HW devices, hierarchy, etc. I can copy paste another one, but it doesn't help me when things aren't working because I don't know how to troubleshoot it. It is a bit like playing whack-a-mole in the dark...

23:51 <jenneron[m]> maybe start with empty dtb, efifb should work with that

23:52 <jenneron[m]> then copy-paste PMIC nodes with regulators and adjust them according to your DSDT

23:52 <jenneron[m]> also, when using DT with efifb, add `clk_ignore_unused pd_ignore_unused` to cmdline

23:52 <aceridus> Is there a way to know I have the nodes defined correctly?

23:53 <jenneron[m]> for syntax stuff you will have errors while compilation

23:55 <aceridus> Would it be a good starting place to create a new dts and have it include only the base sc7180.dtsi that all the chromebooks use?

23:55 <jenneron[m]> yeah, this one should boot into efifb at least

23:55 <jenneron[m]> with that cmdline

23:56 <aceridus> Should I set CONFIG_ACPI=n in the kernel config, sounds like I won't need it at all?

23:56 <jenneron[m]> it should work without this change