(sorry if you get a duplicate email, the SMTP server I was using keeps reporting delays, so I'm resending with different settings)
Hi Nico,
On Sat, Aug 31, 2013 at 03:19:46AM +0100, Nicolas Pitre wrote:
On Fri, 30 Aug 2013, Catalin Marinas wrote:
My position for the arm64 kernel support is to use the PSCI and implement the cluster power synchronisation in the firmware. IOW, no MCPM in the arm64 kernel :(. To help with this, ARM is going to provide a generic firmware implementation that SoC vendors can expand for their needs.
I am open for discussing a common API that could be shared between MCPM-based code and the PSCI one. But I'm definitely not opting for a light-weight PSCI back-end to a heavy-weight MCPM implementation.
Also note that IKS won't be supported on arm64.
I find the above statements a bit rigid.
While I think the reasoning behind PSCI is sound, I suspect some people will elect not to add it to their system. Either because the hardware doesn't support all the necessary priviledge levels, or simply because they prefer the easiest solution in terms of maintenance and upgradability which means making the kernel in charge. And that may imply MCPM. I know that ARM would like to see PSCI be adopted everywhere but I doubt it'll be easy.
I agree PSCI is not always possible because of technical reasons (missing certain exception levels), so let me refine the above statement: if EL3 mode is available on a CPU implementation, PSCI must be supported (which I think is the case for Marvell).
It indeed sounds rigid but what's the point of trying to standardise something if you don't enforce it? People usually try to find the easiest path for them which may not necessarily be the cleanest longer term. As a past example, how many SoC maintainers were willing to convert their code to DT if there wasn't a clear statement from arm-soc guys mandating this?
In other words, if someone does the work to port MCPM to ARM64 and properly abstract the common parts with ARM32 then I don't see why you should refuse merging it.
I don't have a problem with the MCPM itself. It is nicely written and can probably be abstracted into a library. My concern is how MCPM is going to be used by the SoC code. The example I have so far is dcscb.c and I really want such code moved out of the kernel into firmware (or even better if there is some hardware control available). It is highly dependent to the SoC and CPU implementation and setting/clearing bits like ACTLT.SMP which is not possible in non-secure mode. I'm pretty sure that such code will end up doing non-standard SMC calls to the secure firmware and we lose any hope of standardisation.
The PSCI API can evolve in time (it has version information) but so far there is no such thing as "lightweight" PSCI that could be used as an MCPM back-end. For example, MCPM provides callbacks into the platform code when a CPU goes down to disable coherency, flush caches etc. and this code must call back into the MCPM to complete the CPU tear-down. If you want such thing, you need a different PSCI specification.