Segher Boessenkool wrote:
>>> 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 :)
>>>> +/*
>>>> + * 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_.
I'm not telling this is the case. But I don't recall such behavior. It's been a
long time since this is done this way.
>>>> +static void flipper_pic_ack(unsigned int virq)
>>>> +{
>>>> + int irq = virq_to_hw(virq);
>>>> + void __iomem *io_base = get_irq_chip_data(virq);
>>>> +
>>>> + set_bit(irq, io_base + FLIPPER_ICR);
>>>> +}
>>>
>>> So it should be a simple write instead of an RMW here, right?
>>> As it is you are ACKing _all_ IRQs as far as I can see.
>>>
>>
>> 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?
>
> Segher
>
>
Thanks,
Albert
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
