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
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
<konradybcio>
broonie: would you know whether we support any QSPI peripherals in linux that aren't flash chips?
<kuruczgy[m]>
konradybcio: Could you elaborate a bit more? Is this in reference to the GPIOs?
jhovold has joined #aarch64-laptops
<jhovold>
kuruczgy[m]: gpio interrupts on x1e are currently broken in mainline, but my wip branch that you use has a workaround for this
<jhovold>
otherwise you would not even have any keyboard interrupts etc
ellyq_ has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
Heyhey I'm new here, first time using irc aswell so still figuring things out a bit. I have bought myself an Asus S15 Vivobook with the purpose of having a cool ARM laptop and hopefully helping with development. Managed today to make an arclinuxarm bootable usb but it can't read the rootfs of of it yet it seems
<SpieringsAE>
I'm using the linux-aarch64-rc kernel to at least get access to the right dtb. I was expecting usbc to work but it seems that is not really the case yet either
<SpieringsAE>
Is there a kernel I can track that has the most up to date things in it for these new x elite systems?
<anonymix007[m]>
At the very least, you'll need to copy the cmdline.
<SpieringsAE>
that looks interesting, there is one thing I don't get, in /configs/device/x1e-t14s.yaml it lists a linux-t14s package, but this doesn't seem to be an actual package, is this using some unofficial mirror with more packages?
<SpieringsAE>
nvm found it
<SpieringsAE>
I don't really see any changes to the rc kernel here, but I do see some maybe important mkinitcpio things
<SpieringsAE>
or do you think its better to keep them seperated, I want to build off of what you have to add things for my asus
<SpieringsAE>
thanks kuruzgy that one seems perfect for me to keep an eye on
<JensGlathe[m]>
The ubuntu tree has both of johan's wip trees combined.
<JensGlathe[m]>
The image has a boot menu for Volterra, X13s, Yoga 7, Vivobook S15 - pretty simple to add another dtb
<SpieringsAE>
yeah thats what I thought too, its just another boot configuration
<jhovold>
JensGlathe[m]: my x1e branch is already based on top of the sc8280xp one (for dual booting and as many fixes are qcom generic)
<TSIN[m]>
Is there any dts support for sdcard slot for asus vivobook s15？
<JensGlathe[m]>
@jhovold I assumed as much, I rebased both because Volterra patches in my branch
<JensGlathe[m]>
and yes, the git log diff between your branches shows only x1e patches
<kuruczgy>
I tested the sleep power consumption on my Yoga. On Linux, it loses 3.8% battery over 1h, while on Windows it loses less than 1%.
<kuruczgy>
So there is still quite a bit of excess power draw. Does anyone know the specific pieces of hardware in (and maybe outside) the SoC that are drawing power, but we don't have drivers for yet to power manage them?
<kuruczgy>
Also I guess that the `pd_ignore_unused` and `clk_ignore_unused` paramteres are contributing, do we know what's preventing us from removing them?
<kuruczgy[m]>
But from what I can tell it was already going into sleep mode without this patch, the screen just wasn't resuming properly.
<JosDehaes[m]>
Ah thanks, will try that tonight. My yoga would immediately wake up
<kuruczgy[m]>
How do you know that it's immediately waking up?
<anonymix007[m]>
SpieringsAE: I actually wanted to make a generic image, but also wanted it to have automatic dtb selection built-in already. That part is WIP currently
<JosDehaes[m]>
I see that from the dmesg
<SpieringsAE>
anonymix007 how do you intend to do automatic dtb selection? I watched a talk recently from a qualcomm engineer where there was still quite a bit of debate about this. I recently booted archlinuxarm from a usb drive on my girlfriends arm chromebook, that one seems to have some kind of mechanisme for it
<SpieringsAE>
but it also has a strange boot partition, seems to not be EFI
<SpieringsAE>
does the firmware somehow make some variable available that can be used to determine the dtb?
<kuruczgy[m]>
Jos Dehaes: Well the thing is, the clock (at least the one used by dmesg) stops during sleep, so you can't really tell
<kuruczgy[m]>
I inserted some extra log messages using `ktime_get`, and AFAICT the machine is sleeping. SSH is frozen while it's sleeping, and also the power draw is lower (though not low enough, as I noted above.) Note that the power led on the right stays on, and does not start blinking during sleep like it's supposed to.
<kuruczgy[m]>
But despite that, most evidence I have points towards it going to sleep, it's just hard to tell.
<SpieringsAE>
That will only work with systemd-boot then i guess yeah? which doesn't matter to me as that is the one I use anyway
<SpieringsAE>
but its an interesting discussion, keeping an eye on it
<JosDehaes[m]>
kuruczgy @_oftc_kuruczgy:matrix.org: the keyboard backlight stays on
<JosDehaes[m]>
But indeed ssh sessions are stuck
<SpieringsAE>
has anyone already tried enabling the new usb_mp devicetree node (and those it depends on)? Or iss there still more things missing to enable it?
<anonymix007[m]>
SpieringsAE: it should work with grub as well or even without a bootloader at all
<kuruczgy[m]>
Jos Dehaes: Yes it stays on, I don't know yet what controls it. (The theory is that it's the EC, which doesn't have a driver yet.) The workaround is to turn it off manually...
<SpieringsAE>
ah because this is about UKIs anonymix007
<SpieringsAE>
It gets embedded in the UKI
<JosDehaes[m]>
Ah
<broonie>
konradybcio: Not specifically, though I'd be surprised if there weren't things like DSPs out there. You could also group ADCs and DACs together in parallel and use QSPI to get synchronised samples.
cyrinux has quit []
cyrinux has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
<jenneron[m]>
<SpieringsAE> "anonymix007 how do you intend to..." <- depthcharge handles that
<jenneron[m]>
we just package a depthcharge image with all dtbs in pmOS
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
flokli has quit [Quit: WeeChat 4.4.1]
weirdtreething has joined #aarch64-laptops
<kuruczgy>
jhovold: I watched the talk, but I still feel like there is a gap in my understanding.
<kuruczgy>
I think I have all the modules needed to drive the display in the initramfs, so I should be able remove the _ignore_unused params and still have it working. But it immediately goes black after the EFI stub and doesn't come back.
<kuruczgy>
Are the clocks and regulators disabled before *any* kernel module loading happens? But even then, they should just get reenabled when the module gets loaded, so I feel like I still don't understand something.
mrkajetanp has joined #aarch64-laptops
<jhovold>
kuruczgy: seemingly unused clocks and pds are disabled before modules are loaded, and the hw may not like having its resources go away while it is in use
mrkajetanp has quit [Ping timeout: 480 seconds]
<kuruczgy>
Would building the relevant drivers into the kernel instead of modules work in theory?
<jhovold>
yes
<kuruczgy>
Okay, thanks, then I might try that when I have time.
<JensGlathe[m]>
This popped into dmesg when a video started playing on a website, apparently it tried to use the venus codec (from the call trace) and something didn't want to come up.
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
jhovold has quit [Quit: WeeChat 4.3.2]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
flokli has quit [Quit: WeeChat 4.4.1]
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #aarch64-laptops
flokli has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
<kuruczgy[m]>
Jos Dehaes: What makes you believe that? Maybe I am missing something, but I don't see anything strange in these longs apart from ath12k somehow losing the firmware, I have no idea how that's even possible...
<JosDehaes[m]>
well the ath12k crash comes from resume
<JosDehaes[m]>
also the fans were still spinning for a while after initiating sleep
<JosDehaes[m]>
the power light stays on solid (I guess it would blink or so during suspend?)
<JosDehaes[m]>
you also see in the same second as the suspend the CPUs getting enabled again
<JosDehaes[m]>
and after 20 seconds you see 'suspend exit' (I waited longer to press anything to wake)
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
<kuruczgy[m]>
Jos Dehaes: I have the stopped dmesg timer and the power LED staying on as well.
<kuruczgy[m]>
Despite that, I think this experiment strongly suggests that my machine IS in fact sleeping:
<kuruczgy[m]>
I added the attached patch to print the elapsed time during sleep, and the deepest one (which is actually called in a place where the driver is suspended, so you are not supposed to call ktime_get) reports the correct elapsed real time (~10s). I don't see how that would be possible if the machine woke up earlier.
<JosDehaes[m]>
Oh I can surely believe your machine may be sleeping, just that mine isn't 😅 I'd be keen to figure out why/fix it
<JensGlathe[m]>
I think its a bit early
mrkajetanp has quit [Max SendQ exceeded]
<kuruczgy[m]>
I suspect that if you added that patch to print the elapsed time you would see the correct time as well. But I admit it's pretty crude, so if any kernel devs here can suggest some more elegant way to debug PM I would certainly be interested.