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)
<qzed>
hmm, looks like that is SPI? I don't really know how that works on our devices... I thought maybe the TEE manages the SPI device (like the flash for UEFI) but it could also be just some secure store thing and the fingerprint is an actually accessible device...
<steev>
the schematic i found online for the c630 says it's an spi device
<steev>
i believe tee is used to store the fingerprint
<qzed>
yeah, that doesn't necessarily need to mean much...
<qzed>
the SPX schematics also have the UEFI stuff (or what I think it should be) present as QSPI flash
<steev>
but there's also some mbns
<qzed>
windows drivers and especially ACPI will likely give us more indications
<steev>
i haven't booted my c630 into windows in so long, i'm scared to
<qzed>
e.g. the QSPI flash on the SPX is nowhere defined in ACPI (because the OS is not supposed to access it directly)
<qzed>
heh
<steev>
hm, i dunno if it even will? for me it's just chillin at the lenovo logo when i choose windows now
<qzed>
according to the ACPI in the aach64-laptops repo, the c630 has only one SPI device, and that seems to be for audio
<qzed>
so my guess is that the fingerprint is fully managed by TEE
<qzed>
any parents or device references (like full path under details or something)
<steev>
parent says ACPI_HAL\PNP0C08\0
<qzed>
huh, I can't find any PNP0C08 in any of the ACPI dumps in aach64-laptops/build
<steev>
hm, maybe i should re-dump them
<steev>
pretty sure that dump was when i first got it
<qzed>
neat, I think the ALWAYS_ON thing works
<qzed>
it still isn't really behaving well.... seems to time out on something
<qzed>
"resume devices took 13.799 seconds"
<qzed>
but, it did come back with the nvme drive still working
<qzed>
I did pull in a ton of other stuff though that I don't really know if I need
<steev>
well that's a step in the right direction!
<qzed>
at least gives one the option to more or less "properly" debug it xD
<steev>
i understand the ton of other stuff
<steev>
i'm currently trying to figure out what i actually need from the c630 stuff (technically none) and the sc8180x stuff, and then the thinkpad
<steev>
it's just a bit of a slog
<qzed>
yeah
<steev>
mad props to the mainline peeps that are able to do this
<qzed>
oh definitely... dealing with all those qualcomm shenanigans has me questioning how this "standard ACPI x86" stuff even really works...
<qzed>
like in ACPI world you call Device._ON or some other power state method and the device is on / in that state... whereas in DT land you somehow have to be a semi-mad hardware wizard with either a ton of time or decent documentation, or probably both
FizzBuzz has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
<derzahl>
hey fellas
<derzahl>
im playing with my c630 again, is the steev 5.19.0 branch the best to be on? looks like 5.18.y hsnt been updated in awhile
<steev>
did i not push the 5.18?
<steev>
oh, i guess i didn't
<steev>
derzahl: there you go buddy
<steev>
pushed the latest 5.18, i dunno if i did 5.19 just yet
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
qzed: so, the new acpi dump, i seem to not have FACS.{bin,dsl} and tables.txt
<steev>
i'm assuming i ran some other commands last time
FizzBuzz has quit [Quit: Leaving]
klardotsh_ has quit [Remote host closed the connection]
klardotsh has joined #aarch64-laptops
Evaia63 has quit [Ping timeout: 480 seconds]
Evaia63 has joined #aarch64-laptops
derzahl has quit [Remote host closed the connection]
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
derzahl has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
derzahl has quit [Quit: auf wiedersehen]
derzahl has joined #aarch64-laptops
<derzahl>
steev: thank you sir!
<derzahl>
everyone have fancy new x13s's now?
<maz>
jhovold: are you planning to respin this irqdomain race fix?
<jhovold>
maz: yes, that's the plan, but not until after the merge window. Taking a couple of weeks of leave. Sorry for not making that clear.
<maz>
jhovold: no worries, enjoy your time off!
<jhovold>
thanks!
derzahl has quit [Remote host closed the connection]
<steev>
wait, aren't you supposed to be on vacation?
<robclark>
maz: hmm, the issue was segfaults when running khronos webgl tests, so probably not?
<qzed>
jhovold: awesome, thanks!
<robclark>
maz: anything interesting in dmesg?
<jhovold>
steev: starts tomorrow ;)
<maz>
robclark: no, only the display controller shouting in a loop, and the X serssion being completely dead.
<maz>
shouting about a timeout, to be clear.
<robclark>
hmm, hangcheck timeout or waiting for irq timeout?
<maz>
can't remember from the top of my head. let me bring the machine up again and let it simmer for a couple of days. iti usually happens once a week... :-/
<robclark>
ok.. both gpu and disp errors should trigger a devcore dump to capture respective state..
<robclark>
so you might want to have some script to periodically check sysfs and slurp 'em out
<steev>
i think i got the mdss node wrong, i'm not sure what the alphabetical order should be exactly, if it should be based on mdss or the devicename itself
<jhovold>
steev: ok, thanks. not seeing that, but mu x13s doesn't have a modem on that bus. Not enabling that driver either. Well, well, something for another week. :)
<steev>
i don't have a modem either :)
<steev>
at least, i don't think i do
<steev>
maybe they threw one in since they screwed up the initial shipping
<steev>
dmesg output is nicely clean now, the only reds are the missing debounce time on the power key (nbd), and the missing gpu, but also, nbd
<qzed>
I see similar messages on the SPX (sc8180x) with the port for the nvme
<jhovold>
steev: yeah, bamse fixed the dp clock splat which was the biggest annoyance
<steev>
oh, i did see that was sent, i haven't had a chance to do email, this week is release testing week for kali so not a lot of spare time
<qzed>
not sure if that's what you were talking about, but the rcg(?) warning is gone, nice!
<steev>
qzed: that is - that's the patch from bjorn earlier today
<qzed>
awesome
<qzed>
now the only warning I have is some self-test for "pkcslpad"
<szclsya[m]>
yup, I will go back to linux-firmware when that is merged && in arch's linux-firmware package
<szclsya[m]>
I was worrying about copyright issues when doing this package (the blobs are from qualcomm and may not be accepted by the upstream, so a specific package makes sense), but a few days later lenovo publishes that patchset proving me wrong
<steev>
it's one of the grey-er areas of packaging :/
<clover[m]>
it's big news that lenovo is adding linux support?
<steev>
it's the first time they've done it, although i'm a bit sad that mark said that it's unlikely to get the c630/flex5g stuff in (unless the thinkpad is fairly successful)
<szclsya[m]>
not really, but x13s is not part of their thinkpad linux program, so no guarantee
<steev>
szclsya[m]: based on my reading of the thread... they're trying to make it
<szclsya[m]>
steev: usually they will have official claims about supporting linux on some of the thinkpads. they didn't claim it on the x13s, but seems that they are trying to do it regardless
<szclsya[m]>
probably due to it's the first arm thinkpad
<steev>
right
<leezu>
robclark: Nice. No more backtraces when running the WebGL conformance test (at least on the first try), but the system froze and rebooted.. Has that happened to you before?
<clover[m]>
Quick take-aways: audio, WiFi not yet working, power management flaky, and for reasons not divulged (but I assume having to do with proprietary drivers), they're not sure the camera will ever work. Which is a bummer, because that's kinda a deal-breaker for me.
<leezu>
robclark: I noticed that only your first commit includes "Cc: mesa-stable"
iivanov has quit [Quit: Leaving...]
<robclark>
leezu: anything in dmesg, if I had to take a guess possibly bo allocation fail because out-of-memory or out-of-address-space (I mean, I guess if webgl tests are allocating 2GB FBO's then you'll run out of memory quickly)
<robclark>
leezu: 2nd patch has Fixes tag which should be enough for it to be picked up to appropriate stable branches
<robclark>
clover[m]: is camera a mipi camera? I wouldn't have expected that on a clamshell (but it is a thing that would probably be hard to upstream currently)
<clover[m]>
Camera : IR & 5.0 MP MIPI Windows Hello
<steev>
yep
<steev>
it's mipi-csi
<clover[m]>
its a nice camera
<steev>
if the optee stuffs could be figured out, maybe a userland driver could be created for it?
<steev>
i can't tell if it pokes into tz or not
<qzed>
how's that looking on the qualcomm/DT side? x86 Surface devices have been using mipi-csi for a couple of generations and thanks to libcamera folks and some independents we've got that sort-of figured out by now (at least the for older IPU)
<qzed>
steev: I doubt cameras themselves will run via (op)tee
<robclark>
so mipi camera is the one big downstream qc thing we have in CrOS kernel.. there is some talk of new camera framework thing that would make it easier to upstream camera (but I guess that mostly just shifts the magic bits into userspace blobs)
<qzed>
but (at least if it's similar to Intel's mipi-csi stuff) you'll still need some userland software (libcamera) to hook things up, do image processing, ...
<steev>
ah, if you need magic bits in userspace blobs... i can see why it would be unlikely to happen
<robclark>
yeah, I don't think/expect the tee to be involved
<robclark>
the csi cameras tend to rely on lot of isp to get a good image.. all sorts of image processing is done to clean up the picture
<robclark>
with usb camera, all that magic stuff is on the other side of the usb connection ;-)
<qzed>
so on the intel surfaces you have: camera sensor -> mipi-csi interface (IPU or something) -> userspace (libcamera) -> processing (ISP/also IPU?) via hardware / kernel, debayering, ... or something like that
<qzed>
I don't really know the specifics
<qzed>
only that libcamera essentially handles all the processing
<qzed>
windows has some blobs for that (I think they're supposed to be loaded into the ISP or something) but I don't think anyone ever looked at that
<qzed>
so right now the libcamera folks and volunteers are essentially doing the processing stuff themselves
<qzed>
yeah, getting a picture is one thing, getting it to look decent is a whole other thing
<steev>
jhovold: btw, trying newer than 28 next (as well as applying against torvalds to see what we are looking like there...) I see [ 2.254510] qcom-pcie 1c10000.pcie: Phy link never came up
<clover[m]>
Ew x86
falk689 has quit [Remote host closed the connection]
falk689 has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]