quoted

quoted

quoted

Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of  
GAMECUBE_COMMON
is a good name?

I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.

Hollywood is 100% compatible to Flipper though.

No. There's no ARAM for example :)

ARAM is an external device.

quoted

quoted

quoted

quoted

+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/ 
clearing
+ * the corresponding bit in IMR. ACK'ing a request simply  
involves
+ * asserting the corresponding bit in ICR.
+ */

I looked it up in YAGCD; it says that _reading_ the ICR reg already
acks all interrupts (and clears the bits), you never write this reg!

YAGCD is not always right. You should not take it as _the truth_.

Oh I know.  But I have no better source of information.  Well I could
actually test it, that's very easy using OF :-)  Let's do that.

quoted

quoted

No, it acks just a single IRQ.

No it doesn't.  Say IRQs 1 and 3 are asserted, so the reg contains  
0x0a.
Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not  
just 0x02.

Let me rephrase it. No it should just ack a single IRQ :)

So then this is working by accident.
If that's the case, I guess it works because the interrupt is not  
cleared at the source and the ICR is set again immediately for any  
pending interrupt?

Probably, yes.  Also, you will not often have more than one interrupt
pending anyway (on the legacy PIC).


Segher