On Thu, Apr 3, 2014 at 8:00 AM, Jakub Jermar <[email protected]> wrote: > On 2.4.2014 23:51, Jakub Jermar wrote: >> In this approach, AFAIR, it would be primarily or exclusively the >> interrupt controller driver that would use the pseudocode. All other >> drivers would register for interrupts at the interrupt controller >> driver (itself a DDF driver) and receive interrupt notifications from >> it instead of from the kernel. So these other drivers would not >> provide pseudocode, because it would not be needed. > > When thinking about it, maybe this second approach will be necessary > because of the architecture of some of the more exotic platforms. > Meaning, that each driver will be receiving interrupts from or at least > via its parent in the device tree. And that all interrupt routing will > be closely based on the device tree hierarchy.
I thought Jiri might chip in some more details before continuing the discussion. So far might understanding of the new approach is: PIC driver irqcode disables specific irq line on interrupt and notifies uspace pic/platform driver. pic/platofrm driver cascades the information to all devices that use that line, and let them figure out the rest. The device that actually caused the interrupt will ask the pic/platform driver to reanable the line once it is safe again. Is this correct? I want to avoid the situation when we talk about different things :) Jan > > Take, for example, MIPS Malta. On Malta, the kernel does not have a > chance to figure out the exact IRQ number unless it knows something > about the system controller (i.e. little brother Malta platform driver > in the kernel, yuck) and the buses that are attached to it. For the > kernel, all IRQs look the same (just an external interrupt vector, the > real ISA IRQ number needs to be read from a system board-specific > register), so it is reasonable to have them delivered to the Malta > platform driver, that is the only reasonable component that can actually > figure out this number and send it to the corresponding subtree. > > Just typing as thoughts emerge. > > Jakub > > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
