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
<derzahl> their ppw has got to be excellant
<HdkR> They are sucking more than Snapdragon
<HdkR> M1 Max peaks out at 60w
<derzahl> i wonder how Ampere stacks up
<HdkR> Easy enough comparison on SPECInt shows the perf difference
<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> 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
<steev> rob is correct
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> also, for debian types, i pushed my fork of alsa-ucm-conf to
iivanov has joined #aarch64-laptops
<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> steev: we're talking about "fixup: arm64: dts: sc8280xp: fix external display 'data-lanes'" right?
<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> right, but it is locally
<steev> so i have no idea wtf i pushed
<jhovold> heh
<steev> And, the Bluetooth stuff… I started working on it so I’d have some audio, and also to kinda learn these things
<steev> With audio mostly working, I don’t need it
<jhovold> we'll get it sorted, i just haven't had time to test or review it yet
<steev> And Tim is working on the qca2066 driver which also works for ours
<steev> Since he did say it’s the same chip
<steev> BUT his gets the wrong board family
<steev> Chip family
<steev> He says the firmware we have comes from android and idk
<jhovold> you got it working which is what matters, the rest can always be hashed out later
<jhovold> yeah, that was a bit surprising
<jhovold> didn't bamse say the bluetooth fw was now in linux-next even? would that be the "android" fw then?
<steev> no
<steev> let me back up
<steev> the firmware itself is in linux-next
<steev> what isn't in next are the nvm patches
<steev> the nvm patches that were submitted are the 301/302 files
<steev> ours, as you know, is b8c
<steev> his method of figuring out which nvm patch to use, gives us an id of 08c
<steev> regardless, they only submitted a couple of nvm patches, and we probably need lenovo to submit their nvm patches
<jhovold> but apart from the naming, those nvm files from the windows installation seem to work?
<jhovold> right
<steev> yes
<steev> [ 7.769131] Bluetooth: hci0: QCA board ID len 2,id = 0 8c
<steev> [ 7.769137] Bluetooth: hci0: QCA Downloading qca/hpnv21.b8c
<steev> [ 8.027120] Bluetooth: hci0: QCA setup on UART is completed
<steev> because i have a hack in place that if the id is 0, become b
<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 ;-)
laine has joined #aarch64-laptops