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)
Lucanis0 has quit []
Lucanis has joined #aarch64-laptops
Mathew has joined #aarch64-laptops
Mathew has quit [Remote host closed the connection]
mcbridematt has quit [Ping timeout: 480 seconds]
mcbridematt has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
retroctrl has joined #aarch64-laptops
<steev>
jhovold: in good/bad news... my headphones don't work with your 6.4 branch and your config. good for me, means it's not something i broke :)
<steev>
if i unmute EAR_RDAC in alsamixer though, they play audio just fine (rather loud actually), but i do still get the unbalanced irq
<steev>
maybe because mine have a mic? since they're the iphone headphones back when iphones had a headphone jack?
retroctrl has quit [Quit: Leaving]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<bamse>
jhovold: booted linux-next on my x13s without the modem...pcie3a obviously fails to find a device...but the result is that the interconnect driver doesn't hit sync_state, and all busses are kept at max
<bamse>
mani_s, abelvesa: ^^
svarbanov has joined #aarch64-laptops
<steev>
just put a modem in it
<steev>
hm
<steev>
and now headphones don't work with 6.3.10, but they did with 6.3.9, so at least i have a general idea of what to check
<steev>
no, they do, just not every boot
justanotherpersoncallednathan[ has joined #aarch64-laptops
justanotherpersoncallednathan[ has left #aarch64-laptops [#aarch64-laptops]
<jhovold>
qzed: thanks, i'll take a look at the updated series
<jhovold>
and regarding the extra device, i meant that it could be added unconditionally by the scm driver without being descibed in DT (unlike in v3)
<jhovold>
but that would perhaps require exposing some more scm internals again
<jhovold>
steev: ok, good (bad). :)
<jhovold>
sounds like jack detect is broken, and fails to detect your headphones properly
<jhovold>
clover[m] apparently had a similar issue with a pair without a mic, but otherwise the variants with switched gnd/mic connection sounds like a good guess as to why some headphones work and not others
moa5505 has joined #aarch64-laptops
<moa5505>
@hexdump01: Thanks !
<jhovold>
bamse, abelvesa: ouch, have some of the sync state work already been merged for 6.5 and could be involved here?
<jhovold>
i don't have a modem either and don't see why that would prevent hitting the sync state, the pcie controller is still bound to a driver
<moa5505>
@Jenneron: Do you have a compiled version somewhere ?
<jhovold>
or should be...
<jenneron[m]>
moa5505: you don't want it for a new device
<moa5505>
Okay, I'll try to do it myself
<moa5505>
Thanks again !
<jhovold>
steev: i just borrowed a pair of in-ear phone headphones (with mic and button) and they worked here as well
<jhovold>
i'm not seeing those wcd938x_mbhc_get_result_params errors your log had, which indeed points to jack detection
<jhovold>
did you say the headphones that does not work were from apple? perhaps they are doing something funky which throws the driver off
<jhovold>
srinik: ^
<jenneron[m]>
<moa5505> "Okay, I'll try to do it myself" <- but don't boot with flex 5g dtb if you have another device
<jenneron[m]>
the most important thing before booting is to adjust regulators
<jenneron[m]>
you should be able to find what you need to get into it on that page
Vectorboost has joined #aarch64-laptops
<jhovold>
steev: you also have one more error in your log during probe which I have not seen before:
<jhovold>
wcd938x_codec audio-codec: ASoC: error at soc_component_read_no_lock on audio-codec for register: [0x000034b0] -16
<jhovold>
no idea, what that's about
<jhovold>
srinik: ^
<moa5505>
Thanks Jenneron, I'll take a look!
<jhovold>
steev: i would not be surprised if your headphone issues are related to that error though
<jhovold>
the driver fails to determine the codec variant and skips some initialisation when that happens
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
ptitSeb has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
Vectorboost has quit [Remote host closed the connection]
Vectorboost has joined #aarch64-laptops
<jhovold>
steev: can you check if that it error is there also with 6.3 or whichever kernel works for you?
<jhovold>
It seems you said it works sometimes with 6.3, which seems to indicate yet another audio race during boot
svarbanov has joined #aarch64-laptops
ptitSeb_ has joined #aarch64-laptops
ptitSeb has quit [Ping timeout: 480 seconds]
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #aarch64-laptops
<jhovold>
steev: looks like the codec driver is trying to access the bus without first making sure it is resumed (hence the -EBUSY)
<jhovold>
try reverting "soundwire: qcom: enable runtime pm before controller is registered" which is only there to paper over a different audio race by changing the timing during boot
<jhovold>
the codec driver still looks broken, but try that revert anyway
svarbanov has quit [Ping timeout: 480 seconds]
Vectorboost has quit [Quit: Leaving]
Xyaon has quit [Ping timeout: 480 seconds]
svarbanov has joined #aarch64-laptops
svarbanov has quit [Ping timeout: 480 seconds]
ptitSeb has joined #aarch64-laptops
ptitSeb_ has quit [Ping timeout: 480 seconds]
<bamse>
jhovold: dw_pcie_host_init() returns -ETIMEDOUT, because "Phy link never came up"...and that becomes the return value of qcom_pcie_probe()...and sync_state will forever wait, as the device didn't probe successfully
<bamse>
jhovold: so it's in the same boat as venus, which errors out of probe because the firmware isn't there
<bamse>
jhovold: doesn't sound right that sync_state should continue waiting for devices that isn't probe deferring
<jhovold>
bamse: but that's clearly a regression in the pcie driver as it should not return -ETIMEOUT just because the link is not up
<jhovold>
so i'd say it's a different issue than the one with venus and missing fw
<bamse>
jhovold: i'm pretty sure it always did that...
<jhovold>
no, don't have a modem on pcie3 either and the driver is still bound as it should be
<bamse>
da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started")
<jhovold>
da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") may be the cause of the regression jusdging from a very quick look
<jhovold>
heh
<bamse>
do you mind reporting it?
<jhovold>
sure, i can do so
<bamse>
thanks
<bamse>
but i am still wondering if it's reasonable for a failing probe function to hold back sync_state
<bamse>
it's not an issue that will be resolved...and the driver had it's chance to settle the hardware state...
<jhovold>
sure, that's still an issue, but not a new one
<bamse>
right
<broonie>
You'd need to distinguish deferred probe there (though that also may never complete)
<bamse>
broonie: absolutely
<bamse>
broonie: it's not clear to me yet what would be the appropropriate way to handle these "corner cases"
* broonie
generally has concerns about the extent to which it groups things together.
<bamse>
that it's don't on a per-provider basis, and not individual resources?
<bamse>
s/don't/done/
<broonie>
Yes, but for things like MFDs that can be the whole MFD.
<bamse>
ahh
<bamse>
that can be pretty sad
<bamse>
on the qcom platform, we currentyl have the interconnect drivers voting for a lot of bandwidth, and they are all entangled...so if any one device fails to hit sync_state we waste many hours of battery
svarbanov has joined #aarch64-laptops
agl7-Galaxy has joined #aarch64-laptops
<agl7-Galaxy>
Good Evening (here in Europe is it 6:20 pm)
agl7-Galaxy_ has joined #aarch64-laptops
agl7-Galaxy has quit [Ping timeout: 480 seconds]
agl7-Galaxy__ has joined #aarch64-laptops
agl7-Galaxy_ has quit [Ping timeout: 480 seconds]
agl7-Galaxy__ is now known as agl7-Galaxy
agl7-Galaxy has quit [Quit: Leaving]
moa5505 has quit [Remote host closed the connection]
agl7-Galaxy has joined #aarch64-laptops
agl7-Galaxy has quit []
agl7-Galaxy has joined #aarch64-laptops
<steev>
jhovold: reverting that commit didn't help, you are probably right that whatever the "... register: [0x000034b0] -16" message is, is related, because on 6.3.10, when headphones don't work, that message also pops in, i do not see it on 6.3.9
<broonie>
steev: jhovold: I'm not seeing any runtime PM in the interrupt handlers for wcd-mbhc-v2, dunno if the driver ends up thinking it can suspend the CODEC while jack detection is active?
<broonie>
It might be being kept active somewhere else.