Hi Michael,
On Mon, Apr 2, 2012 at 00:44, Michael Schmitz <schmitzmic@xxxxxxxxxxxxxx> wrote:
Part 1 (this): make room for the EtherNAT interrupts - they appear at
vectors 0xc3 (USB ISP1160) and 0xc4 (SMC91C111)
Is there any specific reason you cannot use atari_register_vme_int(), like
drivers/net/ethernet/amd/atarilance.c, to avoid increasing NR_IRQS?
From what I read in atari_register_vme_int(), it returns the next free
VME interrupt starting at VME_SOURCE_BASE. This required the vector
number to be programmable in the correspomding VME device.
To the best of my knowledge, vector numbers are fixed (0xc3 and 0xc4)
for the EtherNAT.
OK. If they are fixed, there's nothing we can do about that.
I definitely need to increase NR_IRQS - it might be better to leave
VME_MAX_SOURCES unchanged and change the NUM_ATARI_SOURCES definition
above instead.
I'm uncertain whether the complicated definition of NUM_ATARI_SOURCES
is needed anymore - are the IRQ_VECTOR_TO_SOURCE and
IRQ_SOURCE_TO_VECTOR macros still used anywhere?
Only the latter:
drivers/net/ethernet/amd/atarilance.c: IO->ivec =
IRQ_SOURCE_TO_VECTOR(dev->irq);
drivers/net/ethernet/amd/atarilance.c: *RIEBL_IVEC_ADDR =
IRQ_SOURCE_TO_VECTOR(dev->irq);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
