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)
<bamse> steev: those are wrong...
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> wrong in what way?
<steev> gwolf: can you give me the output of cat /sys/firmware/devicetree/base/soc@0/geniqup@ac0000/i2c@a88000/bridge@2c/aux-bus/panel/compatible
<bamse> steev: something is broken (not the prints)
<steev> could it be something where i have something built in, and something being a module?
<steev> GCC,GPUCC,and interconnects are all =y
<bamse> steev: the latter two seems to indicate that bwmon never probed
<bamse> and the first two says that gpu never probed
<steev> well
<bamse> do you have anything related to eiher one of those earlier in the log?
<steev> that would definitely be true because apparently i do not have QCOM_ICC_BWMON set
<steev> how the hell that dropped, i have no idea
<steev> gpu is definitely probed
<bamse> computer says no...
<bamse> did it probe shortley thereafter?
<steev> don't believe so, it should have probed long before that, and glxinfo definitely shows i'm using FD690
<steev> those are some of the last messages in dmesg at boot
<steev> https://paste.debian.net/hidden/e3437daf/ the full dmesg output - the bits starting around 14471 are me installing the bwmon enabled kernel
<steev> wanted to throw it out before i reboot it
<bamse> looks weird, not sure why it says so
<steev> hm, bwmon is set to module but it isn't loading
<steev> er, apparently it's not
<steev> 3rd times the charm... i saw it actually build the module this time
<steev> okay the latter 2 were definitely bwmon not showing up
<steev> i definitely have the gpu
<steev> oh well, i don't have a holiday tomorrow, and so, 9am meeting, so, i should get to bed
<bamse> steev: have a good night
<steev> gpu definitely works, but i do see the gcc/gpucc messages (and the whole pmic glink messages)
<steev> https://paste.debian.net/hidden/6c13fb3b/ with bwmon as a module, just those messages, the audio splat... and i suppose at some point i should try to figure out wtf the -84 frame reassembly failure thing is for bluetooth
<steev> if anyone wants to play, it's lenovo-x13s-v6.4.0-rc7-hot (because it has my make it hotter patch applied)
<HdkR> I like the Make it spicy™ patch.
jhovold has joined #aarch64-laptops
<cenunix[m]> For some reason audio is much quieter on the x13s when running NixOS. I know that some firmware stuff is required for pd-mapper to get audio working in general, is there anything else that goes into audio besides the firmware in firmware/qcom/sc8280xp/LENOVO/21BX
<cenunix[m]> That might be affecting the overall volume of the audio ? I’ve tried alsa-ucm, both the linaro patch and one from the nix repos, volume doesn’t seem to increase though
szclsya[m] has quit [Quit: Bridge terminating on SIGTERM]
robertmader[m] has quit [Quit: Bridge terminating on SIGTERM]
Bioxvirizm-x13s[m] has quit [Quit: Bridge terminating on SIGTERM]
NomadNaomie[m] has quit [Quit: Bridge terminating on SIGTERM]
Las[m] has quit [Quit: Bridge terminating on SIGTERM]
danielt has quit [Quit: Bridge terminating on SIGTERM]
davidebeatrici[m] has quit [Quit: Bridge terminating on SIGTERM]
sporos11[m] has quit [Quit: Bridge terminating on SIGTERM]
quinine has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit [Quit: Bridge terminating on SIGTERM]
travmurav[m] has quit [Quit: Bridge terminating on SIGTERM]
aigotchi[m] has quit [Quit: Bridge terminating on SIGTERM]
_`[m]1 has quit []
ajhalaney[m] has quit [Quit: Bridge terminating on SIGTERM]
EricCurtin[m] has quit [Quit: Bridge terminating on SIGTERM]
qzed has quit [Quit: Bridge terminating on SIGTERM]
ungeskriptet[m] has quit []
Sobek[m] has quit [Quit: Bridge terminating on SIGTERM]
mike1922[m] has quit [Quit: Bridge terminating on SIGTERM]
mothenjoyer69 has quit [Quit: Bridge terminating on SIGTERM]
martijnbraam has quit [Quit: Bridge terminating on SIGTERM]
harvests[m] has quit [Quit: Bridge terminating on SIGTERM]
emily[m] has quit [Quit: Bridge terminating on SIGTERM]
hlr[m] has quit [Quit: Bridge terminating on SIGTERM]
wiizzard has quit [Quit: Bridge terminating on SIGTERM]
akawolf[m] has quit [Quit: Bridge terminating on SIGTERM]
Leandro[m] has quit [Quit: Bridge terminating on SIGTERM]
luxio_39[m] has quit [Quit: Bridge terminating on SIGTERM]
Prawn[m] has quit [Quit: Bridge terminating on SIGTERM]
ArtyomK[m] has quit [Quit: Bridge terminating on SIGTERM]
saekau[m] has quit [Quit: Bridge terminating on SIGTERM]
Lucy[m] has quit [Quit: Bridge terminating on SIGTERM]
AlexMarty[m] has quit [Quit: Bridge terminating on SIGTERM]
lun[m] has quit [Quit: Bridge terminating on SIGTERM]
mahmoudajawad[m] has quit [Quit: Bridge terminating on SIGTERM]
harvestz[m] has quit [Quit: Bridge terminating on SIGTERM]
owc[m] has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Write error: connection closed]
firlaev-hans-fiete[m] has quit [Write error: connection closed]
Dylanger has quit [Write error: connection closed]
clover[m] has quit [Write error: connection closed]
Stirl[m] has quit [Write error: connection closed]
Nao[m] has quit [Write error: connection closed]
juergh has quit [Write error: connection closed]
shjim[m] has quit [Write error: connection closed]
baspar[m] has quit [Write error: connection closed]
cenunix[m] has quit [Write error: connection closed]
jenneron[m] has quit []
go4godvin has quit [Quit: Bridge terminating on SIGTERM]
Cyrinux9 has quit []
Cyrinux9 has joined #aarch64-laptops
<steev> much quieter than what
<HdkR> We'll never know since the matrix bridge died :D
<steev> oh, they're still gone
iivanov has joined #aarch64-laptops
agl7-Galaxy has joined #aarch64-laptops
agl7-Galaxy has quit []
xroumegue has quit [Ping timeout: 480 seconds]
chesterlintw has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<gwolf> steev: Ugh, I'll send myself a note and will give it to you when I'm back at the C630
<gwolf> (if I had connected to IRC yesterday night...)
<steev> gwolf: no worries or rush - it's related to a patch
<jhovold> steve and others using my wip branches for the x13s: here's an updated branch based on rc7:
<jhovold> steev: ^
<jhovold> changes include:
<jhovold> - drm lifetime fixes
<steev> what is drm lifetime?
clover[m] has joined #aarch64-laptops
<clover[m]> Not sure. But when you build a kernel are you using laptop defconfig, cenunix?
<jhovold> steev: minor fixes to the drm driver fixing lifetime issues that could lead to a use-after-free
<steev> ahh
<clover[m]> ...why did 85 people leave the room just now?
<steev> because matrix had issues earlier
chesterlintw has quit [Ping timeout: 480 seconds]
<clover[m]> HandleLidSwitchExternalPower seems to work, but HandleLidSwitchDocked doesn't. if i have external displays connected and close my laptop lid it will just do default HandleLidSwitch behavior
<gwolf> steev: I've been lazy (or short-on-time-to-debug), and am still running 5.19
<gwolf> One day I'll have time to understand why my 6.3 is not behaving... Or not :-]
<steev> gwolf: shouldn't matter, i just need to know what panel it says you have :)
<gwolf> OK
<gwolf> Will tell you by this evening.
<steev> no rush at all, i didn't get much sleep thanks to this heat wave (my apartment was still almost 28c inside with the ac not keeping up) plus the kid downstairs not sleeping well either meant the rest of us got to stay up
<gwolf> We share your heat wave, all the way down to our Southern border :-(
konradybcio has joined #aarch64-laptops
<konradybcio> just dropped an experimental series on the list, with possibly better idle management.. please give it a spin and tell me if there are any improvements
<steev> oh i can throw those in while i'm doing the new johan stuff
<steev> konradybcio: i assume the gpucc/gcc ones might deal with the sync_state thing?
<konradybcio> what sync_state thing?
<steev> ignore the bottom 2, i somehow lost bwmon
<konradybcio> oh no that's because sync_state happened before the gmu got to probe
<konradybcio> it should resolve later, without telling you
<steev> it does, i assume since things don't seem broken
Xyaon has joined #aarch64-laptops
<minecrell> konradybcio: if you don't trust downstream for the idle states, wouldn't it be better to take them from acpi?
<konradybcio> they're hardcoded in qcpep I believe
kindergardenn has joined #aarch64-laptops
<minecrell> konradybcio: there is some ARM standard for this that is used on the sc7180 WoA at least, dunno about x13s
<konradybcio> can you point me to it?
kindergardenn has quit []
<minecrell> konradybcio: sure, ifff I find it again xD
<minecrell> It's quite funny how they defined it, there is a magic OperationRegion() (normally used for MMIO etc stuff) where first the registers are "written" and then a SMC is triggered
<konradybcio> also funny how all of the time values are aligned to n*100
<minecrell> konradybcio: on sc7180 the timings seem to match atoll-pm.dtsi exactly, although iirc some of the psci ids were slightly different
<steev> jhovold: do you also see the audio splat on your 6.4.0-rc7?
<akaWolf0> someone has the schematic of x13s?
<jhovold> steev: no, no new issues with audio in rc7 (nor with the interconnects but that could be related to the sync_state patches you added on top I guess)
<steev> it might be related to us going in and manually unmuting the earphone jack
<jhovold> i'm just using the speakers for testing here
<clover[m]> what's the difference between a blob and a splat
iivanov has quit [Ping timeout: 480 seconds]
amstan has joined #aarch64-laptops
<amstan> clover: why does this feel like a... why did the kernel splat cross the road joke?
<amstan> pretty sure i've heard the term splat used in conjunction of errors, like you just get this paragraph of a backtrace and you're supposed to figure out what went wrong
<akaWolf0> steev: why do you enable that make hot patch? what's the temperature it is going up to?
<amstan> blob is a bunch of binary data, usually refering to something that got compiled, don't have the source of and is kind of a black box
<steev> akaWolf0: 65c instead of 55c
<akaWolf0> really no one here has no schematic of x13s while developing for it?
<steev> i'm sure some do, i'm not sure if they can say they do
<steev> it's usually better to just ask your actual question instead of asking if someone is around who has something and waiting for a response
<steev> as for why i enable it, because then the laptop gets hotter before it starts throttling - https://github.com/steev/linux/commit/6cedced75eb5ec70f59c98a202ba8dd3e4e224c2
<steev> ?
<steev> i don't follow why you're linking me that, nor what i'm supposed to do with the info
<steev> i do it because it's what *i* desire. you do not have to use the patch, i drop it from the public stuff i push, but there are a few others who use theirs with active cooling/colder areas and want the longer times at higher freqs
<akaWolf0> steev: actual question is how charging subsystem functionated? I still remember the case when my laptop overdischarged whilst was on delivery and didn't turn on until I took it to service where they are charged battery directly.
<akaWolf0> and I would like to know if it still suffers of this or no
<steev> has your laptop overdischarged since?
<akaWolf0> steev: regarding link: I just wanted to highlight that high temperature is not too good for li-ion battery
<steev> then don't run with the patch that i don't include
<akaWolf0> steev: nop, it din't, but I explicitly keep the charging level high enough, since it's problematic for me to go to service here (in Argentina)
<steev> keeping it at 35C though is, kinda ridiculous, why even bother using a system at that point
Xyaon has quit [Ping timeout: 480 seconds]
calebccff_ has joined #aarch64-laptops
calebccff has quit [Ping timeout: 480 seconds]
<exeat> you should rename your patch to "preclude sluggish electrochemistry" :)
calebccff_ is now known as calebccff
calebccff has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
calebccff has joined #aarch64-laptops
<exeat> Anyway, battery temp tends to stay well below skin temp, if those sensors are to be believed
kettenis has quit [Remote host closed the connection]
<exeat> (I now believe skin_temp_thermal-virtual-0 after measuring the bottom cover temperature)
<steev> mani did good :)