[RFC PATCHv2] ARM: mvebu: Let the device-tree determine smp_ops
Chris.Packham at alliedtelesis.co.nz
Mon Nov 17 12:46:28 PST 2014
On 11/17/2014 09:56 PM, Thomas Petazzoni wrote:
> Dear Chris Packham,
> On Fri, 7 Nov 2014 15:33:46 +1300, Chris Packham wrote:
>> The machine specific SMP operations can be configured either via
>> setup_arch or via arm_dt_init_cpu_maps. For the ARMADA_370_XP_DT devices
>> both of these are called and setup_arch wins because it is called last.
>> This means that it is not possible to substitute a different set of SMP
>> operations via the device-tree.
>> For the ARMADA_370_XP_DT compatible devices add a smp_init function that
>> detects if the device tree has an enable-method defined. If it does
>> return true to indicate that the smp_ops have already been set which
>> will prevent setup_arch from overriding them.
>> Signed-off-by: Chris Packham <chris.packham at alliedtelesis.co.nz>
> My colleague Maxime Ripard (in Cc) rightfully suggests exploring a
> different option: what about getting rid completely of the .smp field
> of the DT_MACHINE structure, and instead have some code run early
> enough that looks if an enable-method is defined, and if not, defines
> it to the default value. This way, we continue to be backward
> compatible in terms of DT, but we always use the enable-method from the
> DT, and not sometimes from DT, sometimes from the DT_MACHINE structure.
> Unfortunately, it will have to be done on the flattened DT, because the
> DT is unflattened right before the enable-method properties are looked
That probably wouldn't be too hard because set_smp_ops_by_method() tells
us if it's actually set something. We'd just need to propagate that up a
few levels. We could either propagate this result through to setup_arch
or move the smp_set_ops() call from setup_arch to something that gets
invoked based on the return from set_smp_ops_by_method() or
I'm a little hesitant because this is core code and I don't have access
to a large set of devices to test (plus the whole newbie thing). But I
could give it a go and see how far I get.
> And manipulating the DT in its flattened format, while possible in
> ->dt_fixup(), is a pain, and probably doesn't allow adding new
> properties anyway.
> So, in the end, maybe this idea doesn't work, I haven't checked
> Best regards,
More information about the linux-arm-kernel