linuxdc-dev

[linuxdc-dev]AICA interrupts

[Adrian M. <ad...@mc...>]

I am experimenting with the AICA interrupt - HW_EVENT_AICA_SYS - but I am 
getting odd results:

This is the request call:

request_irq(HW_EVENT_AICA_SYS, aica_interrupt_handler, SA_INTERRUPT, "AICA", 
NULL);

And this is the (very simple!) handler:

////////////////////////////////////////////////////////////////
// Experimental interrupt handler                             //
////////////////////////////////////////////////////////////////

void aica_interrupt_handler(int i, void* p, struct pt_regs * ptr)
{
  
}


This is triggered thus:

static ssize_t aica_audio_write(struct file *file, const char *buffer,
				size_t count, loff_t * ppos)
{
	if (count < 1)
		return 0;

	//enable aica interrupts
	writel(0x20, 0xa07028b4);
	spu_write_wait();
	ssize_t ret;
	ret = aica_audio_do_write(file, buffer, count, ppos);
	writel(0x20, 0xa07028b8);
	spu_write_wait();
	//turn off aica interrupts
	writel(0x20, 0xa07028bc);

	spu_write_wait();
	return ret;

}

When this runs every call to writel(0x20, 0xa07028b8) appears to generate 
"unexpected IRQ trap at vector 0b" (though system output otherwise is normal).

What have I done wrong?

Adrian

Re: [linuxdc-dev]AICA interrupts

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Tue, Jan 01, 2002:

> I am experimenting with the AICA interrupt - HW_EVENT_AICA_SYS - but I am=
=20
> getting odd results:
>=20
>=20
[...]
> When this runs every call to writel(0x20, 0xa07028b8) appears to generate=
=20
> "unexpected IRQ trap at vector 0b" (though system output otherwise is nor=
mal).
>=20
> What have I done wrong?
>=20

I don't understand why you're getting the "unexpected IRQ ..." message, the
DC interrupt-handling code switches off of SH4 IRQ's 9, 11, and 13, so they
should always be "expected" and return the virtual IRQ.  See
arch/sh/kernel/setup_dc.c::systemasic_irq_demux() for more info.

The only other thing I can think of is that the DC machine vector (machvec)
isn't being selected, and that can only happen if you forget to set the
machine type as "Dreamcast" when configuring the kernel.

Can you check /proc/interrupts to see what interrupts are being handled
(PVR2, gdrom, BBA, etc.), and attach your dmesg output?

M. R.

Re: [linuxdc-dev]AICA interrupts

[Adrian M. <ad...@mc...>]

On Tuesday 01 Jan 2002 6:56 pm, M. R. Brown wrote:
>
> Can you check /proc/interrupts to see what interrupts are being handled
> (PVR2, gdrom, BBA, etc.), and attach your dmesg output?
cat /proc/interrupts

	CPU0
16:	422427		IPR_IRQ	timer
53:	253191		System ASIC		pvr2 VBL handler
80:	0		System ASIC		gdrom
81:	658		System ASIC		AICA
83:	2019		System ASIC		eth0

Re: [linuxdc-dev]AICA interrupts

[M. R. B. <mr...@0x...>]

* M. R. Brown <mr...@0x...> on Tue, Jan 01, 2002:

> * Adrian McMenamin <ad...@mc...> on Tue, Jan 01, 2002:
>=20
> > I am experimenting with the AICA interrupt - HW_EVENT_AICA_SYS - but I =
am=20
> > getting odd results:
> >=20
> >=20
> [...]
> > When this runs every call to writel(0x20, 0xa07028b8) appears to genera=
te=20
> > "unexpected IRQ trap at vector 0b" (though system output otherwise is n=
ormal).
> >=20
> > What have I done wrong?
> >=20
>=20
> I don't understand why you're getting the "unexpected IRQ ..." message, t=
he
> DC interrupt-handling code switches off of SH4 IRQ's 9, 11, and 13, so th=
ey
> should always be "expected" and return the virtual IRQ.  See
> arch/sh/kernel/setup_dc.c::systemasic_irq_demux() for more info.
>=20

I added the code you sent in your message.

Hmm, ok, I hit it too, but it's still a bit perplexing since
/proc/interrupts says AICA interrupts are being triggered;

# cat /proc/interrupts                                                     =
                                                                           =
   =20
           CPU0                                                            =
                                                                           =
   =20
 16:      11594         IPR-IRQ  timer                                     =
                                                                           =
   =20
 40:          0         IPR-IRQ  sci                                       =
                                                                           =
   =20
 41:        106         IPR-IRQ  sci                                       =
                                                                           =
   =20
 42:          0         IPR-IRQ  sci                                       =
                                                                           =
   =20
 43:        463         IPR-IRQ  sci                                       =
                                                                           =
   =20
 53:       6933     System ASIC  pvr2 VBL handler                          =
                                                                           =
   =20
 81:         32     System ASIC  AICA                                      =
                                                                           =
   =20
 83:       2597     System ASIC  eth0

But I still get the "unexpected IRQ" messages on playback.

