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: yes, quite likely that comment should be respected
<steev>
bamse: so since we have lp ddr4 on the thinkpad, i could maybe move 800 down below 720 and add those lines but use 102e instead of 103e and see if things blow up?
<steev>
or do we have ddr5
<bamse>
steev: i think we should try that, but it works pretty well as is, so i would prefer that we do that in a second step
<bamse>
i'll respin the patches and will try to get them merged first
<steev>
i saw you sneak in backlight :D
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
<bamse>
steev: yeah, for some reason we've lost that patch a few times by now
<bamse>
steev: need to land the whole bunch, so i don't need to juggle it around
<steev>
my T-bs are waiting
<HdkR>
steev: LPDDR4X on the X13s. 8CX G3 seems to be a bit too old to pick up LPDDR5
<steev>
HdkR: si :) sudo dmidecode --type 17
<steev>
mine was off at the time i asked initially
<steev>
the c630 has lp ddr4 as well
<HdkR>
ah cool
<steev>
but kinda moot point because -next doesn't build today
<steev>
surprisingly enough, not my patchset
<HdkR>
I am looking forward to the next 8CX getting 128-bit wide LPDDR5. 102GB/s memory BW? Yes please.
<steev>
i'm just looking forward to the thinkpad fully working once we get it to
<HdkR>
Same, Need that GPU working so I can send a bunch around to coworkers still :P
<steev>
i kinda stopped poking at it because there's so much in flux in the msm driver bits themselves
<steev>
once that calms down
<HdkR>
dang
<steev>
sorry :(
<steev>
not that i'm very good in the first place
derzahl has quit [Remote host closed the connection]
<HdkR>
That's okay, I'm even worse at kernel stuff
e1eph4nt has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
jelly has quit [Ping timeout: 480 seconds]
<flowriser>
steev: good question about the zstd and I totally forgot about that! I will change to debian at the next step
<steev>
:) it has caused us... endless headaches since ubuntu debs are no longer compatible
<flowriser>
Definitely gonna switch to debian. I simply remember reading about it a while back, but since I use arch as my daily driver I forgot
<flowriser>
So the dream is this: compile kernel in container, use vm usb pass-through to setup bootloader and distro related stuff
<flowriser>
and everything to be just one cli command
e1eph4nt has joined #aarch64-laptops
<flowriser>
So a while back I was experimenting on bringing up the acer spin 7, if you remember. I turned it off and on so many times that apparently I corrupted its storage :D Today it is getting serviced
e1eph4nt has quit [Ping timeout: 480 seconds]
jelly has joined #aarch64-laptops
e1eph4nt has joined #aarch64-laptops
flowriser has quit [Remote host closed the connection]
jhovold has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
srinik- has quit [Write error: connection closed]
srinik has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
pierro78 has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
jhovold has quit [Quit: WeeChat 3.5]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<mani_s>
maz, for supporting the system suspend/resume on Qcom pcie platforms, the ongoing series disables the clks & phy in suspend and brings them back during resume
<mani_s>
but after disabling the clocks, at the very end of suspend (cpu disable) there was a call to dw_msi_mask_irq()
<mani_s>
this one touches the pcie ip for which the clocks were turned off, so there is an abort
<mani_s>
the dwc-msi controller that is being used doesn't support affinity setting at all (returns -EINVAL in the callback)
<mani_s>
but the mask/unmask seems to be happening during the irq affinity setting
<mani_s>
So i have 2 questions:
iivanov has joined #aarch64-laptops
<mani_s>
1. Is it ok to try to continue irq affinity operations even if the controller doesn't support? there was a check to see if the set_irq_affinity callback is present or not. but in this case it is present but returns EINVAL
<mani_s>
2. Should we just keep the MSI controllers always ON? Is there a way to disable them?
<maz>
1: if any of the irqchip callback can result in a SError, none of them should be issued (basic consistency)
<maz>
2: there is no need for the MSI controller to be on if no end-point can reach it. PM is totally implementation-defined for these (no core code other than the basic per-IRQ refcounting).
<mani_s>
maz, 1. how do you ensure the consistency?
<mani_s>
I mean how do I make sure none of the callbacks are issued
<maz>
by making sure no other code runs after you've turned off the clock or before you've turned it on?
iivanov has quit [Quit: Leaving.]
<maz>
i.e. it should be one of the last things to run on suspend, and one of the first thing to run on resume.
<mani_s>
maz, the access is coming from the core kernel code and not from the drivers
<mani_s>
maz, right, that's why NOIRQ_SUSPEND/RESUME was used
<mani_s>
but still the access is coming during irq_migrate_all_off_this_cpu() and irq_affinity_online_cpu()
<maz>
why is the clock turned off at this point? this seems way too early.
<maz>
at the point where you suspend, there should be only a single CPU left alive.
<mani_s>
maz, early? NOIRQ is the last stage where a driver could disable the clocks, right? Or am I missing something?
<maz>
well, it *clearly* is too early, don't you think?
<mani_s>
i think all the MSI IRQs are pinned to cpu0, and since it is the boot cpu, that's where the issue comes
<mani_s>
maz, after noirq_suspend, there shouldn't be an access to the corresponding peripheral, right
<maz>
I seriously doubt the kernel is calling irq_migrate_all_off_this_cpu() from the last CPU standing.
<mani_s>
maz, they were not able to catch stack dump during suspend, But on resume, there is irq_affinity_online_cpu()
<mani_s>
so irq_migrate_all_off_this_cpu() is a guess
<maz>
of course there is, as we bring back up the CPUs that have been oflined.
<maz>
please don't guess.
<mani_s>
maz, so while we bring back cpu during resume, why there is no check if the irqchip supports affinity setting or not
<mani_s>
i mean a check inside irq_restore_affinity_of_irq()
<maz>
why should we care?
<mani_s>
maz, maybe i'm wrong but why should we continue doing the operation if the underlying controller doesn't support it
<maz>
because that the wrong layer to be concerned about this sort of things?
<maz>
that's*
<mani_s>
hmm
<mani_s>
anyway, that's something i wanted to know...
<mani_s>
maz, but still i'm not sure when would be the ideal time to disable clocks in the pcie driver
<mani_s>
if the access comes very late during suspend
<maz>
I don't know either.
<mani_s>
maz, okay :)
<maz>
as I said above, if you get accesses during the CPU offline phase and that you have turned your clocks off, you clearly have done it too early.
<mani_s>
maz, right..
<javierm>
maz, mani_s: isn't the opposite from the explanation? That the clocks are being ungated too late during resume?
<javierm>
since IIUC from what mani_s said, the problem doesn't happen during suspend but on resume
<mani_s>
javierm, no it happens during suspend also
<javierm>
mani_s: ah, sorry for the noise then. I misunderstood
<mani_s>
it was mentioned in the patch I shared
<mani_s>
javierm, np :)
<maz>
javierm: the two points should be symetric.
<maz>
symmetric*
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
iivanov has quit [Quit: Leaving.]
jhovold has joined #aarch64-laptops
e1eph4nt has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit []
e1eph4nt has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit [Quit: Leaving.]
iivanov has joined #aarch64-laptops
janrinze has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
falk689 has quit [Ping timeout: 480 seconds]
klardotsh has quit [Remote host closed the connection]
jonasbits_ has quit []
jonasbits has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
iivanov has quit [Quit: Leaving.]
falk689 has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
e1eph4nt has quit [Remote host closed the connection]
e1eph4nt has joined #aarch64-laptops
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #aarch64-laptops
Penguinpee_ has quit [Remote host closed the connection]
Penguinpee has joined #aarch64-laptops
falk689 has quit [Quit: No Ping reply in 180 seconds.]
<steev>
still haven't figured out where/how to read the mac address for that thing
klardotsh has joined #aarch64-laptops
<jenneron[m]>
pierro78_: would be better to have an installation .iso which uses dtb for installer (since cpu lock up issue) and installs kernel package into target system
<jenneron[m]>
i don't know how difficult it would be to implement
<derzahl>
what do i need to access the c630 efivars from the OS? is it just a kernel patch providing a compatibility layer ?