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
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Arrow canceled my order for the Dev Kit wow
<zdykstra> Which dev kit is that?
<JensGlathe[m]> Snapdragon Dev Kit
<JensGlathe[m]> ... and apparently killed my account or something
<JensGlathe[m]> oh no its only their wacky website. "An error occured loading orders" and showing my order then. Let's see if money reappears. They sent an email that it's out of stock, I should contact Converge.... (full message at <https://matrix.org/oftc/media/v1/media/download/AdaaqCKMcMTF28AGipJN3PYEEUE3ZJV48BdFSlpHTLmFah3SlDq5P5fRr7zbuoMYWZPeT4sVQApjA-H9sSyvRZdCeSLgms0wAG1hdHJpeC5vcmcvVXlkT0ZPZVJXYWxFUUhRTVVnT21Pb3Jr>)
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo has joined #aarch64-laptops
<Jasper[m]> <JensGlathe[m]> "oh no its only their wacky..." <- > <@jglathe:matrix.org> oh no its only their wacky website. "An error occured loading orders" and showing my order then. Let's see if money reappears. They sent an email... (full message at <https://matrix.org/oftc/media/v1/media/download/AdzFIF470iqNTCaagXTdyO9WCAF-bqC9pa-lmKKPsXjq94QlBU9R9uzdxMkDMR81hRbklMhx_FIIGSwD62d5OOhCeSLouJ-gAG1hdHJpeC5vcmcvdkpqWEJGRlRtT0ZUVm5kdFN2WnNUb1hz>)
alfredo has quit [Ping timeout: 480 seconds]
martiert has joined #aarch64-laptops
<HdkR> Dang, I see an unpopulated PCIe slot on that board. What a shame
<JensGlathe[m]> yep
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> I wonder how far one would get by just populating those spots yourself, not the most difficult things to solder
<SpieringsAE> all the chips around the hdmi port seem to be there, hell, maybe design your own daughterboard with DP instead of HDMI
<SpieringsAE> the PCIE slot seems to have something hijacking part of it
<SpieringsAE> ah no its just a cable managment clip stuck on there
alfredo has joined #aarch64-laptops
<MrCatfood[m]> even windows cant handle the lid properly, every time i start my laptop, i need to close the lid and open it up again for it to show the login screen -.-
iivanov has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
macc24 has joined #aarch64-laptops
<macc24> kuruczgy: i wrote a piece of rust code that talks to ec over i2c
<anonymix007[m]> abelvesa: USB-A works now! But I'm getting a lot of warnings in dmesg: https://katb.in/wazucasiqof
bluerise_ has joined #aarch64-laptops
dlg has quit [Remote host closed the connection]
dlg has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
hogliux has joined #aarch64-laptops
<hogliux> Has anyone had any experience with USB4 PCIe tunneling/thunderbolt alt mode? I have a PCIe NIC I need for work in a thunderbolt enclosure. It works on Windows on the yoga slim 7x. Nothing happens on Linux even with all the recent patches to the retimer (i.e. DP alt mode works for me in Linux).
<craftyguy> any reason why I can't enable CONFIG_CRYPTO_DEV_QCE on the x13s?
<craftyguy> "CONFIG_CRYPTO_DEV_QCE", I mean 🙃
<travmurav[m]> doesn't look like it was ever added to 8280
<craftyguy> it seems like performance with luks isn't great, and it seems like hw accel for crypto isn't enabled in jhovold's kernel. but I'm not sure if that's for any particular reason or not
<craftyguy> that was kinda a guess as to which kconfig I might need to enable for it... is there something else I would need to enable? or is hw crypto accel not a think on the 8280?
<travmurav[m]> it's probably there in hardware but it was never described in the dts
<travmurav[m]> so even if you enable it, it won't work
<HdkR> hogliux: Thunderbolt/PCIe tunneling isn't wired up in Linux. Sad day I know
<craftyguy> travmurav[m]: oh gosh
<craftyguy> is there a "enabling crypto in dts for dummies" I could study?
<travmurav[m]> the list of devices with qce enabled is a bit weird https://elixir.bootlin.com/linux/v6.11/B/ident/qcom%2Cqce
<travmurav[m]> well the main problem is like... knowing at what address it's located and which iommu lines it uses which is like ugh...
<craftyguy> how is that stuff typically discovered/known?
<travmurav[m]> by someone who works at quic I'd say :P
<craftyguy> 🤦
<travmurav[m]> craftyguy: quick look at it seems to suggest that it might even be protected since there is a comment in 8350 (same ish generation mobile platform) that enabling related dma crashes the system
<craftyguy> wowzers
<craftyguy> the crypto BAM thing
<travmurav[m]> well yes, idk what has happened in 3rd generation
<travmurav[m]> but well, if one knows the correct addresses and resources,then may ^C^V those nodes and it may work
<travmurav[m]> knowing is the hard part
<craftyguy> oops wrong chip
<craftyguy> sorry I thought I was looking at the dtsi for my soc
<travmurav[m]> yes it's not described in the sc8280xp
<macc24> craftyguy: you can check the acpi tables of x13s and the crypto device will probably be listed
<travmurav[m]> only in sm (smartphone) chips
<travmurav[m]> but I'd assume the hardware is there
<macc24> can check its exact acpi id in windows
<craftyguy> can I dump acpi tables from Linux, or does 'linux mode' disable that stuff?
<craftyguy> nice
<bamse> craftyguy: do you know how to test qce? i have the patches ready, the driver probes, but i don't know how to test it
<craftyguy> oh really?
<craftyguy> I'd probably test it by enabling the kconfig option for QCE (mentioned above) and see if performance improved for my rootfs that is on luks. I assume that's a valid test, but .. heh
<bamse> yeah, that might be a relevant test case...i could post the patches and state that they are untested...
<craftyguy> if you're worried, you could DM me the branch location, or pastbin the patch, or email it to me. I won't distribute, but would be suuuper happy to help test
<bamse> yeah, i guess i can push them somewhere...let me do that
<craftyguy> emailing me a patch also works if that's too much trouble. I'm just happy I don't have to stumble my way through making a patch myself 😅
<bamse> i was hoping to figure out that i can just throw one of the kcapi test tools at it and get a "test ok" out...and then the patches just sat there
<craftyguy> bamse: ping me once you're ready to share and I'll give it a try, and report back. thanks :D
<abelvesa> anonymix007[m]: yeah, that's the usb_2 controller which I was talking about. I only enabled it because I thought there might be something connected to it (e.g. fprint sensor). Not having schematics made me push the boundaries a bit. Thanks for reporting this. Doesn't show up on my t14s.
<abelvesa> anonymix007[m]: just drop this commit and you will not see that splat anymore:
<hogliux> HdkR: "not wired up" mean it's not in the device tree or stuff needs to be added to the re-timer or other drivers - or both?
<HdkR> hogliux: Both
bluerise_ is now known as bluerise
<macc24> kuruczgy: this is rust code for ec stuff: https://bpa.st/GM6MG, it needs i2cdev crate and i2c3 device enabled in dt with speed of 400000
<hogliux> ok kind of was expecting that
<macc24> it *should* wait for interrupt instead of polling but i don't think i can do that from userspace :)
<macc24> you can play around with key combinations like fn+space, or fn+f4
<macc24> ultimately it didn't give me any hits as to why the lid switch doesn't work
<macc24> i wish i could just stick a logic probe into i2c3 bus :/
<macc24> oh i wonder why the lid device in dsdt says it depends on SCM0 device
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
hogliux has quit [Quit: Page closed]
<steev> bamse: worst case, it would just cause an serror like the c630 :P
<macc24> travmurav[m]: any idea where GpioInt with number 0x340 could be wired up?
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
fparent_ has joined #aarch64-laptops
fparent has quit [Ping timeout: 480 seconds]
Mary has joined #aarch64-laptops
fparent has joined #aarch64-laptops
fparent- has joined #aarch64-laptops
fparent_ has quit [Ping timeout: 480 seconds]
fparent has quit [Ping timeout: 480 seconds]
<kuruczgy[m]> macc24: Thanks!
thevar1able_ has joined #aarch64-laptops
<bamse> steev: it didn't when i booted the mtp and/or crd...
<bamse> steev: that said, i haven't tried it on x13s
<bamse> macc24: which device? do you have a dsdt i can look at?
<macc24> bamse: it's a lenovo yoga slim 7x
<bamse> macc24: that should be gpio 92
<steev> bamse: tested it here, and i get a deferred device for 1dfa000 but no serror
<bamse> steev: sounds like we/you are missing some dependency then?
<steev> possibly
<steev> i'll let craftyguy look into it though :D
<bamse> well...i have the crd running, so let me cherry-pick and take it for a spin...
<steev> all i did was those 2 patches and make CRYPTO_DEV_QCE a module
<bamse> applied the one patch ontop of linux-next, built defconfig, booted the crd and "ls /sys/devices/platform/soc@0/1dfa000.crypto" returns stuff
<bamse> steev: do you not have CONFIG_QCOM_BAM_DMA ?
<steev> i see stuff in there too
<bamse> ahh, so then it did come up after all :) nice
<bamse> now we just need to know how to test it...
<steev> it's up but it says its still deferred?
<steev> and no, i don't have qcom_bam_dma
<bamse> ahh, of course...forgot that you will have some stuff in there...
<steev> let me enable bam dma too
paddymahoney has quit [Ping timeout: 480 seconds]
<steev> yeah, it was the missing bam_dma :)
paddymahoney has joined #aarch64-laptops
<macc24> i've went through most ec writes that could do /something/ on lenovo yoga slim 7x and nothing changed except now my wifi is down for some reason
<robclark> there is a physical rf-kill switch.. maybe that goes to the EC and you've triggered the sw equiv?
<robclark> (or is it a camera-kill?)
<macc24> it's a camera-kill
<macc24> i *think* i triggered the software switch
<robclark> ahh, ok, makes sense then why it doesn't do anything on linux
<macc24> that enable/disable ec stuff in dsdt just enables or disables ec interrupts
Kelsar has joined #aarch64-laptops
<agl> steev: The Problem with the pd-mapper and Sound is fixed: The following article helps me https://forum.armbian.com/topic/30415-thinkpad-x13s-remoteproc-firmware-fails-to-load-if-on-a-fast-boot-device/
macc24 has quit [Ping timeout: 480 seconds]
macc24 has joined #aarch64-laptops
<craftyguy> bamse: I enabled bam_dma and the dce kconfig options, rebooted and the system reboots when it loads the module (I think, not totally clear since I haven't figured out how to get logs from kernel when it happens)
krei-se has quit [Quit: ZNC 1.9.1 - https://znc.in]
<bamse> craftyguy: would you expect that loading loading the module would cause the device to be used immediately?
<bamse> craftyguy: i'm able to load the module and probe the device just fine on my devices (and steev did as well)...but we don't use it...
<steev> not yet :( the 6.12 kernel, i might be okay with doing an encrypted rootfs
<steev> it would be nice if someone at qualcomm *cough cough* would get the venus firmware in
<minecrell> bamse: qcom,controlled-remotely works only in combination with clocks/icc or static num-channels/qcom,num-ees properties. Otherwise you rely on pure luck that the BAM is powered on while trying to auto detect those
krei-se has joined #aarch64-laptops
macc24 has quit [Quit: WeeChat 4.4.2]
<bamse> minecrell: ohh, i see... so that could relate to https://lore.kernel.org/all/20211105035235.2392-1-steev@kali.org/ then also i presume?
<steev> oh, that very well could be, we don't have them in sdm845.dtsi
<steev> we don't have the interconnects either it seems like?
todi_away has quit []
todi has joined #aarch64-laptops
todi_away has joined #aarch64-laptops
todi has quit [Ping timeout: 480 seconds]