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
<alexVinarskis[m]>
oh thats nice. on XPS retimer shields are soldered.
<valpackett>
no retimers under the tiny shield.. literally just the connectors themselves haha
<valpackett>
the retimers might be on the other side..
<valpackett>
inserted the windoze ssd to see if there's new dsp firmware to get.. and to measure power consumption.. so far it's far worse than linux just because of all the background crap :D
<valpackett>
ok, the actual target with screen showing static content at min brightness and nothing happening is 3 W. I think it's literally mostly just PSR that we're missing
<valpackett>
oh, no, it got down to 2.4W
tobhe has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
hexdump01 has quit [Ping timeout: 480 seconds]
fantom_ has quit [Ping timeout: 480 seconds]
<valpackett>
OK, here's my whole dev branch with newly edited to-be-submitted-as-v2 patches for dell thena: https://files.catbox.moe/k64ilx.gz
<valpackett>
just uploaded a tarball of patches because github is being github
<sgerhold>
valpackett: The comment about the WiFi regulator still applies (partially) to soldered M.2 cards. The point is that we’re modeling the internal design of the M.2 card (regulators etc) as part of the device tree for the mainboard, even though that’s completely independent
<JensGlathe[m]>
I didn't understand the reason for that. Does pwrseq do anything with this info?
SpieringsAE has joined #aarch64-laptops
<JensGlathe[m]>
And, more important: Does the completely independent internal structure of the card actually care?
jhovold has joined #aarch64-laptops
<sgerhold>
JensGlathe[m]: The M.2 card (no matter if removable or soldered) doesn’t really care much about the PMU and individual regulator stuff we’re modeling right now. M.2 has pins for 3.3V/1.8V supplies and „wireless disable“ GPIOs for WiFi/BT. Ideally that’s what we should model instead of the whole PMU boilerplate.
<JensGlathe[m]>
😈 you know what I would be asking next
<sgerhold>
If you look at all the boilerplate in the BT patch it really just breaks down to a verbose version of that. Only the 3.3V regulator really exists, the other defined ones are effectively dummy
<JensGlathe[m]>
so if it boils down to vreg_wcn_3p3 anf gpio 116/117, why all the hassle. the pmu driver does some stoff on probe. Could it work with this info alone?
fantom has joined #aarch64-laptops
<sgerhold>
JensGlathe[m]: The BT bindings were written to require defining that PMU, and we haven’t come to a conclusion how to model it properly (also because the M.2 standard has its limits, there is often subtly vendor-specific stuff as well)
ravikant_ has joined #aarch64-laptops
<sgerhold>
Ideally we should have some node representing the M.2 connector rather than the PMU from inside the M.2 card
<JensGlathe[m]>
So it boils down to "do I need all the pmu internals if they are mostly inconsequential" for bt
<sgerhold>
JensGlathe[m]: The answer is pretty clearly "no" for the M.2 case, which is why we've been "blocking" all the BT patches so far
<sgerhold>
But the problem is that we don't have something better currently, and the discussion has kind of stalled
<jhovold>
valpackett: we're missing skin temperature throttling on x1e
<jhovold>
the fw will prevent the cpus from melting, but they can still generate too much heat
<jhovold>
that could burn your fingers or lap
<jhovold>
and cause other effects, like throttling charging so that your battery depletes during length compilations
<jhovold>
and possibly cause other stability issues
<jhovold>
Here's an updated wip branch for the X13s:
<lynxy>
which commit addresses the xps power button, out of curiosity?
<JensGlathe[m]>
pm8010 it should be
<lynxy>
ah, i see- thanks!
<lynxy>
hmm, built & installed but the power button still doesn't appear to behave
Danct12 has joined #aarch64-laptops
<alexVinarskis[m]>
Do you have any spmi and/or pmic related errors in dmesg? I actually tried to reproduce it yesterday, but couldn't anymore - now my power button always works even without the fix. Only thing that changed was bios 2.2.0->2.8.x update.
<lynxy>
nothing on spmi, and pmic output- at least for the pmic_pwrkey- looks fine
<lynxy>
i did just get a weird boot which i've never had before- screen flashed full brightness white with a glitchy look and hung
<lynxy>
bah, i'm just putting of revising by working on something more interesting- i'll be back after the databases exam this evening
<lynxy>
putting off*
anthony25 has quit [Remote host closed the connection]
anthony25 has joined #aarch64-laptops
martiert_ has joined #aarch64-laptops
martiert_work has quit [Ping timeout: 480 seconds]
ravikant_ has quit [Ping timeout: 480 seconds]
<jhovold>
lynxy: thanks for testing, now get back to the books ;)
sally_ has joined #aarch64-laptops
<jhovold>
alexVinarskis[m]: perhaps you can respin that patch and drop the reference to the power button if it now seems unrelated?
<jhovold>
that also makes backporting to stable less of an issue, what did does probe errors look like?
<alexVinarskis[m]>
Yes I am planning to do a few more tests including BIOS downgrade to reproduce it, and will update or respin accordingly. It certainly was correlated, as previously I had to disable pm8010 to get power button working, but seems there yet something else.
sally has quit [Ping timeout: 480 seconds]
<jhovold>
alexVinarskis[m]: I don't think you need to downgrade the bios just for this, perhaps compare with which version lynxy or someone else using
<jhovold>
iiuc, the issue is gone with your machine regardless of the patch, and lynxy still has it with the patch
<jhovold>
bamse: do you have any issues with the power button on your xps?
<jhovold>
alexVinarskis[m]: you patch is correct either way, but it would be good to determine how it relates to the power button issue
Ariadne has quit [Read error: Connection reset by peer]
ravikant_ has joined #aarch64-laptops
Ariadne has joined #aarch64-laptops
<alexVinarskis[m]>
<jhovold> "iiuc, the issue is gone with..." <- Right now - yes. The thing is that some 4-6 months ago the power button only worked with this patch, so I thought to dig a bit more info. Otherwise you are right, I will respin to drop correlation to power if i cannot prove it (anymore).
<jhovold>
sounds good, if there is a bug lurking somewhere in the spmi implementation it would be good to track it down
<jhovold>
perhaps something is just hidden by changes in timing, can you go back to an older kernel which you had the issue and see if it's still there with the new bios?
<jhovold>
know*
<alexVinarskis[m]>
good point, yes I will try that.