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: would it be possible for you to use lowercase 'b' in Tested-by when you reply to patches on the list? to keep checkpatch on my side happy?
<steev>
oh, sure, sorry about that
<steev>
need/want me to resend?
<bamse>
thanks
<bamse>
no need to resubmit, then i guess i will just have both ;)
<steev>
reminds, i should send that i tested stephen's aggregate patchset
<bamse>
b4 kindly picks up your tags with the capital 'B' and then checkpatch complains
<steev>
yep, i'll keep that in mind for the future :)
<bamse>
and i respun the backlight patches for c630, if you want something more to say tested-by to
<steev>
oh, very nice
<bamse>
just need to take them for a spin
<bamse>
but that means my c630 tree is down to the some-battery driver and dts addition
<bamse>
which also implies that i haven't been producing enough patches for that in a while ;)
<steev>
to be fair, it's mostly good at this point?
<steev>
actually
<steev>
b16ton or whatever his name is, emailed me the other day
<bamse>
once i've landed the dp integration in the display driver i will take another stab at the EC driver
<steev>
he keeps getting the dpu encoder frame timeouts
<bamse>
hmm, lots of them or every now and then?
<bamse>
well you said that you have the complaints from the web camera as well..wonder if we've screwed up something somewhere
<steev>
he said it's random (and it is) - i think it's related to the clks stuff, because i've moved back to using clk_ignore_unused and dropped the rcg2 and such
<bamse>
yeah, i talked to Stephen about clk_ignore_unused...so we concluded that it's broken and should be removed
<steev>
he's also missing the patches from lukas(sp?) for the boost freqs
<bamse>
and until we do that you have to run all qualcomm platforms with clk_ignore_unused
<steev>
this part i don't fully understand (and he uses a bit of run-on sentences so.... i'm just gonna repeat it)
<steev>
Also tried enabling spi9 to play with the fingerprint reader (spi9 is correct?) but get gserial (forget what its called the flexio type thing used for various serial protocols on snapdragon) complains with protocol 2 error
<bamse>
the geni serial hardware implements uart, i2c and spi (and some other protocols) using firmware, each driver checks if the appropriate firmware is loaded and fails if it isn't
<bamse>
so there are two possible explanations that comes to mind: 1) he's off-by-one in the translation from acpi, 2) he needs to use the GPI based access mechanism, where all accesses goes through the dma controller in the parent geni wrapper
<bamse>
perhaps there's a third one, in that qualcomm typically require only trustzone to be able to access the fingerprint hardware...but i don't know if that's applicable
<steev>
that might be, since i believe they store the fingerprint infos... somewhere
<amstan>
maybe they have it routed through the sensor hub?
<bamse>
right, but that last part relies on lenovo picking the qualcomm solution, if they just inherited something from their intel platforms it should be fine
<bamse>
amstan: i believe it's a generic geni instance (not one of the sensor-specific ones)...so there must be some magic happening in secure world
<steev>
i mean, it's lenovo so.... who knows
<bamse>
amstan: but all i can say with certainty is that there are two black boxes...
<amstan>
yeah, it's a hard field to get right. on chromeos we just gave up and used an external mcu that does the fingerprint validation, in the name of user's fingerprint privacy
<amstan>
costs more though
<steev>
i also keep trying to convince that guy to come to the irc channel to ask his questions and he's too scared for some reason
<bamse>
right, but it might be cost effective for lenovo to reuse whatever they have on intel based machines
<steev>
that's true
<steev>
i just assumed it wouldn't work because it was a goodix
<steev>
that's what the firmware says anyway, or seems to think
<steev>
bamse: i'm guessing you haven't yet sent the new backlight?
<bamse>
steev: no, need to reboot my c630
<steev>
ah
<steev>
i got a couple more radxa zeros in, and was about to reboot to test a new kernel on my c630 earlier, until i realized i was powering one of the radxa's off off of the usb ports on it
<bamse>
acpi tables indicates what interrupts its using, but i don't see which bus it sits on
<steev>
the fingerprint reader?
<bamse>
yeah
<steev>
that is something... i will not be testing
<steev>
i don't do biometrics
<bamse>
does depend on \_SB.TREE though
<bamse>
so it seems likely that it's some sort of trusted application then
<steev>
only checked the webcam stuff because my boss likes to do video for our 1:1
<bamse>
hehe, i need to get audio working reliably again, so i can do that on the c630
<steev>
it works... mostly reliably here?
<bamse>
well...maybe i've just not applied the right patches then
<steev>
there's still the popping that srinik mentioned has to do with COMP
<steev>
you need his latest ucm2 stuff
<bamse>
i think it worked fine except volume controls last time i tried
<bamse>
right
<steev>
which i believe he's actually passed up to alsa project now
<bamse>
but what do you do for microphone? headset?
<steev>
i was just testing and noticed that the cam was super jerky
<bamse>
okay, too bad
<steev>
so i ran cheese
<bamse>
hmm, that's new...
<steev>
and gstreamer started complaining that the system was too slow with > 640x480
<bamse>
it used to work really welll, but i had to use my usb-mic to get audio into it
<bamse>
it complained a little bit when i ran osb on it, but it worked fine
<bamse>
but, that was back in september :)
<steev>
yeah, 5.15 is pretty good although i think i let it run for about 15 hours and then it kinda slowed down?
<bamse>
i'm apparently on 90 days uptime on my c630
<bamse>
running next-20211101-00010
<steev>
oh dang
<steev>
i'm on 5.16.4 or 5.15.18
<steev>
and testing 5.17.0-rc2 occasionally
<bamse>
i should fix the battery driver, so i can switch to just running whatever arch linux provides me
<steev>
rc1 was actually fairly smooth minus that ITS thing
<bamse>
and then i can run linux-next on the dev-machine
<steev>
pretty sure rc2 still has it
<bamse>
although i keep having keyboard issues on the second machine...from time to time it just spams me with SYSRQ input
<steev>
i found the patch that introduces the issue... but i couldn't get git send-email to reply to it properly
<steev>
gmail just kept saying "lolno, not sending"
<bamse>
a patch in one of the pm8xxx drivers?
<steev>
no
<steev>
it's in gic
<bamse>
the thing that makes us hit that WARN_ON() during boot?
<steev>
d23bc2bc1d634
<steev>
irqchip/gic-v3-its: Postpone LPI pending table freeing and memreserve
<steev>
yeah, i believe it's doing the warnon because of a pending page?
<steev>
+ if (WARN_ON(!pend_page)) {
<steev>
+ ret = -ENOMEM;
<bamse>
yes, i've seen that on several devices...but haven't looked into it yet
<bamse>
so if you revert that it's smooth again?
<steev>
i mean, it still boots and works
<steev>
just splatty in the dmesg
<steev>
i should try reverting it though
<steev>
there were some patches in rc2 so i want to test that those fix it first
<bamse>
you do that, i'll take a break in the meantime :)
<steev>
already installing the deb
<bamse>
nice, i'll test and send out those backlight changes as soon as i have some space on my desk to power up my device
<steev>
no rush, its working currently :P
<steev>
although the current one
<bamse>
would be nice to not miss another merge window on those :)
<steev>
one thing i've noticed is that it does sometimes just randomly reset to about 50% on a boot
<steev>
ah nope, still have it with rc2, sadge
<bamse>
and it's only the webcam that you have problems with, it seems smooth otherwise?
<steev>
pretty much yeah
<steev>
i think, 5.15 is still using the "old" backlight controller ways
<steev>
not tied to that gpio or whatever
<bamse>
okay, makes me suspect that the usb performance improvements that landed recently might be worth looking at
<steev>
or that
<steev>
blah
<steev>
i thought that patch went to linux-arm-kernel, but i guess not?
<steev>
the postpone lpi
<bamse>
i haven't looked
<bamse>
but now i'm off for some dinner
<steev>
nejoy
<steev>
when audio *doesn't* work, one thing i've noticed is the whole qcom-soundwire wcd934x-soundwire.5.auto: swrm_wait_for_rd_fifo_avail err read underflow and then things just go downhill from there
<steev>
bamse: https://paste.debian.net/1229131/ that's what cheese spits out. Interestingly enough, in Cheese's interface it's the *photo resolution* that you need to set to 640x480 and not the *video* resolution to "fix" it
<steev>
maz: it seems to be some patch for dealing with kexec. but on the c630, it causes a WARN_ON. doesn't seem to affect anything, but the warning is there