Thread (21 messages) flat view 21 messages, 7 authors, 2012-06-12
DORMANTno replies

Revision v7 of 10 in this series.

Revisions (10)
  1. rfc [diff vs current]
  2. v2 [diff vs current]
  3. v3 [diff vs current]
  4. v4 [diff vs current]
  5. v5 [diff vs current]
  6. v5 [diff vs current]
  7. v6 [diff vs current]
  8. v6 [diff vs current]
  9. v7 [diff vs current]
  10. v7 current

[PATCH v7 00/12] Per SoC descriptor

From: Marc Zyngier <hidden>
Date: 2012-06-12 10:39:01

On 08/06/12 15:54, Arnd Bergmann wrote:
On Thursday 07 June 2012, Marc Zyngier wrote:
quoted
[As per Arnd request, I've updated this patch series, in the hope that
it could be useful to the single zImage work]

This patch series introduces a per-soc descriptor which should, in the
end, contain most of the SoC specific operations.

This first patch series introduces the arm_soc_desc structure, adds
per-soc SMP and CPU hotplug operations, and converts all SMP platform
to this new scheme.

Patches against v3.5-rc1. Tested on VExpress (Cortex A15).

Also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git soc_desc-v3.5-rc1
With my experimental multiplatform kernel tree, it let me actually build
an allyesconfig including SMP enabled, so just for that you get an

Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks.
Two comments though:

1. I needed the patch below to avoid conflicting pen_release symbols.
I was not sure if any of the platforms rely on the pen_release variable
being located in the same cache line or page as the code accessing it,
or why else it is defined in assembly. If we don't have a reason for that,
we should probably pick the simpler approach and just have a single
definition for this in common ARM SMP code.
I have mixed feelings about this. On most hardware, CPU power management
should make the use of pen_release obsolete (it only makes sense if you
cannot turn off the power).

On the other hand, given how "popular" the versatile implementation is,
we might as well consolidate it. I've queued a patch to that effect, but
I'd really like platform maintainers to realize how wrong they are.
2. Sorry for having to bring it up yet again, but it still feels silly
to have the split data structures when nothing in the code actually
checks whether the functions are __init or __cpuinit, which was the
intention for splitting the struct in the first place according to
Nico. If people still like the split, I'll just shut up, but I would
prefer if this could be converted (back) into a single 'struct smp_ops'
with function pointers and no "name" field or the ambition to add
stuff other than SMP callbacks.
Right. I now have a slightly simpler/smaller series, which only cares
about SMP and have a single structure approach (though it still uses
split structures internally):

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
smp_ops-v3.5-rc2

I'll post it later today.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help