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> oh, right, i remember seeing that series
flowriser has quit [Quit: Konversation terminated!]
<steev> qzed: blergh, your qmp patches will need to be redone it looks like, since it's split out now
<qzed> yeah, I already have that at some older next branch... if we're lucky that still works
<steev> at least it's pretty easy
<steev> ah yeah, you did the reverts yeah
<steev> that's a lot of reverts :(
<qzed> yeah, two series... tried to look a bit into it but at some point I gave up and just reverted that stuff
<qzed> in hopes that people who understand that better figure it out xD
<qzed> the OPP thing was something with cpu frequency scaling and multiple clocks
<qzed> and the deferred probe thing caused issues with the panel not working
<steev> that's what we have bamse for... all i'm good for is an edit of the dts here and there, these days :(
<jenneron[m]> is there any version of some-battery driver with support of 2+ devices? We're looking at this https://github.com/andersson/kernel/commit/aed863b9fa2e11c6383c83e0a52b1707f612e49f and surface rt has similar thing, should be possible to have a common driver with device-specific regmaps
<steev> some-battery isn't a real driver
<steev> it'll never be submitted anyway, really we should be rewriting it for the ec
<steev> bamse just wrote it to give us some kinda battery info
<jenneron[m]> so, what is the proper way to get these ECs upstreamed?
hexdump01 has joined #aarch64-laptops
<steev> i don't know - probably a driver under mfd - the c630 has an ENE KB9022G or something
<steev> OTOH
<steev> you could always modify the some-battery driver, and use it until a proper driver is ready
<steev> qzed: bleh, new next has more stuff that i'm guessing is supposed to fix some of those reverts
<qzed> i'd guess that the opp thing is probably fixed by now, seemed like that should have affected a bunch of qcom devices, not just sc8180x
<qzed> but I haven't looked into that since then
<steev> yeah, i was trying to just revert the devlink crap
<steev> i mean, i'm sure it's good in theory
<qzed> yeah, that edp thing seems to be a bit picky... so probably some weird edge case
<steev> i'm sure bamse, lumag, abnihav and friends will all sort it out
<steev> i'm happy (enough) with 5.19 so far
mani_s has joined #aarch64-laptops
shawnguo has joined #aarch64-laptops
<bamse> qzed: ugh, that's a large list to drop...
vkoul has joined #aarch64-laptops
<bamse> jenneron[m]: in addition to battery info, the EC deals with USB-C and in particular displayport...so i've been thinking about updating the design now that we're figuring out how the other side of the USB/DP interaction should look like
<bamse> steev: and while the chip it runs on seems to be a KB9022G...i think the protocol is specific to the device :/
<steev> oh, that is fun
srinik has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
<travmurav[m]> Hi, I was writing a DT for an 7c gen1 based Acer Aspire 1. I see the thing is based on "QSIP7180" module (SoC/ram/emmc/two pmics/wifi/(modem)), does it make sense to try separating it out into some sc7180-qsip.dtsi? Would at least be two pmics, their regulators and -supply properties for things like usb and wifi/bt as I can tell
hexdump01 has quit [Ping timeout: 480 seconds]
<bamse> travmurav[m]: if you believe we'll have more devices on the qsip it might be worth doing...but i probably would prefer to just have the dts and then we can break it appart when the second thing arrives
<travmurav[m]> Yeah, I guess I'll leave it all in one file for now then, thanks!
flowriser has joined #aarch64-laptops
flowriser has quit []
jhovold has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
falk689 has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov__ has quit [Read error: Connection reset by peer]
iivanov has joined #aarch64-laptops
iivanov has quit []
<robclark> many, but not all, of the sc7180 chromebooks are using qsip.. I suspect the state is the same on WoA laptops (some but not all are using qsip).. no idea if the WoA and chromebook qsip's are the same. At any rate, dianders is probably the sort of person who'd have opinions about the dtsi organization
<dianders> Yeah, what robclark said. Many but not all sc7180 Chromebooks are QSIP. Definitely considered trying to represent QSIP in the dtsi file but in the end we didn't. If someone really wanted to try to reorganize to abstract out QSIP they could but it probably wouldn't be worth it.
<dianders> On sc7280 we've tried to abstract out the similar concept (qcard) and we'll see if that was a good idea or if we end up needing to roll it back in to the separate dtsi files... Device tree organization is more art than science, unfortunately. :(
<travmurav[m]> Right, after filling my DT a bit more I got a feeling that it'd be both a bit empty and also require maybe a bit too much careful thinking on naming the node labels for example
<dianders> leezu: Both Power-Refresh and an update of Cr50 will cause EC to reboot. I'm kinda confused about how the EC got into such a wonky state.
<travmurav[m]> Unrelated to this, I see that my laptop crashes somewhere in the efi stuff on poweroff/reboot, is there some magic needed on WoA boards that is not needed on chromebooks?
<travmurav[m]> it's kinda annoying to have to hold the button every time...
<dianders> travmurav[m]: Sorry, don't actually know much about WoA / efi, but I assume bamse or someone else who's been working on getting Linux on WoA laptops will chime in. ;-)
<steev> travmurav[m]: not sure if this is still needed (i haven't been carrying the patch in a while but forgot) but maybe something like this is needed for you - https://github.com/linux-surface/kernel/commit/7efa7e92f6991c9e9f6d531a663d789fe2619798
<travmurav[m]> Oh interesting
<qzed> ah, steev got there first
<travmurav[m]> but for me it's a hang with lots of kernel oops spam (when I had efifb at least)
<travmurav[m]> ah, it will fordce psci I see
<steev> i get that occasionally here, not every time
<qzed> qualcomm locks down direct efi access (at least to efi variables), and this somehow also breaks some other efi function, including power-off stuff
<qzed> I did want to look into this at some point... but that might be far off
<qzed> for efi variables, there's some service in TZ/as TZ app (so you essentially call that via a scm call)
<qzed> but I'd really like to know why efi poweroff is broken and what windows does here
<travmurav[m]> locking stuff down indeed sounds like qcom... Wonder if the RTC is still locked down here
<travmurav[m]> hm, I remember overseeing that _zap.mbn is whatever "unlocks" the gpu and I need it (renamed from qcdxkmsuc7180.mbn) so the laptop doesn't crash?
<qzed> not sure what that does, but yeah, the qcdx-thing is zap and it's apparently signed, so you need to copy that from windows
<travmurav[m]> hm I think this either didnt work or it doesn't know the file is needed, I just gave it firmware at runtime and got "Zap shader not enabled - using SECVID_TRUST_CNTL instead"
<qzed> I only know that it needs to be specified in the DT, but if that's already there then I have no idea
<travmurav[m]> ah
<travmurav[m]> I probably didn't specify that then, thanks
<travmurav[m]> I was mainly looking at the 7c chromebooks that I suppose don't need it
<travmurav[m]> a-ha, gpu works now, thanks!
<steev> hype
<travmurav[m]> hacking false into the efi_poweroff_required() seem to have not helped though
* travmurav[m] reminds himself that he should reboot twice to test reboot-related bugs
<steev> qzed: fwiw, building in the display stuff doesn't seem to help the reliability on the flex 5g :/
<steev> it might just be something unrelated not probing in time
<qzed> could be
<travmurav[m]> Cool, it has happily rebooted now!
<steev> not sure if it's already in next, but i know https://patchwork.freedesktop.org/series/105392/ is coming down the pipeline at some point
<bamse> travmurav[m]: i currently am passing efi=noruntime to the kernel command line, this avoids jumping back into efi runtime services for the poweroff/reboot
<bamse> qzed: the variable access is a slightly different (bigger?) issue, in that efi runtime services doesn't have access to storage...
<travmurav[m]> Ah, cool if this can be done with less code hacks, thanks for a suggestion
<bamse> yeah, but hopefully we can get this resolved in the long run
matthias_bgg has quit []
<qzed> tpm also seems to be handled via the TZ
<qzed> or TrEE as qualcomm refers to that, I think
<qzed> I've got an issue for that at https://github.com/linux-surface/surface-pro-x/issues/37 if anyone wants to add any comments
<bamse> hmm, so you think that's where they store the efi variables?
<qzed> pretty sure, the windows driver has a "EfiVariableService" or something named like that
<qzed> let me check
<bamse> is that a qualcomm or microsoft service?
<qzed> I'm not entirely sure how specific that is, it's provided in a surfaceprox_tree directory, so at least somewhat surface specific
<qzed> but I think the service thing is general for qualcomm
<qzed> you could check if there's a tree driver for the flex and then check the inf file
<qzed> on the spx, there are entries for "UEFIVAR SECURE APP SERVICE"
<qzed> I think the reason it's specific to the spx is that there are a bunch of mbn files for HDCP/playready
<qzed> which are probably signed for that device
<qzed> the uefivar service doesn't seem to require one though
<qzed> I've added a list with all services mentioned in the spx inf to https://github.com/linux-surface/surface-pro-x/issues/37
<qzed> (also there are references to GetVariable/SetVariable function names in the .sys)
<bamse> qzed: a typical solution on arm-devices where tz doesn't have storage access is that you have some sort of service running in the OS which performs the disk access
<bamse> qzed: for UFS devices this has made total sense, as i believe the rpmb is part of the UFS device
<bamse> qzed: but i don't know how that work with the nvme based devices, as they have some secondary storage for boot et al
<bamse> and there's the tpm as well
<steev> qzed: we do have that on the flex
<qzed> ah interesting, so those services might not actually do scm calls on the UFS devices?
<qzed> I still need to have a look beyond just running strings at that driver
<bamse> qzed: in above described model, they would do scm calls for implementing callbacks to allow tz to read and write rpmb in the storage device
<qzed> ah, that makes sense
<bamse> seems nvme typically provides some rpmb storage as well...
<bamse> but i don't know, we have some work-in-progress that's taking shape for interacting with the qualcomm tee, which probably could be used to implement something like that in the end...but it's pretty much uncharted territory so far
<qzed> all I know so far are that there are some services (based on inf and strings in the driver), some mbn files (which I guess are tz services) and that there is a scm call routine in the driver... but I don't know anything else
<qzed> steev: after cursing windows utf-16le encodings, I've managed to diff the inf files... and there really isn't that much difference
<steev> qzed: time to diff the mbns :P
<qzed> the spx has some storesec.mbn file that the flex doesn't have, which I guess is due to the UFS difference
<qzed> and the rest seems to be rebranding "Qualcomm" to "Surface"
<qzed> oh, the flex has a "fingerpr.mbn"
<qzed> I guess that means the flex has a fingerprint reader? xD
<steev> yeah, the fingerprint rader
<qzed> yeah, spx doesn't have that so seems logical
<steev> it does, but i've never used it (the c630 also has one)
<steev> i am... not a fan of using biometrics with my computing devices
jhovold has quit [Ping timeout: 480 seconds]
flowriser has joined #aarch64-laptops
flowriser has quit []