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

Albert Herranz albert_herranz at yahoo.es
Thu Nov 26 04:13:41 EST 2009


Segher Boessenkool wrote:
>>  config GAMECUBE_COMMON
>>      bool
>>      select NOT_COHERENT_CACHE
>> +    select FLIPPER_PIC
> 
> 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.

>> +#define pr_fmt(fmt) DRV_MODULE_NAME ": " fmt
> 
> Unused
> 

Nope. It is used via the pr_{err,info,...} macros.

>> +/*
>> + * 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.
>> + */
> 
>> +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.
But the simple write idea may work. I need to check if writing 0s causes no harm (which IIRC is true).

>> +unsigned int flipper_pic_get_irq(void)
>> +{
>> +    void __iomem *io_base = flipper_irq_host->host_data;
>> +    int irq;
>> +    u32 irq_status;
>> +
>> +    irq_status = in_be32(io_base + FLIPPER_ICR) &
>> +             in_be32(io_base + FLIPPER_IMR);
>> +    if (irq_status == 0)
>> +        return -1;    /* no more IRQs pending */
>> +
>> +    __asm__ __volatile__("cntlzw %0,%1" : "=r"(irq) : "r"(irq_status));
>> +    return irq_linear_revmap(flipper_irq_host, 31 - irq);
>> +}
> 
> There are generic macros for this kind of thing, no need for asm.  ffs()
> or something.
> 

__ffs() matches exactly that. Thanks.

Cheers,
Albert



More information about the Linuxppc-dev mailing list