ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Pali has joined #armlinux
djrscally has quit [Ping timeout: 260 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
m5zs7k has quit [Ping timeout: 256 seconds]
olofj has quit [Read error: Connection reset by peer]
olofj has joined #armlinux
Pali has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 256 seconds]
m5zs7k has joined #armlinux
amitk has joined #armlinux
iivanov has joined #armlinux
frieder has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
guillaume_g has joined #armlinux
djrscally has joined #armlinux
milkylainen has quit [Quit: Ping timeout (120 seconds)]
milkylainen_ has quit [Quit: Ping timeout (120 seconds)]
milkylainen has joined #armlinux
sszy has joined #armlinux
abelvesa has quit [Ping timeout: 256 seconds]
abelvesa has joined #armlinux
nsaenz has quit [Quit: Leaving]
nsaenz has joined #armlinux
matthias_bgg has joined #armlinux
headless has joined #armlinux
Pali has joined #armlinux
alexels has joined #armlinux
<arnd>
olofj tmlind shenki krzk shawnguo robher: I finished my first pass through the old 'for-next' branch in the soc tree that didn't make it, and through patchwork, applied everything I saw that is needed in 5.17 to https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=arm/fixes
psydroid has joined #armlinux
<arnd>
let me know if there is anything I missed, or if you'd like something else in my pull request this week
<arnd>
I'll also start merging the branches that were sent for 5.18, and will reply to the pull requests that got into for-next but not 5.17. If you want the contents merged into 5.18 directly, please let me know, otherwise I'll wait for a new PR
<krzk>
arnd: thanks, the fixes branch look ok to me. The material which did not make v5.17 (and is not a fix), I will resend, so dropping old commits from arm-soc is fine.
monstr has joined #armlinux
<tmlind>
arnd: looks good to me for the fixes thanks
apritzel has joined #armlinux
<headless>
kos_tom: ping
matthiasbgg[m] has joined #armlinux
<headless>
kos_tom: I know you have sh7786... but I guess on a Renesas board? I'm trying to figure out what irq chip is used on ap-sha4-3a/ap-sh4ad-0a boards...
<headless>
sorry for offtopic, #linux-sh is dead
<headless>
hum... not entirely but almost no ppl there :-)
<arnd>
headless: if nobody has an answer here, try asking on #jcore, at least dalias is usually around there. geertu also has some sh machines
<headless>
arnd: I know geertu (and his machines)
<headless>
:-)
<headless>
thx for advice tho :-)
* headless
goes back to the svace's reports
<arnd>
headless: fwiw, I wouldn't have too high hopes on SMP working reliably, I think this was the only non-reference board that was ever supported for SH SMP mode, and pmundt left Renesas soon after adding it.
<headless>
arnd: I don't need SMP, I just need to make sure irq0 is no longer used
<headless>
and these boards use irq0 for the smsc911x chip
<ardb>
yes, you just need to implement a single function in a runtime EFI module in u-boot
<ardb>
and expose the address via a EFI config table
<kettenis>
looks like this doesn't attempt to try full-on SMCCC, but I think that is fine for us
<kettenis>
(did I add enough C's in there?)
<ardb>
not sure that would add anything
<ardb>
EFI runtime code fundamentally runs at the same EL as the OS that invokes it
<mrutland>
Which version of PSCI is exposed?
<kettenis>
yes and in our implementation (Apple M1) we probably want to keep this code as small as possible anyway
<mrutland>
... because later versions imply the presence of a full SMCCC (even if trival) implementation
<ardb>
mrutland: that depends on what PSCI_FEATURES returns, no?
<ardb>
mrutland: this is just a non-SMCCC conduit
<marcan>
incidentally, if we're using this for sleep, it's going to have to step on the SMC driver's toes... and it also means we could implement shutdown/reboot support in here and skip that whole SMC subdriver I wrote today (*cries in mailbox/RTKit atomic support*)
<mrutland>
ardb: the code checks both PSCI_VERSION() >= 1.0 && PSCI_FEATURES() reporting SMCCC_VERSION is present, but IIRC on the spec-side it's expected that PSCI implies the presence of SMCCC
<ardb>
mrutland: does M1 need anything beyond 0.2 ?
<kettenis>
marcan: stepping on the SMC's toes sounds like a bad idea to me
<mrutland>
ardb: maybe not, just checking we're not backing ourselves into a corner
<marcan>
actually I'm not entirely sure if we really need to trigger sleeps through SMC
<marcan>
but it's not *that* bad
<marcan>
with IRQs off and the OS already in a UP sleep path, we can coexist; the main issue is we'd have to throw away syslogs if we happen to get any, and the SMC driver should disable notifications to avoid confusion
<ardb>
mrutland: so the context of the EFI suggestion was avoiding the need for custom CPU enable methods on arm64
<ardb>
mrutland: so CPU_ON and CPU_OFF, but little more
<marcan>
CPU sleep too
<marcan>
we need to implement deep sleep
<marcan>
(i.e. deeper than wfi)
<ardb>
fair enough
<mrutland>
ardb: sure, and that's certainly *better* that custom enable methods
<ardb>
marcan: fair enough
<marcan>
and also suspend
<marcan>
so SYSTEM_SUSPEND
<mrutland>
ardb: my big fear is that this is *quite* different from SMC/HVC (e.g. needing the kernel to switch TTBRs, not getting implicit context synchronization via SMC/HVC/ERET, etc), so there's a big rick of subtle breakage that's really painful to fix
<marcan>
is there another way though?
<marcan>
it's pretty much either this or custom driver code
System_Error has joined #armlinux
<kettenis>
I suppose as long as we don't implement any calls that need more that the function identifier and 3 parameters we could add smccc functions as well
<ardb>
kettenis: not sure the PSCI pseudo-conduit is the right place for that tbh
<ardb>
precisely for the reasons mrutland is mentioning
<mrutland>
In the past I had assumed that we'd extend/redo spin-table to have a mechanism for throwing CPUs back, which would get us hotplug (but not much more), and for that we'd need to define the contract for things like register state, etc.
<mrutland>
I can see that it's nice to align with PSCI, and I'm not necessarily opposed to that (I just have concerns)
<kettenis>
ah, smccc is discovered through psci and not the other way around, so I don't think there is any need to implement smccc calls then
<mrutland>
I think if longer-term we want to expose *more* stuff, having the option of an SMCCC-level conduit might be nicer
<mrutland>
... and so e.g. we might need ot pass more registers
<mrutland>
... even if for now we only support PSCI calls
<arnd>
I would lean towards keeping the interface narrowly defined to just PSCI rather than opening the door to anything that may be done using SMCCC
<mrutland>
I also think we might need to treat this differently from HVC/SSMC PSCI in somce cases, e.g. in panic() situations where we might not be able to safely play with the TTBRs
<arnd>
Opening this up too much adds the risk of having other platforms abuse this into firmware-level device drivers the way we get it on powerpc with RTAS, or on PCs doing too much in ACPI that should be in a kernel driver
suzukikp has joined #armlinux
<mrutland>
arnd: the difficulty is that PSCI generally is just SMCCC, so if we only want PSCI-0.2 that's OK, but we can't e.g. design for future PSCI stuff without supporting SMCCC calling convention generally
<mrutland>
(e.g. if a new PSCI call with more arguments shows up, that for some reason people want)
<arnd>
mrutland: how frequently do we add new features to PSCI?
<mrutland>
arnd: it's bursty, so I can't really say
<mrutland>
arnd: my point was more that we can easily limit it to an *old* version of PSCI, but not PSCI as a floating spec
<arnd>
right
<ardb>
mrutland: i think 0.2 is the sweet spot for this, tbh
<ardb>
although it lacks SYSTEM_SUSPEND
<marcan>
I was about to say that
<ardb>
arnd: mrutland , can we have custom platform_suspend_ops on arm64?
<ardb>
or does it have to be PSCI as well?
<mrutland>
I'd much rather we ran that through PSCI, or it's going to be very difficult to keep everyone else from writing their own
<ardb>
right
headless has joined #armlinux
<mrutland>
which IIUC means PSCI 1.0 minus
<arnd>
marcan: what is the difference on between suspend-to-idle and normal suspend with the current M1 platform? Could we just use the idle call?
<marcan>
system suspend is a thing, PMU/SMC stuff is involved at least to some extent
<marcan>
it's not just the CPUs
<marcan>
but also, that would imply some kind of Linux support for fake-system-suspend where it just puts the CPUs into sleep and freezes userspace/timers/whatever so the usual wakeups don't happen
<mrutland>
suspend-to-idle alreayd exists in Linux
<marcan>
oh, huh
<marcan>
that one's actually worth testing then
<marcan>
because what I do know is that an M1 air with an active SSH session over WiFi (which is obviously not going into full system suspend) in macOS eats about 1% battery per hour
<marcan>
which is already better than real standby on some x86 machines
<marcan>
so I wonder what proper s2i would do
<marcan>
we still need to put the cores into deep-wfi though, that one is both a performance and power issue
<marcan>
without deep-wfi you don't get boost frequency states
<maz>
is that the one where you lose state?
<marcan>
you lose register state, but it keeps sp and pc
<marcan>
so at least you can pop/push your way around it
<marcan>
on older apple chips it used to lose all state and end up at the reset vector
<marcan>
but at some point they implemented sp/pc retention, though you can also turn it off and get back the old behavior
<marcan>
in fact switching to the old behavior seems to be part of putting the system into full sleep
<maz>
I guess you restart with empty TLBs and whatnot.
<marcan>
I imagine so
<marcan>
at least basic sysreg stuff sticks, I imagine
<marcan>
not sure about fp regs
<marcan>
GPRs definitely go away
<maz>
they must discard more than just the GPRs, even if they have a boatload of them.
<maz>
otherwise, that's a pretty small gain.
<marcan>
let me do a quick test
<arnd>
a number of 32-bit platforms lose the translation table registers, so they need some interesting code to get the state back when SP and PC point to physical addresses
torez has joined #armlinux
<marcan>
fp state is lost
<marcan>
TTBRs are preserved
<marcan>
all sysregs I've tried so far are preserved
<mrutland>
Huh; so SCTLR_ELx.M is kept on?
<marcan>
correct
<marcan>
in fact we've been relying on that for a while now in m1n1, since I put the cores into deep-wfi in our idle loops and we have lots of "init mmu on secondary; do stuff" type experiments which would obviously not work if the MMU got disabled in deep-wfi :)
<marcan>
never noticed anything dodgy and we've tried lots of things
<marcan>
I only save callee-preserved GPRs around our deep-wfi implementation
Guest74 has joined #armlinux
<marcan>
(fp state is lost but I haven't played much with fp, so I only noticed that one now)
<marcan>
mrutland: in fact the "intended" way to use this is to let the CPU itself decide whether to go into deep-wfi
<marcan>
so it should not be much heavier than a regular wfi to make it work
<marcan>
we override that though, and explicitly force one or the other mode
<marcan>
but it would be kind of silly if macOS had to save the world around its default wfi loop
<mrutland>
marcan: sure; it just seems an odd middle-ground that losing GPRs but not sysregs and other context is saving that much beyond retaining the GPRs
<mrutland>
marcan: does that lose the SP, too? or do SP_ELx all get retained?
<marcan>
sp stays, that's why we can just push/pop around
<marcan>
let me test EL0
<marcan>
all SPs are retained
<mrutland>
Ok, so that's plausible to use within an EFI function as a PSCI CPU_SUSPEND implementation, then
<mrutland>
Currently SMCCC / PSCI does say that FP is *retained* unless you return via the cold reset vector, though
<mrutland>
IIUC Linux doesn't currently depend upon that, but it's one potential problem
headless has quit [Quit: Konversation terminated!]
<marcan>
it should be easy enough to save/restore on the PSCI side though
Guest74 has quit [Quit: Client closed]
<broonie>
Linux shouldn't get upset about FP state being changed by EFI.
<broonie>
but like you say it's simple to do and avoids any future problems.
<ardb>
the EFI runtime wrappers already preserve/restore the FP/SIMD state
<broonie>
Yup.
<broonie>
And it's hard to see that ending up being a hot enough path to try to optimise.
<mrutland>
Sure -- what was meant to be an example of ABI/functional divergence between SMCCC and these calls that needs special care (even if that's just "we write a comment somewhere")
<mrutland>
s/what/that/
jlinton has joined #armlinux
<ardb>
mrutland: arnd, marcan, kettenis: i did a quick test in a VM with a EFI runtime routine that just calls HVC, and CPU_ON works fine
<ardb>
CPU_OFF is problematic right now because the CPU disappears in the middle of a preempt disabled FP/SIMD using sequence, and comes back via the CPU_ON entrypoint
<ardb>
non-retention CPU_SUSPEND will be similar, i imagine
<ardb>
and note that i rebased and re-pushed that efi-psci branch
monstr has quit [Remote host closed the connection]
guillaume_g has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
alexels has quit [Quit: WeeChat 3.4]
apritzel has quit [Ping timeout: 240 seconds]
nsaenz_ has joined #armlinux
nsaenz has quit [Ping timeout: 240 seconds]
shailangsa has quit [Remote host closed the connection]
jlinton has quit [Quit: Client closed]
nsaenz_ has quit [Quit: Leaving]
atorgue has quit [Quit: Client closed]
Amit_T has quit [Quit: Leaving]
prabhakarlad has joined #armlinux
headless has quit [Ping timeout: 240 seconds]
headless has joined #armlinux
iivanov has left #armlinux [Leaving...]
iivanov has joined #armlinux
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 256 seconds]
iivanov has joined #armlinux
iivanov__ has quit [Ping timeout: 250 seconds]
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
<ukleinek>
broonie: on which rev should I rebase the "spi: make remove callback a void function" series?
iivanov has joined #armlinux
<broonie>
It was
<broonie>
Mainline
iivanov__ has joined #armlinux
<ukleinek>
b4 am -l YgJyiiLqLu44MWF1@sirena.org.uk + git am ./20220123_u_kleine_koenig_spi_make_remove_callback_a_void_function.mbx works fine for me on current linus/master
<ukleinek>
on next I get a merge conflict in drivers/staging/fbtft/fbtft.h
iivanov_ has quit [Ping timeout: 256 seconds]
iivanov has quit [Ping timeout: 240 seconds]
<ukleinek>
ah, and also on drivers/hwmon/adt7310.c and drivers/staging/pi433/pi433_if.c
<ukleinek>
the conflicting commits are 4ef027d5a367131c56ffc4949466a892733a7d60, 9c950b125f781d1fa8575f338a6d098387dd8d66, dd94ffb3d4f28fd78341ce41b7e5f9cf0d066f13 and d46c8ec7117eaacc7d37cda122f779bd5d31d0e5.
<ukleinek>
broonie: neither of them is in mainline
<broonie>
Greg said to ignore staying.
<broonie>
I’d need a pull for hwmon
<broonie>
Or depending on what the conflict actually is just let Linus fix it
<ukleinek>
broonie: I don't understand the problem. Applying on top of linus/master (or spi/for-next) is fine, right?
<broonie>
You said there was some issue with that?
<ukleinek>
broonie: for me, applying on top of linus/master works fine.
<ukleinek>
only when doing that on top of next/master there is a problem.
<broonie>
So what are those commits you’re talking about?
<ukleinek>
these are commits in next
<broonie>
Well, I don’t know why I would have a hwmon commit in my tree…
<ukleinek>
I'd say the right thing to do is: Apply the series on top of -rc1 (or a later -rc if you prefer), tag that and tell the hwmon maintainer(s) to pull that into their tree.
<broonie>
As far as I know that is what I did
<broonie>
I think rc2
* ukleinek
retries with -rc2
<broonie>
I’m on my phone, I can’t see any of this stuff right now
<ukleinek>
broonie: works fine for me (git checkout v5.17-rc2 && b4 am -l YgJyiiLqLu44MWF1@sirena.org.uk && git am ./20220123_u_kleine_koenig_spi_make_remove_callback_a_void_function.mbx)
<ukleinek>
broonie: ok, if I can do anything else, just tell me. If it helps you, I can send a PR for a tag. I wouldn't presume to do that without you asking for it.
<ukleinek>
otherwise I'm happy that quest eventually comes to an end
<ukleinek>
(so only i2c and platform left :-)
headless has quit [Ping timeout: 256 seconds]
amitk_ has joined #armlinux
<broonie>
I’ll have a look tomorrow (I had pulled it aside in case it would fix up I think). In general it’s helpful to put the base-commit in the cover (there’s a format patch option for that).