[linux-sunxi] Re: [PATCH v3 0/8] ARM: sun9i: SMP and CPU hotplug support
On Mon, 15 Jan 2018, Chen-Yu Tsai wrote: > Changes since v2: > - Do away with the MCPM framework, directly implement smp_ops > - Some debug messages were clarified > - New ARCH_SUNXI_MCPM Kconfig symbol for this feature You should use ARCH_SUNXI_SMP instead to avoid confusion with the actual MCPM code. Ditto for function names as Dave mentioned. For the ARM to Thumb switch you could add something like this at the beginning of your entry code: #ifdef CONFIG_THUMB2_KERNEL .arm mov ip, #1 bx ip .thumb #endif [your code follows here] And make sure that code is word aligned. Nicolas -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management
On Thu, 4 Jan 2018, Chen-Yu Tsai wrote:
> Nicolas mentioned that the MCPM framework is likely overkill in our
> case [4]. However the framework does provide cluster/core state tracking
> and proper sequencing of cache related operations. We could rework
> the code to use standard smp_ops, but I would like to actually get
> a working version in first.
>
> [...] For now however I'm using a
> dedicated single thread workqueue. CPU and cluster power off work is
> queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
> is somewhat heavy, as I have a total of 10 static work structs. It might
> also be a bit racy, as nothing prevents the system from bringing a core
> back before the asynchronous work shuts it down. This would likely
> happen under a heavily loaded system with a scheduler that brings cores
> in and out of the system frequently. In simple use-cases it performs OK.
If you know up front your code is racy then this doesn't fully qualify
as a "working version". Furthermore you're trading custom cluster/core
state tracking for workqueue handling which doesn't look like a winning
tradeoff to me. Especially given you can't have asynchronous CPU wakeups
in hardware from an IRQ to deal with then the state tracking becomes
very simple.
If you hook into struct smp_operations directly, you'll have direct
access to both .cpu_die and .cpu_kill methods which are executed on the
target CPU and on a different CPU respectively, which is exactly what
you need. Those calls are already serialized with .smp_boot_secondary so
you don't have to worry about races. The only thing you need to protect
against races is your cluster usage count. Your code will end up being
simpler than what you have now. See arch/arm/mach-hisi/platmcpm.c for
example.
Nicolas
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [RFC 0/7] ARM: sun9i: SMP support with Multi-Cluster Power Management
On Sun, 17 May 2015, Maxime Ripard wrote: Hi Ian, On Sat, May 16, 2015 at 11:08:46AM +0100, Ian Campbell wrote: On Thu, 2015-05-14 at 14:10 +0800, Chen-Yu Tsai wrote: This is my attempt to support SMP and CPU hot plugging on the Allwinner A80 SoC. The A80 is a big.Little processor with 2 clusters of 4x Cortex-A7 and 4x Cortex-A15 cores. I thought there was a preference these days to support this sort of thing via support PSCI in the firmware, which allows for other things such as non-secure-world etc. Yes, it is the preferred way. Meaning that if someone wants to do that work, he's very much welcome and encouraged to do so. But if no one's doing it, then we still have to have a way to bringup the secondary CPUs. And doing so in the kernel (at least initially) is simpler, and so much easier to fix when it is broken. We've seen a few systems already where power management is crippled because no one is able/allowed/willing to fix the broken firmware. Nicolas