I'm going to dig around the irq and DC irq stuff a bit more, I'll let you
know when I find out what's going on.

I'm also starting to suspect something a bit more insidious, after catting
/proc/interrupts a couple of times now I get "Unable to handle kernel
paging request" register dumps, followed by cat segfaulting.  Something
looks to be seriously broken.

M. R.

Re: [linuxdc-dev]AICA interrupts

[Adrian M. <ad...@mc...>]

On Tuesday 01 Jan 2002 7:18 pm, M. R. Brown wrote:
> * M. R. Brown <mr...@0x...> on Tue, Jan 01, 2002:
> > * Adrian McMenamin <ad...@mc...> on Tue, Jan 01, 2002:
> > > I am experimenting with the AICA interrupt - HW_EVENT_AICA_SYS - but I
> > > am getting odd results:
> >
> > [...]
> >
> > > When this runs every call to writel(0x20, 0xa07028b8) appears to
> > > generate "unexpected IRQ trap at vector 0b" (though system output
> > > otherwise is normal).
> > >
> > > What have I done wrong?
> >
> > I don't understand why you're getting the "unexpected IRQ ..." message,
> > the DC interrupt-handling code switches off of SH4 IRQ's 9, 11, and 13,
> > so they should always be "expected" and return the virtual IRQ.  See
> > arch/sh/kernel/setup_dc.c::systemasic_irq_demux() for more info.
>
> I added the code you sent in your message.
>
> Hmm, ok, I hit it too, but it's still a bit perplexing since
> /proc/interrupts says AICA interrupts are being triggered;
>
> # cat /proc/interrupts
>            CPU0
>  16:      11594         IPR-IRQ  timer
>  40:          0         IPR-IRQ  sci
>  41:        106         IPR-IRQ  sci
>  42:          0         IPR-IRQ  sci
>  43:        463         IPR-IRQ  sci
>  53:       6933     System ASIC  pvr2 VBL handler
>  81:         32     System ASIC  AICA
>  83:       2597     System ASIC  eth0
>
> But I still get the "unexpected IRQ" messages on playback.
>
> I'm going to dig around the irq and DC irq stuff a bit more, I'll let you
> know when I find out what's going on.
>
> I'm also starting to suspect something a bit more insidious, after catting
> /proc/interrupts a couple of times now I get "Unable to handle kernel
> paging request" register dumps, followed by cat segfaulting.  Something
> looks to be seriously broken.
>
> M. R.


My /proc/interrupts also indicates that AICA interrupts are being handled 
too. I have not had any problems with paging errors.

Further poking about suggests that this does not happen with every write of 
the 0xa07028b8, but only when something is written to the AICA memory. At 
least the number of "Unexpected IRQ traps..." matches the number of writes.

[Interestingly when I removed the enable and disable writes and just kept the 
pending one the whole system froze and could only be restored by switching 
off - not sure why that should be.]

Re: [linuxdc-dev]AICA interrupts

[Adrian M. <ad...@mc...>]

On Tuesday 01 Jan 2002 7:28 pm, Adrian McMenamin wrote:

> Further poking about suggests that this does not happen with every write of
> the 0xa07028b8, but only when something is written to the AICA memory. At
> least the number of "Unexpected IRQ traps..." matches the number of writes.
>
No, this is wrong too - as I have just had a case of three writes and only 
two error messages...

Re: [linuxdc-dev]AICA interrupts - problem solved?

[Adrian M. <ad...@mc...>]

It seems I was calling this incorrectly - the 'pending' bits need to be reset 
inside the interrupt handler as without that happening no new interrupts can 
be handled on the AICA (or something) - this obviously was not happening, but 
when the handler was rewritten:

////////////////////////////////////////////////////////////////
// Experimental interrupt handler                             //
////////////////////////////////////////////////////////////////

void aica_interrupt_handler(int i, void* p, struct pt_regs * ptr)
{
	writel(0x20, 0xa07028b8);
	spu_write_wait();  
}

The problem disappeared (nb - removed the write to 0xa07028b8 from elsewhere 
too).

Re: [linuxdc-dev]AICA interrupts - problem solved?

[Adrian M. <ad...@mc...>]

On Wednesday 02 Jan 2002 10:42 am, Adrian McMenamin wrote:
> It seems I was calling this incorrectly - the 'pending' bits need to be
> reset inside the interrupt handler as without that happening no new
> interrupts can be handled on the AICA (or something) - this obviously was
> not happening, but when the handler was rewritten:
>
> ////////////////////////////////////////////////////////////////
> // Experimental interrupt handler                             //
> ////////////////////////////////////////////////////////////////
>
> void aica_interrupt_handler(int i, void* p, struct pt_regs * ptr)
> {
> 	writel(0x20, 0xa07028b8);
> 	spu_write_wait();
> }
>
> The problem disappeared (nb - removed the write to 0xa07028b8 from
> elsewhere too).

However, a scan of /proc/interrupts also shows that while the interrupt 
handler is registered, there appear to be no interrupts being generated, so 
this does not seem a suitable vehicle in which handle buffer updates.