[PATCH] powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support

[Kevin Hao]

On Thu, Nov 07, 2013 at 11:34:51AM -0600, Scott Wood wrote:
> On Thu, 2013-11-07 at 15:17 +0800, Kevin Hao wrote:
> > It makes no sense to initialize the mpic ipi for the SoC which has
> > doorbell support. So set the smp_85xx_ops.probe to NULL for this
> > case. Since the smp_85xx_ops.probe is also used in function
> > smp_85xx_setup_cpu() to check if we need to invoke
> > mpic_setup_this_cpu(), we introduce a new setup_cpu function
> > smp_85xx_basic_setup() to remove this dependency.
> 
> Is there any harm caused by setting up the IPIs?

No real harm. Just make no sense to do so and it does cause confusion
when you cat /proc/interrupts and get something like this:
  507:          0          0   OpenPIC   2043 Edge      ipi call function
  508:          0          0   OpenPIC   2044 Edge      ipi reschedule
  509:          0          0   OpenPIC   2045 Edge      ipi call function single
  DBL:       7053      10137   Doorbell interrupts

> 
> What about other MPIC setup, such as setting the current task priority
> register?

This is done by the invoking of function mpic_setup_this_cpu() in
smp_85xx_setup_cpu().

> BTW, what exactly is probe() supposed to be doing?

It is supposed to do the platform specific smp initialization and then return
the CPU count.

>  It looks like its
> main effect (with smp_mpic_probe) is to request IPIs, but the caller
> seems to treat it mainly as a way to determine CPU count.
> 
> I looked at the caller of .probe() (which is smp_prepare_cpus()) to see
> what happens when probe is NULL, and the handling of max_cpus doesn't
> make much sense.  At first I was concerned by the gratuitous difference
> between smp_mpic_probe() using cpu_possible_mask versus
> smp_prepare_cpus() using NR_CPUS, but the value isn't even used (all the
> code that consumed max_cpus after setting it has been removed), and the
> value passed in to smp_prepare_cpus() is ignored.

Yes, the return value of .probe makes no sense now. Actually there is already
a patch to remove the check of the return value of .probe in function
smp_prepare_cpus().
  http://patchwork.ozlabs.org/patch/260574/

Thanks,
Kevin
> 
> -Scott
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20131108/44851a53/attachment.sig>