On Tue, Sep 16, 2008 at 7:24 PM, Scott Wood <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 06:08:34PM -0400, Jon Smirl wrote: >> You have to map between GPIO and IRQ inside the interrupt handlers so >> it has to be reasonably fast. This gets done on every shared interrupt >> so you will end up building mapping tables. Also, gpio_to_irq() >> doesn't take the gpio chip struct as a parameter. > > Well, that sucks. We should be removing magic global numberspaces, not > adding them. > >> Why does this mess with all of ther GPIO controllers? If they generate >> interrupts they obviously have to coordinate with the VIRQ system. > > And if they don't generate interrupts, and they decide they can also > just park themselves at MAX_IRQ?
More coordination has to be going on here, as far as I can tell gpiolib has a built in assumption that all gpios in a system are uniquely numbered. I guess that since most systems can't dynamically add GPIO the problem hasn't been addressed. It could be fixed by creating a function for obtaining the max gpio id in use and then using it as a base for any that are added later. The core complain here is: what happens if you assign non-interrupting GPIOs to 1-8 which are also hardware IRQs and then use irq functions on these non-interrupting GPIO ids. My answer to that is don't assign GPIO ids that are legal hardware interrupts. The function for determing max GPIO ID in use may even exist in the ARM code, I haven't gone looking for it. In the mpc5200 most (maybe all?) GPIOs are capable of being an interrupt source so a 1:1 mapping with VIRQs is the natural solution. mpc5200_pic.h reserves 208 spots for hardware interrupts. I don't know why, there aren't that many possible. There are 56 GPIO pins, so you end up with 264 virqs total. PowerPC defaults to 512 virqs available. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev