ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<aceridus> jenneron[m]: Hmmm, I already tried changing it to &i2c6 and it seemed to hang the boot without seeing any kernel messages. Let me try it again though.
<aceridus> jenneron[m]: Can you explain how you determined that? I would like to understand!
<jenneron[m]> dsdt https://dpaste.com/EV2N7KR2D
<jenneron[m]> aceridus: ^
<aceridus> jenneron[m]: Very nice, thanks! I see the correlation
<aceridus> A bit of forward progree, the i2c_hid layers are trying to reset the device: https://imgur.com/a/P4y5e2K
<aceridus> progress*
<jenneron[m]> aceridus: send dts
<jenneron[m]> current
<aceridus> jenneron[m]: https://dpaste.com/2U9V5XNKU
<jenneron[m]> looks good, idk
<jenneron[m]> maybe try without pin configuration, it should be set, but in this case keyboard interrupt should be configured on bootloader stage
<jenneron[m]> i also don't see any regulators supplied to this in dsdt, but i'm not that good at reading it
<jenneron[m]> but that's where i don't know what to do and guesses are starting
<jenneron[m]> anyway 400000 is the frequency set in ACPI
<jenneron[m]> so better add it
<aceridus> Major forward progress!! The pin configuration was the issue on the keyboard. I was in the middle of adding various dts USB blocks too in the off chance it might get the USB working. Almost couldn't believe my eyes when it booted *ALL* the way into a full Linux CLI from my USB drive, haha! https://imgur.com/a/ZoAmgem dts: https://dpaste.com/2YAP4FMK5
<jenneron[m]> i suppose keyboard works?
<aceridus> Yes! It spews a bunch of incomplete hid descriptor errors at startup until the first key is pressed. Working past that, amazing!
<jenneron[m]> ok, now touchpad
<jenneron[m]> it's on &i2c10
<jenneron[m]> interrupt is 0x180 (may mean something else) active low
<aceridus> Only the type-a USB works, but it is a start!
<jenneron[m]> reg is 0x40
<jenneron[m]> hid descriptor is 0x0e
<jenneron[m]> also, touchpad uses ldo10a regulator
<aceridus> I was just looking at that, let me add that in a moment. Not sure I can test it from a tty though?
<jenneron[m]> it also has 150ms delay
<jenneron[m]> aceridus: evtest utility
<aceridus> Ok, let me make sure that is in my rootfs
<jenneron[m]> aceridus: for touchpad you will need `vddl-supply = <&vreg_l10a_1p8>;` and `post-power-on-delay-ms = <150>;`
<aceridus> When you say &i2c10 is that the dsdt number or did you already convert for DT?
<jenneron[m]> DT
<aceridus> Also, is it frequency 400000 also?
<jenneron[m]> it's IC11 in ACPI, so i2c10
<jenneron[m]> frequency 400000 as well
<aceridus> I tried to do a graceful shutdown with 'poweroff' and it cause a stack trace, lol
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
derzahl has quit [Ping timeout: 480 seconds]
<aceridus> jenneron[m]: First attempt didn't work for touchpad https://dpaste.com/ALRHESSZC
<aceridus> 10-0040: supply vdd not found must be the reason
<jenneron[m]> other logs?
<jenneron[m]> maybe send a full dmesg
<jenneron[m]> but yeah vdd may be the reason
<jenneron[m]> besides what we've written in DT, ACPI also sets 31 GPIO to `Zero` state and 32 to `One`
<jenneron[m]> one of these may be vdd supply, one may be reset
<aceridus> You might be right because I changed vddl-supply to vdd-supply and now the message complains about not vddl supply found
<jenneron[m]> ldo10a is vddl one not vdd
<aceridus> Ok, so it definitely wants a vdd-supply then
<jenneron[m]> <aceridus> "10-0040: supply vdd not found..." <- this is not an error, this is a warning
<jenneron[m]> keyboard works without it
<jenneron[m]> send full dmesg and try to run i2cdetect and i2cdump
<jenneron[m]> if there is no i2c device, it's most likely a power issue
<aceridus> I do see i2c-6 and i2c-10 under /sys/class/i2c-dev
<jenneron[m]> yes, do that on 10 one
<aceridus> I will need to add those i2c command to my rootfs first
<jenneron[m]> yeah
<jenneron[m]> the command should be i2cdetect -r 10, but i'm not sure
<jenneron[m]> aceridus: are you sure i2cdetect command completed?
<jenneron[m]> it doesn't try 0x40
<jenneron[m]> i don't know whether `One` in ACPI is a high (0) state of GPIO in DT or it is low (1)
<jenneron[m]> you need to ask someone who better understands ACPI for this
<jenneron[m]> or check ACPI documentation or whatever
<aceridus> That is the output of 'i2cdetect -r 10', maybe I needed more parameters?
<jenneron[m]> not likely
<jenneron[m]> meanwhile you can take .mbn firmware files from windows and try to bind wifi
<jenneron[m]> once you have wifi, you can use ssh and work on panel over drm
jhovold has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
<jenneron[m]> aceridus: for touchpad i can suggest to try 4 configurations with fixed regulator:... (full message at <https://matrix.org/_matrix/media/r0/download/matrix.org/hlstZbReWpmFuVzokfsZWSnr>)
<jenneron[m]> vdd*
<aceridus> That link is giving me a not found error
<jenneron[m]> gpio 31 active high, no pull
<jenneron[m]> gpio 31 active low, no pull
<jenneron[m]> gpio 32 active high, no pull
<jenneron[m]> gpio 32 active low, no pull
<jenneron[m]> set the voltage to 3.3V and supply it to touchpad as vdd
<aceridus> Ok, I am not sure how to set the voltage to 3.3V?
<jenneron[m]> bind a fixed regulator
<jenneron[m]> aceridus: something like this https://dpaste.com/GL955J2XY
<jenneron[m]> nope
<jenneron[m]> this https://dpaste.com/CH2QMFWAC
<jenneron[m]> forget about first one
<aceridus> Interesting, I'll give that a try. Am I sort of correct if I say that the vdd_touchpad: regulator-vdd-touchpad {} block is largely symbolic in the sense that it defines a 3.3V regulator that is behind (i.e controlled by) GPIO 31 or 32?
<jenneron[m]> yes
<jenneron[m]> the only thing it actually does in hardware is gpio switch
<jenneron[m]> voltage and regulator name are just software modelling of this regulator
<aceridus> Ok, good. These aspects of DT have always been a bit blurry to me.
<aceridus> I like the phrase "software modeling" because that feels to me like exactly what it is doing
<aceridus> As someone who has hacked around a bit on DTS files, but largely doesn't understand or connect the dots as to why my changes work it helps me a lot because it is hard sometimes to identify which parts of DTS are very concrete (e.g. this thing is at this specific memory address) vs more symbolic structural representations (i.e "software modeling" of the hardware layout).
iivanov has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
matthias_bgg has quit [Quit: Leaving]
iivanov has quit [Quit: Leaving...]
<ajhalaney[m]> steev: is your lenovo-x13s-v6.0 branch good to run on the x13s? I'm debating upgrading my kernel this weekend and your branches seem to be the best to follow still (thanks for that work btw I appreciate it!)
aceridus has quit [Remote host closed the connection]
<steev> ajhalaney[m]: yeah, although i need to push 6.0.2 out, i just haven't yet
<steev> but it's what i run on mine :)
<steev> 6.0.3*
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
<ajhalaney[m]> thanks for the confirmation steev !
leezu has quit [Quit: WeeChat 3.0]
leezu has joined #aarch64-laptops
leezu has quit [Quit: WeeChat 3.0]
<steev> ajhalaney[m]: pushed tag lenovo-x13s-6.0.3 (and the branch should be lenovo-x13s-6.0 ) which may or may not have worked (i mean it works and boots fine here, i just suck at git and pushing tags)
* ajhalaney[m] will try steev's tag soon(is)
<steev> clover[m]: ^^ too
<clover[m]> <3
<steev> nothing new, just based on 6.0.3
<ajhalaney[m]> Hmm, unfortunately that fails to boot for me but I'm not sure why. Your 6.0.0-rc6 works fine though. Tried a quick triage with `boot_delay` and `ignore_loglevel` but it didn't reveal much.. just looked like systemd took off finally and the screen looks like it's going to start showing the "prettier console" and login (console clears) but it never does. Fun part is the backlight dims after a while even. maybe it's got network and I
<ajhalaney[m]> can ssh in steev but it will have to wait as I've got guests coming for the weekend soon :(
jhovold has quit [Ping timeout: 480 seconds]
solsTiCe has joined #aarch64-laptops
solsTiCe has quit [Quit: Ping timeout (120 seconds)]
solsTiCe has joined #aarch64-laptops
* clover[m] continues to wait patiently
<steev> hmm, odd; nothing should have touched the graphics stack; let me check here
<steev> fwiw, this is a diff of a savedefconfig and what is in the laptop_defconfig here - https://paste.debian.net/1257897/ ; and http://sprunge.us/Jd4VVD is the exact config i am booting here
<steev> ajhalaney[m]: do remember that the firmware moved again, but i think you acked/reviewed it so
<steev> though that shouldn't affect the display
solsTiCe has quit [Quit: The Lounge - https://thelounge.chat]
SSJ_GZ has quit [Ping timeout: 480 seconds]
leezu has joined #aarch64-laptops