Skip to content

Commit

Permalink
powerpc/xics: EOI xics ipi by hand in kexec
Browse files Browse the repository at this point in the history
EOI normally has the side effect of returning the cpu to the base
priority to recieve the next interrupt.  This is actually controlled
by the top byte of the xirr register.   When we are exiting the
kernel in kexec we must eoi the ipi for the next kernel because we
never return from the handler, but we want to leave interrupt
delivery blocked until the next kernel takes action.

Since the hardware ipi vector is fixed, its easiest to just do the
eoi explicitly.

Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
  • Loading branch information
Milton Miller authored and Benjamin Herrenschmidt committed Oct 13, 2008
1 parent b496325 commit 1a57c92
Showing 1 changed file with 7 additions and 11 deletions.
18 changes: 7 additions & 11 deletions arch/powerpc/platforms/pseries/xics.c
Original file line number Diff line number Diff line change
Expand Up @@ -757,25 +757,21 @@ void xics_teardown_cpu(void)

void xics_kexec_teardown_cpu(int secondary)
{
unsigned int ipi;
struct irq_desc *desc;

xics_teardown_cpu();

/*
* we need to EOI the IPI
* we take the ipi irq but and never return so we
* need to EOI the IPI, but want to leave our priority 0
*
* probably need to check all the other interrupts too
* should we check all the other interrupts too?
* should we be flagging idle loop instead?
* or creating some task to be scheduled?
*/

ipi = irq_find_mapping(xics_host, XICS_IPI);
if (ipi == XICS_IRQ_SPURIOUS)
return;
desc = get_irq_desc(ipi);
if (desc->chip && desc->chip->eoi)
desc->chip->eoi(ipi);
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_xirr_info_set((0x00 << 24) | XICS_IPI);
else
direct_xirr_info_set((0x00 << 24) | XICS_IPI);

/*
* Some machines need to have at least one cpu in the GIQ,
Expand Down

0 comments on commit 1a57c92

Please sign in to comment.