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.
+/*
+ * 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.
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev