[PATCH 1/1] irqchip: irq-gic: forward SGI to itself for cortex-a7 single core

[marc.zyngier@arm.com (Marc Zyngier)]

On Mon, 8 Aug 2016 14:48:42 +0100
Mark Rutland <mark.rutland@arm.com> wrote:

> On Mon, Aug 08, 2016 at 09:28:47PM +0800, Peter Chen wrote:
> > On Mon, Aug 08, 2016 at 02:07:54PM +0100, Mark Rutland wrote:  
> > > I see that for arm64 we have:
> > > 
> > > static inline bool arch_irq_work_has_interrupt(void)
> > > {
> > > 	return !!__smp_cross_call;
> > > }
> > > 
> > > Could we do similarly for ARM, and ony register gic_raise_softirq if
> > > we have non-zero SGI targets?
> > > 
> > > If I've understood correctly, that would make things behave as they do
> > > for UP on you system.  
> 
> [...]
> 
> > > If self-IPI is necessary, then this would be up to the GIC code to
> > > solve.
> > > 
> > > For that case, it would be nicer if we could detect whether this was
> > > necessary based on the GIC registers alone. That way we handle the
> > > various ways this can be integrated, aren't totally relient on the DT,
> > > work in VMs, etc.  
> > 
> > How we can detect IPI capabilities based on GIC register?  
> 
> Check the mask associated with SGIs, as we do for gic_get_cpumask(). If
> this is zero, we have a non-multiprocessor GIC (or one that's otherwise
> broken), and can't do SGI in the usual way.
> 
> However, it only makes sense to do this if self-IPI is truly a
> necessity. Given there are other interrupt controllers that can't do
> self-IPI, avoiding self-IPI in general would be a better strategy,
> avoiding churn in each and every driver...

Indeed. And I won't take such a patch until all other avenues have been
explored, including fixing core code if required...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.