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>
hm, even using johan's 6.2.0 and his defconfig, i end up with not working external
<steev>
but i also have a bunch of deferred pendings
<clover[m]>
:(
<derzahl>
thats cool. but hard to justify pricewise compared to the m1 macbook unless it has comparable power.
<steev>
eh
<derzahl>
isnt qualcomm just not able to put out a chip that rivals apple?
<derzahl>
or is it a cost issue?
<steev>
not just qualcomm
<derzahl>
ive been very impressed with the speed of my m1, but apple cant be doing magic
<derzahl>
theyre all aarch64
<derzahl>
id think that other big time arm designers could close the gap, no?
<steev>
there's more to aarch64 than just being aarch64
<derzahl>
whats apple got that others dont?
<derzahl>
any idea what the primary advantages are?
<steev>
biggest reason? they design their own chips
shoragan has quit [Quit: quit]
shoragan has joined #aarch64-laptops
<derzahl>
im sure thats a huge advantage in regards to the OSX experience, but i mean raw performance - as observed running linux on them
<HdkR>
Because they design their own CPU cores. They make them significantly more powerful
<derzahl>
an OS that likely was not given any consideration during chip design
<HdkR>
QCom has been using off the shelf Cortex cores for quite a while now
<derzahl>
oh, i thought qualcomm designed theirs as well
<HdkR>
They haven't designed their own since 32-bit SoCs
<HdkR>
But they've bought Nuvia to theoretically get back in to the custom CPU cores, but have fallen in to legal trouble with ARM about it.
<derzahl>
but regardless, to most other ARM designers - high performance and powerful cores is their objective as well
<derzahl>
so im just curious why they cant keep up
<HdkR>
Cortex doesn't reach as high as Apple's designs. ARM tries to keep their design more balanced
<derzahl>
sure, but higher ppw at least is the objective
<HdkR>
Sure, but that's the difference
<derzahl>
its not like m1's are sucking power and need heavy cooling
<HdkR>
Only has Apple's mobile phone cores but shows enough to matter
<derzahl>
cool thanks
<derzahl>
so theyre up on their own little island
<HdkR>
Apple is usually 2-3 generations ahead of Cortex in perf on average
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<steev>
okay
<steev>
so, i have external display working again, still have to do the flippy floppy on the usb-c port; and i don't know why, but it's johan's fixup commit that was breaking it here?
<robclark>
re: apple vs whatever, it's all economies of scale.. if 95% of windows laptop market was arm it would justify designing things that reach up higher into the perf aspect of balancing perf/power/price
<steev>
https://github.com/steev/linux/commits/lenovo-x13s-v6.2 pushed here, it's the fixup commit removed, otherwise johan's 6.2.0, and then the bluetooth stuff and the laptop defconfig with fedora thingies on top of the laptop defconfig
<robclark>
when it comes to printing sand.. the first core is super expensive, the n+1'th is super cheap
<steev>
added bonus of my wip fix for removing the bluetooth module not spamming warnings in the logs
<jhovold>
steev: you should not remove that fixup commit for the external display, it is needed on 6.2 and unrelated to any probe deferral issue you may have seen
<jhovold>
I've seen audio fail to probe once with the new reset driver, that gave a bunch of deferrig probe error messages
<jhovold>
it went away after a reboot and haven't seen it since
<jhovold>
(so the issue is likely still there, just not very triggered very often)
<jhovold>
bamse: yes, but as steev mentioned a range as low as 2 feet and the machine getting even warmer with bluetooth, it still seems we want a proper boardfile before enabling it generally
<jhovold>
wifi was different as having something there is better than nothing, not sure the same reasoning applies to bluetooth
<jhovold>
steev: that bluetooth regulator patch you added does not look right, regulators should already be disabled in qca_power_shutdown() called from qca_serdev_remove(). If not, you should fix that (possibly you patch adding support for x13s), not just add another explixit call to diable regulators to qca_serdev_remove()
<jhovold>
steev: indeed, you forgot to update qca_power_shutdown() when adding support for the x13s, which is what introcude the module unload warnings you reported
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #aarch64-laptops
<jhovold>
steev: in fact, the regulators would currently never be disabled on x13s (e.g. when closing the device), fixing qca_power_shutdown() as I mentioned above should address that and take care of the module unload warnings
Lucanis has quit [Ping timeout: 480 seconds]
juergh[m] is now known as juergh
juergh is now known as Guest5541
Guest5541 is now known as juergh
Lucanis has joined #aarch64-laptops
<bamse>
jhovold: are you saying that we've seen bt alone heat up the system?
<bamse>
jhovold: or are you saying that enabling bt makes steev's already poorly working wifi even warmer?
<jhovold>
bamse: the latter
<bamse>
jhovold: steev's wifi is already so bad that i think the only proper solution is to tell him not to use it
<bamse>
not hold back progress in other areas
<jhovold>
heh, maybe so. I still want to test and review things I include in my wip branches, and I haven't had time to do either yet (well, apart from finding out that the patch adding bluetooth support for x13s is broken wrt regulators that are never disabled)
<bamse>
that's perfectly fine
<jhovold>
and if it turns out that bluetooth is crappy without the boardfile I'd probably still not include it (as unlike wifi, it's not that essential)
kesslerd has joined #aarch64-laptops
kesslerd has quit [Quit: Konversation terminated!]
kesslerd has joined #aarch64-laptops
kesslerd has quit []
<steev>
in my defense, i have no idea what i'm doing :D
<steev>
and i didn't say i had to remove the fixup for probe deferral issues, i'm saying with the fixup in place, i have broken external display
<steev>
it's easy to tell because i have gdm which will use wayland by default, so if it doesn't crash at boot, and fall back to xorg, it means external display isn't gonna work
<jhovold>
wihtout that you should see "[drm] Invalid property "data-lanes", default max DP lanes = 4" in the logs, when it falls back to using four lanes for the external display
<jhovold>
things may still work, but the intention was to specify 2-lanes and that's done differently in 6.3, hence the fixup for 6.2
<jhovold>
and external display is working here
<steev>
actually, now i'm even more lost
<steev>
because i said i removed the commit, but i still see it in my tree
<steev>
and yet i also still get the message in dmesg output
<steev>
i should just give up
<jhovold>
steev: it looked it was gone when I checked this morning. Still not in it's place here:
<steev>
but this is all based on the v1 of his patchset, not v2, which changes things up, and i haven't come up with a way to override it in there
<steev>
the other way is just symlinking b8c to 08c in the firmware directory, which also works
<steev>
i haven't checked if just symlinking either of the submitted nvm patches work or not
<steev>
and it would be nice if we could have proper board file for wifi :D
<steev>
i know it exists, it would just be nice to be public
<steev>
and both his patch and mine both still have the frame reassembly failed, so there's still something missing, but i have no idea how to check that, and oddly enough, it doesn't always happen
<bamse>
steev: what's in linux-firmware from january works straight off for me...i've not added anything from windows
<bamse>
jhovold: ^^
<steev>
bamse: yes it does, but it doesn't include the nvm patch to the firmware
<bamse>
i believe there's a complaint about missing nvm...
<bamse>
right
<steev>
now i need to disclaim that i have nfi what the nvm patches do
<steev>
and id definitely rather, if they are optional (they seem to be?) not complain that the nvm isn't there
<bamse>
it probably contains something that warrants a dev_warn()
<steev>
i just assumed it was radio/regdb type stuffs, but i don't really remember much bluetooth stuff
<steev>
aha, i see what jhovold meant with the shutdown that i missed
<steev>
that's an easy quick fix
<steev>
i also, every so often get `Received HCI_IBS_WAKE_ACK in tx state 0`
<bamse>
ahh, there's another chunk of conditionals in there as well
<steev>
yeah :)
<steev>
oh interesting
falk689 has quit [Ping timeout: 480 seconds]
<steev>
jhovold: bamse: so... if i start with the usb-c device providing hdmi output plugged in, external video doesn't work, however, unplugging it and plugging it back in, it seems to initialize it?
<steev>
hrm, no, i'm wrong
<steev>
hrm, no, definitely with the data lines corrected i'm just not getting external display at all
<steev>
oh wait, i do, but yeah, i have to unplug it and plug it back in (a few times)
<steev>
and that's not strictly true either...
<steev>
it's there, it says it's working, but the hdmi while xrandr reports it is, hdmi says there's no signal
derzahl has quit [Remote host closed the connection]
laine has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
<rfs613>
oh windows, you are so strange... laptop battery was "stuck" at 88%, reports as charging, but neither goes up nor down for hours.
<rfs613>
do the old reboot... "windows is installing updates" (no I didn't tell it to do that...)
<rfs613>
finish reboot... battery charging... in 5 minutes went from 88% to 95%
<rfs613>
so was it reporting wrong all along? or not charging but also not draining (was plugged in the whole time)
<rfs613>
and yes I know this is aarch64 channel... but it was my x13s doing it, so I figured i'd share ;-)