[PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag for FSL MPIC.

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to 
hardware vector number space (MSIs) while setting up internal sources.

Signed-off-by: Varun Sethi <redacted>
---
 arch/powerpc/sysdev/mpic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8be1ea2..33520dd 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c

@@ -1191,7 +1191,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
 	if (of_get_property(node, "single-cpu-affinity", NULL))
 		flags |= MPIC_SINGLE_DEST_CPU;
 	if (of_device_is_compatible(node, "fsl,mpic"))
-		flags |= MPIC_FSL;
+		flags |= MPIC_FSL | MPIC_LARGE_VECTORS;
 
 	mpic = kzalloc(sizeof(struct mpic), GFP_KERNEL);
 	if (mpic == NULL)

-- 
1.7.2.2

On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to=20
hardware vector number space (MSIs) while setting up internal sources.

What is driving this change?  The commit message isn't quite correct as =
MPIC_LARGE_VECTORS is about the # of IRQs, not the fact that vector =
field is 16-bits.

device_node *node,

	if (of_get_property(node, "single-cpu-affinity", NULL))
		flags |=3D MPIC_SINGLE_DEST_CPU;
	if (of_device_is_compatible(node, "fsl,mpic"))
-		flags |=3D MPIC_FSL;
+		flags |=3D MPIC_FSL | MPIC_LARGE_VECTORS;
=20
	mpic =3D kzalloc(sizeof(struct mpic), GFP_KERNEL);
	if (mpic =3D=3D NULL)
--=20
1.7.2.2
=20
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, March 27, 2012 7:01 PM
To: Sethi Varun-B16395
Cc: Linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/4] powerpc/mpic: Use the MPIC_LARGE_VECTORS flag
for FSL MPIC.
=20
=20
On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
=20

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to
hardware vector number space (MSIs) while setting up internal sources.

=20
What is driving this change?  The commit message isn't quite correct as
MPIC_LARGE_VECTORS is about the # of IRQs, not the fact that vector field
is 16-bits.
=20

[Sethi Varun-B16395] We derive the internal interrupt source vector numbers=
 from the
number of supported hardware interrupt sources. With the current value of 2=
56
we end up using vector numbers (for internal sources) corresponding to actu=
al hardware
interrupts. With the MPIC_LARGE_VECTORS flag we can avoid eating in to hard=
ware vector
number space.

-Varun

On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala [off-list ref] wrote:

On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to
hardware vector number space (MSIs) while setting up internal sources.

What is driving this change?

Whats driving the change is proper handling of error interrupts.   Right
now error interrupts (muxed on int 16) are treated as a shared
interrupt source.   We want each to be handled as a individual interrupt
source...thus the desire to support more than 256 interrupts.

Stuart

On 03/27/2012 10:21 AM, Stuart Yoder wrote:

On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala [off-list ref] wrote:

quoted

On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to
hardware vector number space (MSIs) while setting up internal sources.

What is driving this change?

Whats driving the change is proper handling of error interrupts.   Right
now error interrupts (muxed on int 16) are treated as a shared
interrupt source.   We want each to be handled as a individual interrupt
source...thus the desire to support more than 256 interrupts.

We don't actually need more than 256 interrupts for this (the individual
error interrupts are not counted against this).  But unless we change
how vectors are allocated, we need vectors >= 256, since we have MSIs
close enough to 256 that under the current scheme the IPIs, timers, and
such collide with the third MSI bank.

-Scott

On 03/27/2012 01:44 PM, Scott Wood wrote:

On 03/27/2012 10:21 AM, Stuart Yoder wrote:

quoted

On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala [off-list ref] wrote:

quoted

On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to
hardware vector number space (MSIs) while setting up internal sources.

What is driving this change?

Whats driving the change is proper handling of error interrupts.   Right
now error interrupts (muxed on int 16) are treated as a shared
interrupt source.   We want each to be handled as a individual interrupt
source...thus the desire to support more than 256 interrupts.

We don't actually need more than 256 interrupts for this (the individual
error interrupts are not counted against this).  But unless we change
how vectors are allocated, we need vectors >= 256, since we have MSIs
close enough to 256 that under the current scheme the IPIs, timers, and
such collide with the third MSI bank.

Sorry, I misremembered -- the error interrupts do count against the 256,
but only for Linux IRQ numbering purposes (not hardware vector assignment).

-Scott

On 03/27/2012 01:44 PM, Scott Wood wrote:

On 03/27/2012 10:21 AM, Stuart Yoder wrote:

quoted

On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala [off-list ref] wrote:

quoted

On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS flag
while intializing the MPIC. This also prevents us from eating in to
hardware vector number space (MSIs) while setting up internal sources.

What is driving this change?

Whats driving the change is proper handling of error interrupts.   Right
now error interrupts (muxed on int 16) are treated as a shared
interrupt source.   We want each to be handled as a individual interrupt
source...thus the desire to support more than 256 interrupts.

We don't actually need more than 256 interrupts for this (the individual
error interrupts are not counted against this).  But unless we change
how vectors are allocated, we need vectors >= 256, since we have MSIs
close enough to 256 that under the current scheme the IPIs, timers, and
such collide with the third MSI bank.

Note that this is the case today even without the error interrupt stuff
-- the highest vector used by MSIs on MPIC 4.1 is 0xf7, and we have 13
special vectors (4 IPIs, 8 timers, and spurious).

-Scott

On Mar 27, 2012, at 2:16 PM, Scott Wood wrote:

On 03/27/2012 01:44 PM, Scott Wood wrote:

quoted

On 03/27/2012 10:21 AM, Stuart Yoder wrote:

quoted

On Tue, Mar 27, 2012 at 8:30 AM, Kumar Gala =

[off-list ref] wrote:

quoted

quoted

quoted

=20
On Mar 27, 2012, at 7:15 AM, Varun Sethi wrote:
=20

quoted

FSL MPIC supports 16 bit vectors so our vector number space isn't
restricted to 256 vectors. We should use the MPIC_LARG_VECTORS =

flag

quoted

quoted

quoted

quoted

while intializing the MPIC. This also prevents us from eating in =

to

quoted

quoted

quoted

quoted

hardware vector number space (MSIs) while setting up internal =

sources.

quoted

quoted

quoted

=20
What is driving this change?

=20
Whats driving the change is proper handling of error interrupts.   =

Right

quoted

quoted

now error interrupts (muxed on int 16) are treated as a shared
interrupt source.   We want each to be handled as a individual =

interrupt

quoted

quoted

source...thus the desire to support more than 256 interrupts.

=20
We don't actually need more than 256 interrupts for this (the =

individual

quoted

error interrupts are not counted against this).  But unless we change
how vectors are allocated, we need vectors >=3D 256, since we have =

MSIs

quoted

close enough to 256 that under the current scheme the IPIs, timers, =

and

quoted

such collide with the third MSI bank.

=20
Note that this is the case today even without the error interrupt =

stuff

-- the highest vector used by MSIs on MPIC 4.1 is 0xf7, and we have 13
special vectors (4 IPIs, 8 timers, and spurious).

This all makes sense, what I ask is that the commit message be updated =
to convey this.

- k=