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)
<steev>
well, dang
<steev>
yuzu says it can't use the gpu on the thinkpad :(
<HdkR>
Why's that?
<HdkR>
steev: Didn't install Vulkan correctly or something?
<steev>
according to the logs, we're missing some vk extensions?
Lucanis has quit [Remote host closed the connection]
Lucanis has joined #aarch64-laptops
<HdkR>
Interesting
<HdkR>
I'd expected the first three aren't terrible, but widelines is questionable
<steev>
i'm only on mesa 23.1.0
<steev>
and trying to switch it to opengl, it says we need opengl 4.6 and i do believe we only do 4.5?
<HdkR>
Might work if you override the version. I think the main thing they want is the spirv extension there
<HdkR>
Or if you're lucky they just check for extensions
<steev>
doesn't matter though, even on my windows box... the xbox one elite controller doesn't quite work properly with totk
<clover[m]>
You can get totk on windows?
<steev>
with yuzu, yeah
<HdkR>
It's emulation
<steev>
i don't have the switch pro controller, and not gonna try to get joycons working
mcbridematt has joined #aarch64-laptops
<steev>
qzed: i do see the efivars files in /sys/firmware/efi/efivars on the thinkpad (though i have to admit this is with 6.4.0-rc2 and pulling in the 1 patch that's needed from -next
<quinine>
I haven't tried it, but I know that yuzu totk on steam deck doesn't perform as well as switch.
jhovold has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
kitsune-tsuki has quit [Ping timeout: 480 seconds]
Xyaon has joined #aarch64-laptops
Xyaon has quit [Remote host closed the connection]
Xyaon has joined #aarch64-laptops
<Xyaon>
Hi! What's the current state of c630 development?
rmsilva_ is now known as rmsilva
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
kitsune-tsuki has joined #aarch64-laptops
agl7-x13s has joined #aarch64-laptops
_xav_ has quit [Ping timeout: 480 seconds]
<Xyaon>
What is the most functional kernel for the c630? Version 5.11 by aarch64-laptops works fine, but I'm having gpu issues with 5.15. I get the same issues with steev's 6.3.2 in addition with wifi and usb ethernet adapters not working. Are those things still under development or am I doing something wrong?
xroumegue has joined #aarch64-laptops
<ardb>
xyaon: i've been using 6.0 for a while now, but upgrading has been painful so i try to avoid it
<bryanodonoghue>
on steev's lenovo-x13s-linux-6.4.y as @ 11 days ago
<steev>
i see that occasionally here
hightower4 has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
<bamse>
xyaon: i'm running v6.4-rc1 + battery-patch on my c630, seems to work well
<Xyaon>
I figured out what I was doing wrong, the firmware files were missing from my initramfs
<bamse>
danielt: any luck figuring out why hid_sensor_hub is kicking the keyboard on c630?
<Xyaon>
has anyone got wwan working on c630?
<danielt>
bamse: I have to admit I've rather fallen behind on kernels w.r.t. C630. Haven't actually opened it in a long time...
<bamse>
danielt: you should ;)
<bamse>
danielt: i'm always on my x13s these days...so it would have been nice to fix those last few c630 pieces and "leave it" in a good state
<steev>
xyaon: you need to throw the ipa firmware into your initramfs, or, reprobe the driver, it doesn't seem to do any sort of retry if it doesn't find the firmware when it first probes
<bamse>
steev: isn't ipa a module? or it's being inserted into the ramdisk as well?
<steev>
it should be a module, i'm not sure of their setup, i just remember here that i had that issue here, so i'm assuming the ipa module gets thrown into the initramfs for reasons
<bamse>
steev: ipa, venus and remoteproc all has the problem that firmware needs to be in the same place as the module...
<bamse>
steev: so far for me though, none of them are picked up for the ramdisk...which saves me from having to stuff the firmware in there as well
<steev>
i just have an initramfs hook that tosses the ipa fw into it, it's only 33K in size
<bamse>
i don't know how to deal with this problem...we don't want to MODULE_FIRMWARE(), because that will just give us a bunch of unused firmware files in the ramdisk...
<bamse>
right, but that's a manual thing you've set up
<steev>
can we not tell it to probe defer if the firmware isn't found?
<steev>
or do we need MODULE_FIRMARE to do that
<bamse>
it will probably work...given that there are other drivers that are going to probe once the rootfs is in place...but it's a hack
<bamse>
and we don't want MODULE_FIRMWARE, becase /lib/firmware/qcom is/will be hundreds of MB
<bamse>
last time we tried to come up with a solution Linus answered me...to the tune that theregister.com wrote about it...
<steev>
yeah
<bamse>
so i've "ignored" the problem for a while now
<steev>
a number of people link that to me and ask if i've ever gotten it, and i say... no, i'm not good enough to get that kinda reply
<steev>
so, i do get my rmnet_ipa0, but, i don't recall if i've tried to actually connect
<Xyaon>
I did that and it even shows up as a network interface, but ModemManager says it is not supported by any plugin
<steev>
what distro are you using?
<steev>
and what version of modemmanager
<Xyaon>
arch
<steev>
oh, i'll let bamse talk, he's the arch guy that would know what to do there
<Xyaon>
i'm kinda new to IRC, do you just type name+colon to tag people?
<konradybcio>
not sure if QCOM_BAM_DMUX is necessary
<clover[m]>
ok i left a comment to them
<steev>
at some point... i'm planning to fold back in support for the c630 and the flex5g, since i'd like to use one kernel across all the qualcomm devices i have
<HdkR>
Apparently the render process is just crashing here
<steev>
i just run slack in the browser
<HdkR>
I'd also recommend that
<HdkR>
Anything that is just an embedded browser is going to be a pain
<HdkR>
Like Steam
<robclark>
so.. gpu-process sandbox seccomp rules are pretty arch specific.. I wouldn't be completely surprised that that falls completely over if it tries to use x86 seccomp rules on arm64
<robclark>
actually, I'd be a lot more surprised if it did work, tbh
<HdkR>
That's what --no-sandbox is for, since FEX doesn't support seccomp and we report to the application that we don't support it
<robclark>
I guess that would take fex doing some pretty heroic seccomp re-writing
<robclark>
ahh
<robclark>
but yeah, disable sandbox if you really need to (although not sure why you'd need to run a glorified web app under fexemu)
<steev>
oh nice, the orientation switching is in next now :)
<clover[m]>
one less patch then? :)
<kitsune-tsuki>
I've violated warranty only to get `gcc_ufs_phy_axi_clk status stuck at 'off'` from the kernel log
<kitsune-tsuki>
how and why UFS initialization breaks other clocks and breaks firmware-configured mipi-dsi is above me
<bamse>
robclark: have you ever had arm_smmu_get_by_fwnode() return NULL and thereby arm_smmu_probe_device() oops? i got this when probing adreno on my sc8280xp...but it doesn't show up again after a reboot, so seems to be some race...
<bamse>
kitsune-tsuki: do you boot with clk_ignore_unused pd_ignore_unused?
<robclark>
bamse: hmm, no, haven't seen that..
<kitsune-tsuki>
bamse: ofc
<bamse>
kitsune-tsuki: you'd be surprised how many times that has solved such issues :(
<bamse>
kitsune-tsuki: hopefully we'll figure out way out of that soon though...
<bamse>
robclark: trying to make sense of the code, but only thing that makes sense is if adreno_smmu is racing with gpu probing...
<robclark>
bamse: maybe the dev_get_drvdata() part returns NULL, ie. a race between probing smmu and device that uses it? Seems like that should be an -EPROBE_DEFER situation?
<bamse>
robclark: right, smmu does iommu_device_register() right before setting drvdata...
<bamse>
robclark: but i didn't think the two drivers would probe in parallel(?)
<konradybcio>
kitsune-tsuki: did you try clk_ignore_unused pd_ignore_unused in your cmdline?
<kitsune-tsuki>
konradybcio: yes
<bamse>
robclark: anyway, it happened only once...so low prio for now ;)
<bamse>
robclark: seems valid to return EPROBE_DEFER from that though...
<konradybcio>
kitsune-tsuki: you're essentially the first one to try ufs on 7180.. try cross-referencing some downstream kernel
<kitsune-tsuki>
problem #1: sc7180 lacks any UFS definition in dtsi
<konradybcio>
kitsune-tsuki: that's definitely a problem!
<kitsune-tsuki>
problem #2: new (linux 6.4) sm7150 ufs_phy and sdm845 ufs phy blow up spectacularly (screen off)
<kitsune-tsuki>
problem #3: any other com phy i've found in dtrees just spews errors
<kitsune-tsuki>
problem #4: qcom downstream is really, really different from mainline
<konradybcio>
you tell me ;)
<kitsune-tsuki>
but clocks and registers values are same, thank goddess
<kitsune-tsuki>
but that doesn't exactly helps when they are the same as in mainline
<kitsune-tsuki>
which doesnt work
<konradybcio>
did you confirm that with debugcc?
<konradybcio>
linux only shows you what the thinks the state is
<kitsune-tsuki>
errr
<kitsune-tsuki>
i'm talking about values in dts and dtsi
<kitsune-tsuki>
not about what is in hardware registers
<kitsune-tsuki>
and I also have decompiled acpi table
<kitsune-tsuki>
said acpi table is enough for windows installer to recognize and use ufs
<kitsune-tsuki>
which is hilarious because said acpi table is _not_ enough for that installer to recognize keyboard and touchpad
<Libre____>
hey I haven't read scrollback and I imagine you get this question all the time, but is X13s usable as a daily driver? How much time would it take to get to a fedora arm64 desktop?
<Libre____>
my x86 thinkpad is starting to show early warning signs of failure...