[RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support

[Segher Boessenkool]

>>>> 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