ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
<_merk>
omg sick i just figured i can snap pipewire out of a handsfree call to headset by restarting the service! (;
<_merk>
it gives me the shits from time to time when i want to listen to hi-def music (;
<Radical[m]>
_merk: does the image and replies work over the bridge? Im not used to communicating over these 😅
<_merk>
btw thanks macc24 i thought i was in #e last night when raising the multiarch/lib issue
<_merk>
Radical[m]: if i'm not mistaken, yes! haah
<_merk>
in the past it has been overwhelming
<_merk>
but a-ok now
<_merk>
if im not delusional haha!
<Radical[m]>
well i sent an image with my first message and replied twice so if you cant see them then no
<_merk>
ser, ma'am, ye, master, miss or mistress (;
<_merk>
is abour my range of reference out of respect.
<_merk>
i could use such a memlat governer in my mind
<_merk>
a self governing one :D
<_merk>
what does SCMI stand for?
<_merk>
some kind of interface?
<_merk>
<3
<_merk>
omg i see memlat.. how would that play into webrtc conference sync? my understanding sip/webrtc conferences need rtc sync which is not perfect when hosted on a virtualised server
<Radical[m]>
_merk: It's apparently System Control Management Interface
<_merk>
and memlat is some sort of web based browser for memory load latency profiles,eyeah?
<_merk>
its ironic you bridged that as i was in a telehealth conference, thats why i ask, dunno if i'm gaining insight or ... delusional haha
<_merk>
webcam on the snapdragon would be nice
<_merk>
i had to user my phone but had the dragon in the virtual waitingroom with the mic on in call.
<_merk>
there was one moment in the conference where it was like it had a seizure
<_merk>
thats what got me thinking this lol
<_merk>
like a schumann's resonance syncd the schism with lightning
<ppd[m]>
hm, does anyone have a resource on what qcom does when loading the qadb, or is that all in audioreach?
<_merk>
iono
<_merk>
i have to make an arm multilib environment/package repositiory
<_merk>
so there is archlinux arm binaires for wine etc
<_merk>
so thats my focus (;
<_merk>
regardless if i use qemu-user-static, box64 or FEX
<ppd[m]>
best of luck to you, and note that many arm processors are not multilib
<_merk>
still need that
<_merk>
ppd[m]: thats ok i wrote the cross-arch freebsd bmake contribution over a decade ago
<_merk>
tbh never finished it as i ended up under government duty of care and thrown into the pan/rehab lol.
<ppd[m]>
aside, better question: assuming (with my current knowledge) that the adsp is used for audio in windows, is it able to be used for audio processing in linux?
<_merk>
oh you said qadb the first time not adsp i thought you meant some kind of qcom androidbd
<_merk>
thx for the heads up this is interesting stuff
x44a has joined #aarch64-laptops
x44a has quit []
x44a has joined #aarch64-laptops
x44a has quit [Remote host closed the connection]
x44a has joined #aarch64-laptops
x44a has quit [Remote host closed the connection]
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
x44a has joined #aarch64-laptops
x44a has quit [Remote host closed the connection]
hexdump0815 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
<macc24>
amstan: well my mental health got a lot worse in past few months :(
<macc24>
also, making me a mod is a bad idea right now
<macc24>
in future probably too
martiert_work has quit [Quit: WeeChat 4.4.4]
martiert_work has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
alfredo has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
funderscore is now known as f_
<jhovold>
ppd[m]: yes, the adsp is used for audio, but also things like usb-c altmode and orientation detection, and battery
alfredo has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
<steveej[m]>
i'm exploring better office headsets and i'm trying to understand if the x13s has bluetooth LE hardware capabilities so that i could have triple-channel audio on bluetooth with the right headset?
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
srinik has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
<anthony25>
however I'm quite confused, if maybe someone has a clue of what is going on
<anthony25>
other x1e80100 laptops use GPIO pin 92 for this, on this laptop it is also the case, but pin 92 doesn't get any event unless I start to monitor events on pin 71
<anthony25>
pins 71 and 92 both get the same events, so tracking pin 71 seems to work, however I tried to understand in my acpidump what would be this pin 71 but didn't find anything relevant
<travmurav[m]>
inb4 71 is accidentally tied to 92 and all you did is changed it's pinctrl from forced output/pull to hi-z input to un-choke it
<anthony25>
however the acpidump shows me that the LIDR (which reads the LID status) is on pin 92
<anthony25>
travmurav[m]: I'm not really familiar with GPIO, can you explain me a bit what you mean?
<travmurav[m]>
without that change, what are the debug/gpio settings of gpio 71?
<travmurav[m]>
my guess is that it was set to output and overpowered actual lid events on the wire
<anthony25>
input, active-high
<travmurav[m]>
oh, and 92 is input too?
<anthony25>
I mean, that's what I get with gpioinfo on this chip, but nothing is set on the dts for this pin
<travmurav[m]>
right, and this is without your patch that sets pinctrl?
<anthony25>
by default everything is on input active-high, yeah
<travmurav[m]>
interesting
<travmurav[m]>
is there pull settings?
<anthony25>
how could I check that?
<travmurav[m]>
would you mind sharing output of the debug gpio file?
<travmurav[m]>
at least for those two gpios
<anthony25>
you mean the output of gpioinfo or something else?
<travmurav[m]>
cat /sys/kernel/debug/gpi
<travmurav[m]>
o
<anthony25>
so, with this patch:
<anthony25>
gpio71 : in high func0 16mA no pull
<anthony25>
gpio92 : in high func0 2mA no pull
<anthony25>
I give you a full paste and the output without this patch in a few min
<macc24>
anthony25: what device are you talking about?
<anthony25>
lenovo yoga slim 7x, snapdragon x elite
<anthony25>
travmurav[m]: so what cleaner solution should I go for instead of what I did?
<travmurav[m]>
yeah so my guess is that hw wise theyre both connected but gpio71 is set to (strong!) output high which just overpowers any attempt of the ec to pull the line low
<travmurav[m]>
my suggestion would be to have your input gpio as 92 like on all other boards but set pinctrl for the lid node to both gpios, making both input with no bias (assuming the line is externally biased in appropriate manner)
<travmurav[m]>
at least IMO that'd be the correct way to describe it, explicitly setting pinctrl settings for both involved gpios
<travmurav[m]>
or output-low; for that matter I guess
<travmurav[m]>
well
<anthony25>
and what is the common naming for a PIN we don't know about?
<travmurav[m]>
in the end, just need to set it to not be strong output-high xD
<anthony25>
I'm asking because I have no clue what PIN 71 is, so if I send a patch for the dts, how should I name this item?
<travmurav[m]>
I'd do a group like this and call the 71 something like lid-pull-pins, with a comment why it has to be set. Unfortunately there is no way of actually knowing what it does without schematics
<macc24>
<anthony25> "Hi, I have a lenovo yoga slim 7x..." <- holy shit
<anthony25>
haha :p
<macc24>
congrats!
<anthony25>
that's a fun laptop, it's clanky but I get to learn a bit how it works in the ARM space for linux support
<macc24>
how did you figure it out?
<anthony25>
I've looked how it was done on other laptops with the same chip, did an acpidump on windows, saw that it should be pin 92 too, so I got confused
<anthony25>
and I basically ran a gpiomon on everypin of this chip in parallel :D
<macc24>
huh
<anthony25>
and got confused because only then I saw events on LID switch on pin 92
<anthony25>
so I narrowed it down
<kuruczgy[m]>
can confirm, while running gpiomon -c /dev/gpiochip9 71, gpio92 seems to correctly report the lid state. Will try your patch now.
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
why is that pin even set to output in firmware then, very wacky lol
<SpieringsAE>
but also just, why 2 input pins
<kuruczgy[m]>
redundancy :D
<SpieringsAE>
two switches?
<kuruczgy[m]>
well no, it seems that the two gpios are physically wired together. there is no world where that makes sense.
srinik has joined #aarch64-laptops
<SpieringsAE>
kettenis: Huh is netbsd trying to stick with acpi for these devices? But at least nice that this pattern was found!
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
<macc24>
kuruczgy @kuruczgy:matrix.org: someone made a typo and it was too late to correct xD
<kuruczgy[m]>
And can confirm that the laptop goes to sleep when closing the lid with the patch. Thanks for this early Christmas present anthony25 :)
<macc24>
i'd love to see that patch on the mailing list
<macc24>
;)
<SpieringsAE>
I'm hoping for a usb_2 related christmas present, would love to have a working sd card reader
<SpieringsAE>
For anyone with the t14s, does the fingerprint scanner work in windows?
<SpieringsAE>
I suspect that one is also on usb_2, but the sd card reader on the asus vivobook is also broken in windows
derzahl has joined #aarch64-laptops
<anthony25>
I'm debugging with the explanations from travmurav[m] to make it cleaner ;p
<anthony25>
I'm quite new on dts tweaking
* travmurav[m]
is not sure if he is happy his "bringing up boards without schematics is torture" stance is reaffirmed again today
<anthony25>
haha!
<travmurav[m]>
perhaps it's a good thing that keeps me from irresponsible purchases /s
<anthony25>
if only windows didn't rely on ACPI, maybe we would have a descriptive format we could actually read…
<anthony25>
(for these laptops, I mean)
<travmurav[m]>
the problem is that not everything /needs/ to be described sometimes, but you'd still need to have knowledge of things when you're bringing stuff up. i.e. the OS doesn't need to know what's connected to the EC but you need, to know what you /could/ interrogate EC on or i.e. what makes no sense to do since EC would force things it's way anyway
<anthony25>
I understand, but that's what you do on the driver level, no? (if I understand correctly, that's for example what the EC driver does on this laptop, which allows to turn off the keyboard and blink the LED when suspended)
<anthony25>
for the GPIO pins, it's a static description
<travmurav[m]>
well yes, but what use a laptop if you don't get everything working on it
<travmurav[m]>
my point was, that even "good" description given to software won't be that good to bring the board up fully
<travmurav[m]>
and that doesn't even concern platform stuff
<travmurav[m]>
like on aspire1 I have some gpios that control some power rails, I can kill the gpios but I can't kill power rails because they're also controlled by the EC, which I only know from the schematics
<anthony25>
ha yeah definitely
<robclark>
\o/ 7x lid switch
* robclark
wonders how long it will take to get out of the habit of manually clicking power -> suspend
<anthony25>
travmurav[m]: and you were right, setting pin 71 to 2mA works
<travmurav[m]>
was almost immediately for me when I implemented it for mine
<travmurav[m]>
anthony25: I guess another problem is that we don't know exactly //why// it was used
<travmurav[m]>
i.e.
<travmurav[m]>
what if that gpio is a very dumb design decision of being an actual pull-up of that line
<travmurav[m]>
in which case just disabling it may end up causing spurious lid events
<travmurav[m]>
though I guess it'd be rather obvious if we had both gpios no-bias and no output and the line suddenly went low
<anthony25>
I don't disable it, I just set it to no-bias and drive-strength <2>
<travmurav[m]>
oh and still let it output? I guess
<anthony25>
yep
<travmurav[m]>
but well, Id argue that gpio should have full description (i.e. you should assume firmware will leave it in fully random state and your thing should still work)
<anthony25>
I don't know what it does, so I prefer changing the minimum things
<travmurav[m]>
so probably want to set output-high; on that pinctrl to explicitly define it's needed state
<travmurav[m]>
but whatever you do, the most important part is probably writing a comment about why :P
<kuruczgy[m]>
I have the gpio config dumps from windows somewhere, maybe we could check what windows is setting gpio71 to
<travmurav[m]>
that would be good to do yeah
<anthony25>
is it in DSDT?
<anthony25>
if so, I can paste it, I found this GPIO pin there
<travmurav[m]>
(equivalet of debug/gpio but harder to read haha)
<kuruczgy[m]>
GPIO 71 | 0xf147000 | in | func0 | hi | pull up | 16 mA | ctl=0x000001c3 io=0x00000003
<travmurav[m]>
and can you remind me of the other one?
<travmurav[m]>
92 that is
<anthony25>
92
<kuruczgy[m]>
GPIO 92 | 0xf15c000 | in | func0 | lo | no pull | 2 mA | ctl=0x00000000 io=0x00000001 (in case this also matters)
<travmurav[m]>
interesting
<travmurav[m]>
um
<travmurav[m]>
this is at the same time?
<kuruczgy[m]>
yes
SpieringsAE has quit [Quit: Leaving]
<travmurav[m]>
one is hi and one is low?
<anthony25>
they're both as input, should I try to just set the 71 as input?
<kuruczgy[m]>
wait what? yeah you are right that's def wrong
<kuruczgy[m]>
Ah no the "hi/lo" is the output, which in this case doesn't matter
<travmurav[m]>
ah
<kuruczgy[m]>
You can decode the register values yourself, my decoding code was written by Claude so I don't trust it one bit, I already fixed one bug in it
<travmurav[m]>
ah bit0 is 1 in both
<travmurav[m]>
well I guess in this case setting both 71 and 92 to exactly how it's on windows would be the best solution IMO
<anthony25>
so input-high for pin 71?
<anthony25>
should I set bias-pull-up for 71 and bias-no-pull for 92 or should I leave it to bias-disabled?
<travmurav[m]>
bias-pull-up; output-disable; I think for 71, bias-disabled for 92
<travmurav[m]>
not sure if all of them are available on qcom tlmm
<travmurav[m]>
(I've re-checked that above dump for gpio 71 is correct, according to the ctl register value in it)
<anthony25>
nice, that works
<anthony25>
why output-disable and not input-high as it seems to be on windows?
<travmurav[m]>
output enable/disable and input enable/disable are not mutually exclusive
<travmurav[m]>
and there is no "input-high" :P
<travmurav[m]>
you want to remove "output_enabled" bit from the ctl register to make hardware not drive the pin
<travmurav[m]>
input is independent from that and, if output is enabled, would just read whatever it itself outputs
<anthony25>
ha ok, I see
<travmurav[m]>
or, well, if something overpowers it, that :D
<anthony25>
yeah my question was stupid, I see that the pin is now listed as input high
<ppd[m]>
jhovold: is it just for sending signals to audio or does it do some processing of its own?
<anthony25>
I'm updating the patch to Ubuntu, I'll send it on the ML (first patch that I'll send for the kernel \o/)
<tobhe>
thanks anthony25 :) I'll make sure to include it in the next build
<anthony25>
ty tobhe!
<maz>
isn't that what macc24 was after for a while?
<travmurav[m]>
I think at least 3 people took a stab at this
* travmurav[m]
mumbles something about not having schematics again
* maz
would love the schematics to the devkit... I hear some people have them... ;-)
<travmurav[m]>
presumably devkit is just some evaluation board/reference design in a box so possible that the schematics exist in a lot of people's hands outside of qcom, being a part of the design package
<travmurav[m]>
but nda moment
<maz>
yeah, exactly. I wouldn't want someone to get in trouble over that.
<macc24>
maz: yeah it was
<kuruczgy[m]>
When I was looking at the lid switch a while back I was only looking at pins set to output by windows, did not occur to me that you instead have to set a pin as input that the fw sets to output by default.
<kuruczgy[m]>
I think macc24 was mostly looking at EC stuff in relation to the lid switch
<JensGlathe[m]>
maybe pin71 -> pin92 interconnect is sort of a wakeup hack? Like "don't go to sleep when... <whatever>"
<anthony25>
I think so
<JensGlathe[m]>
even when lid is closed
<macc24>
they have a "lid open = power on" switch in uefi
<JensGlathe[m]>
oooh fancy mac-style things. I've seen that on the HP X14, too, but since its always on anyway (sorta), you tend to forget
<JensGlathe[m]>
macc24 did you play around with this EC testing sw
<travmurav[m]>
um gpio71 connected as interrupt on sdhc? lol
<travmurav[m]>
inb4 as a hack to switch it to input
<travmurav[m]>
"just append it to some random place, whatever"
<anthony25>
what would that mean?
<anthony25>
oooohhh, ok
<anthony25>
wow…
<travmurav[m]>
ah s/interrupt/io/ so I guess just plain input
<anthony25>
windows does some fancy stuff regarding screen detection, idk if it could be linked
<travmurav[m]>
no idea how that gpio is related to sdhc but ehhhh
<anthony25>
like it detects if you're in front of the screen (not crazy at all…)
<anthony25>
but why would it be specific to this laptop compared to the t14s or xps 13…
<JensGlathe[m]>
good q
<travmurav[m]>
I wonder if running has lid switch/emulation of lid
<travmurav[m]>
the devkit thing that is
<JensGlathe[m]>
I would swear I've seen this on HP X14 and Lenovo Thinkbook 16, too
<travmurav[m]>
anyone already uploaded proper board photos for that thing?
<steev>
they're probably available on the fcc's website
<abby>
fccid.io is handy but seems to be down
<travmurav[m]>
the devkit is not fcc approved but even if it was, you can't really see much on a scan of a printout of a photo made on a 2003 feature phone
<travmurav[m]>
but I guess no one would bother disassembling the thing and spending proper time making macro photos and stitching them into a 25MiB jpegs like what I did for aspire1 to reference to
<travmurav[m]>
did you know that they laser big logos on chips using lines?
<kuruczgy[m]>
I don't remember seeing it before...
<robclark>
semi-recently (but that was probably a release or two back) I spiffed out the smmu fault reporting.. the S1CBNDX=127 part tells you which client
<robclark>
err, maybe I meant the SID part
<robclark>
SID=0x1c00 looks like display <-- lumag, fyi
<anthony25>
also, I recommend applying the patches to get the EC working on this laptop (I don't know why it's not merged yet): https://lkml.org/lkml/2024/9/27/947
<anthony25>
without it, the keyboard (and the backlight) is not turned-off when the laptop is suspended, and it also makes the power LED to blink
<anthony25>
by "I don't know why it's not merged yet", I meant I don't know why it's not in 6.13
<kuruczgy[m]>
I guess that patch needs a v2, and as macc24 said she has been a bit burned out lately... But yeah, EC driver would definitely be nice to have upstream
<anthony25>
oh sorry, I didn't understand that
derzahl has quit [Ping timeout: 480 seconds]
<ppd[m]>
kuruczgy: seems to be. I don't have those messages in my dmesg (though I'm still on 6.13-rc2 as of writing)
<macc24>
anthony25: the ec driver needs to be renamed to something that'd reflect it's shared across most x1e laptops and it's based on it8987
<ppd[m]>
I'm currently building 6.13-rc3 and will be booting to check quickly but otherwise it must be new
<anthony25>
ha ok, I thought it was a slim 7x specific thing
derzahl has joined #aarch64-laptops
<macc24>
i also thought that
<ppd[m]>
kuruczgy: OK, just booted rc3 and still no error matching that
<SpieringsAE>
I should at some point look into the ec (it5120vg) on this thing (asus vivobook), since it does seem to be different
<kuruczgy[m]>
ppd: I think I got it after waking up from suspend
SpieringsAE has quit [Quit: SpieringsAE]
<JensGlathe[m]>
yeah I had similar things with 6.12-rc, this disappeared with 12.6 (and a config sync with Ubuntu Concept)
<JensGlathe[m]>
Not having this now.
<JensGlathe[m]>
Those interesting cb errors I didn't see
<JensGlathe[m]>
it was suspend/restore related only