On Thu, Apr 3, 2014 at 12:09 PM, Ján Veselý <[email protected]> wrote: > 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?
Can anyone confirm/correct the above? I hope I'm missing something, because as described, there are tons of problems with it Jan > 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
