Re: [PATCH 10/14] irqchip/mips-gic: Add a IPI hierarchy domain

From: Qais Yousef <qais.yousef@imgtec.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: <linux-kernel@vger.kernel.org>, <jason@lakedaemon.net>,
	<marc.zyngier@arm.com>, <jiang.liu@linux.intel.com>,
	<ralf@linux-mips.org>, <linux-mips@linux-mips.org>
Subject: Re: [PATCH 10/14] irqchip/mips-gic: Add a IPI hierarchy domain
Date: Tue, 17 Nov 2015 10:08:26 +0000	[thread overview]
Message-ID: <564AFC9A.9080505@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1511161610070.3761@nanos>

On 11/16/2015 05:17 PM, Thomas Gleixner wrote:
> On Mon, 9 Nov 2015, Qais Yousef wrote:
>> On 11/07/2015 02:51 PM, Thomas Gleixner wrote:
>> Generally it's hard to know whether a real device is connected to a hwirq or
>> not. I am saving a patch where we get a set of free hwirqs from DT as only the
>> SoC designer knows what hwirq are actually free and safe to use for IPI. I'll
>> send this patch with the DT IPI changes or the rproc driver that I will be
>> send once these changes are merged.
>>
>> The current code assumes that the last 2 * NR_CPUs hwirqs are always free to
>> use for Linux SMP.
> So what you're saying is that you cannot rely on the last X hwirqs
> being available for IPIs. That's insane and to my knowledge there is
> no hardware out there which does not reserve a consecutive IPI space.

If I read the code you were suggesting correctly, you were trying to fit 
the IPIs in any available non allocated area in the GIC space. What I am 
trying to say is that we can only work on a limited subset of this space 
that we are told explicitly it's safe to use for IPIs. Most likely it's 
consecutive, but I don't feel brave enough to make this assumption 
personally - maybe I'm over paranoid.. I'm more keen on anything that 
would simplify this patch series now though.

I'll do my best with the next series but maybe we'd need to iterate this 
more than once till I get it right.

Thanks,
Qais