steev changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Various Snapdragon laptops) - WIP kernel: https://gitlab.com/Linaro/arm64-laptops/linux/-/commits/qcom-laptops - Chat archives: https://oftc.irclog.whitequark.org/aarch64-laptops
<penguin42[m]> Mohamed MediouniOK, that's better - fastrpc_test -d 3 is passing 2 out of 3, with the hap_example_mem_dmahandle being the one that failed; which I think is what llama was moaning about in it's logs
ScentedFern has joined #aarch64-laptops
ScentedF1 has joined #aarch64-laptops
ScentedFern has quit [Read error: No route to host]
<mmediouni[m]> Are you running it as root
<mmediouni[m]> if so that's a bad idea
<penguin42[m]> I am, not had a host crash yet
ScentedF1 has quit []
<mmediouni[m]> from what I saw, DSP access will break until you reboot and not run workloads as root
<mmediouni[m]> why? idk exactly
ScentedFern has joined #aarch64-laptops
<penguin42[m]> weird; I am seeing the kernel restart the cdsp after a crash - but that seems succesful
<penguin42[m]> right, time for bed; attack it more tomorrow - good night
JanC has quit [Remote host closed the connection]
JanC has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<clover[m]> <asteroidimalittleteapot[m]> "Well. I installed arch ports on..." <- Patched kernel?
mbuhl has quit [Ping timeout: 480 seconds]
martiert has joined #aarch64-laptops
martiert_ has quit [Ping timeout: 480 seconds]
<HdkR> How does Snapdragon support Microsoft HMFT when that's a stateless API but they require stateful? :thonk:
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
dc7800 has joined #aarch64-laptops
<asteroidimalittleteapot[m]> <clover[m]> "Patched kernel?" <- Yup
dc7800_ has quit [Ping timeout: 480 seconds]
<asteroidimalittleteapot[m]> I forgot to backup the firmware 😂. Waiting on Jens to fix me up
blaztinn has quit [Ping timeout: 480 seconds]
ScentedFern has quit [Ping timeout: 480 seconds]
blaztinn has joined #aarch64-laptops
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #aarch64-laptops
bandini has joined #aarch64-laptops
mbuhl has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris has joined #aarch64-laptops
Ariadne_ has joined #aarch64-laptops
Ariadne has quit [Read error: Connection reset by peer]
Ariadne_ has quit [Read error: Connection reset by peer]
bandini has quit [Ping timeout: 480 seconds]
Ariadne has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
psydroid has joined #aarch64-laptops
bandini has joined #aarch64-laptops
bandini has quit [Ping timeout: 480 seconds]
<\[m]> anyone tested fairydust on asahi ?
<\[m]> Jens Glathe sorry i haven't had time to test the tb4 dock, your new mentioned tip, does it have the usb3 fallback hack or that will remain experimental?
ninelore has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ninelore has joined #aarch64-laptops
bandini has joined #aarch64-laptops
<JensGlathe[m]> It is in there and enabled for T14s. Even if qcom,disable-usb4 might not be upstreamed, the other patches in ps883x should if they prove to solve the dp altmode negotiation issue.
<penguin42[m]> Hmm what's that about - I was just about to ask if you knew of anything with tb4 working - because I've seen no sign of it so far
<penguin42[m]> (on my zenbook)
ScentedFern has joined #aarch64-laptops
ScentedF1 has joined #aarch64-laptops
ScentedFern has quit [Read error: Connection reset by peer]
<JensGlathe[m]> make a tb4 dock with type-c fallback useful again. My 40B0 Is completely useless with tbt4 cable and an arm laptop, but with a type-c host cable it works well (as type-c hub with reduced functionality). There are issues with the ps883x redriver, though. So, went on vibe-hacking to debug this, and found patches to make it work, too.
<JensGlathe[m]> I have a patch for the A14 dt, too, but not published yet.
<penguin42[m]> oh right, well I'll have it when you're ready; I bought myself a few cables that claim to do the trick
enyalios_ is now known as enyalios
<krhnrchr> I didn't try the new arciso but just did the changes for mainline and I am on mainline kernel now. Magic. Hats off to everyone who made this possible, x13s truly is the perfect laptop for day drinking in the yard and doing silly things.
bandini has quit [Ping timeout: 480 seconds]
noch has joined #aarch64-laptops
norayr has quit [Ping timeout: 480 seconds]
<penguin42[m]> Thanks, I'll give it a go!
<penguin42[m]> Mohamed MediouniI have same behaviour on the fastrpc/cdsp as non-root (just chmod a+rwx /dev/fastrpc-cdsp) ; just checking, you're not running 'secure' are you?
bandini has joined #aarch64-laptops
norayr has joined #aarch64-laptops
noch has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Ping timeout: 480 seconds]
fen_ has joined #aarch64-laptops
fen has quit [Ping timeout: 480 seconds]
fen_ is now known as fen
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<akrosi> are there patches circulating for iris breaking after suspend on x1e yet, or the occasional eDP link negotiation failure? I've found a way to work around the latter, but the general jankiness of iris is getting annoying
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
agl has quit [Ping timeout: 480 seconds]
agl has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
<penguin42[m]> oh great, the test cases in the fastrpc git are binary only; that really helps for debugging the damn things
bandini has quit [Ping timeout: 480 seconds]
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
noch has joined #aarch64-laptops
norayr has quit [Ping timeout: 480 seconds]
<Mis012[m]> penguin42: ghidra go brrrr
<Mis012[m]> fuck black box development
<Mis012[m]> but weird
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
<penguin42[m]> Mis012The whole ecosystem is pretty screwy here; as far as I can tell you need a fastrpc and firmware to match - which you have to get from your vendor; but ok, can you in theory then run any fastrpc client against that - wth knows?
* penguin42[m] adds a note to https://github.com/qualcomm/fastrpc/issues/235 saying why missing the source is a pain
<Mis012[m]> penguin42: ideally we'd make use of EL2 and nuke stupid qurt and the whole stupid thing
<Mis012[m]> but I would do that more on principle, didn't realize it was this bad even if you don't have those
<Mis012[m]> * but I would do that more on principle, didn't realize it was so bad you may want to do it even if you don't have those
<penguin42[m]> Mis012Except then you've got wth knows what other uses of the hexagon for the platform; I'm not sure what uses the cdsp, but I saw for example that the usb handshaking goes through the hexagon so as soon as you touch it, it's pretty much everything gone
<Mis012[m]> that's adsp
<Mis012[m]> cdsp shouldn't be used by anything
<Mis012[m]> I mean, it shouldn't even be booted unless you explicitly want it to be?
<Mis012[m]> while adsp-lite is a thing now because of the usb stuff xD
<penguin42[m]> what's adsp-lite?
<Mis012[m]> tl;dr a lighter build of adsp fw used by uefi so you can have usb work in uefi
<Mis012[m]> afaict
<penguin42[m]> ah right, yeh I saw something about that
<Mis012[m]> but Mohamed Mediouni can probably give you a better answer :P
<anthony25> and battery reading
<Mis012[m]> right, they also shoved charging in there
<penguin42[m]> anthony25Yeh well I am wondering where the kernel message 'kernel: Unknown battery technology 'OOI0AS3GZHg3KB4617'' is coming from....
<Mis012[m]> I mean, it's better than being done by an EC, this way you can move it all into Linux since you in theory have access to the pins :P
<Mis012[m]> though using the EC would have the theoretical benefit that the SoC doesn't need to be powered on for charging
<Mis012[m]> I bet in practice they'd screw it up anyway
<anthony25> with adsp lite I couldn't see the battery in linux, but I didn't try much, I've quickly setup qebspil
<anthony25> but normally that should work
<anthony25> I don't know if it was a misconfiguration of my initramfs
<Mis012[m]> could also just be broken?
<Mis012[m]> can you see battery in edk2 :P
<anthony25> I don't know, I thought some people were using el2 without qebspil here
<Mis012[m]> well, on that specific device maybe it just doesn't work
<Mis012[m]> how would the OEM even notice
<anthony25> slim 7x
<anthony25> but I don't know
<Mis012[m]> I assume windows loads full fat fw and edk2 setup shit doesn't show battery info :P
<penguin42[m]> anthony25: Have you got a charging LED?
<Mis012[m]> Mis012[m]: though I suppose some do
<anthony25> I'm a bit lazy to debug, maybe I will once I'm bored backporting the remoteproc patches for qebspil :p
<anthony25> penguin42[m]: you mean in adsp lite or in general?
<penguin42[m]> I meant in general, and is that working?
<anthony25> yes but I configured the EC driver for it
<anthony25> do you have a slim 7x x1e?
<penguin42[m]> no, asus zenbook a14
<penguin42[m]> also x1e
<penguin42[m]> well, maybe not the e
<anthony25> hmm, so if I read https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14#feature-matrix, it says: Similar to out-of-tree EC driver for Lenovo Slim 7x
<anthony25> and you can try this for the dts of the zenbook a14: https://lore.kernel.org/all/ajKCupui1WILXnxh@tour-anthony.aruhier.fr/
<penguin42[m]> I've not tried that driver yet, there's a little python script to do some fan stuff on here which I've been using so far, but I need to try that sometime
<anthony25> I don't know if the EC is on the same GPIO pins for the 2 laptops
<penguin42[m]> (back in ~30)
<anthony25> maybe serdeliuk can help you on this
<penguin42[m]> oh yeh I just need to get around to trying that one, it's low on my priority though since that mostly seems to be working OK
dc7800_ has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Read error: Connection reset by peer]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
f_ has quit [Ping timeout: 480 seconds]
Ariadne has quit [Read error: Connection reset by peer]
Ariadne has joined #aarch64-laptops
f_ has joined #aarch64-laptops
dc7800_ has joined #aarch64-laptops
dc7800 has quit [Ping timeout: 480 seconds]
dc7800 has joined #aarch64-laptops
dc7800_ has quit [Read error: Connection reset by peer]
f_ has quit [Ping timeout: 480 seconds]
f_ has joined #aarch64-laptops
<penguin42[m]> ahha, I've got an infinite amount of debug out of farf