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