Hi, this is all rather generic (and obvious). I thought there was something specific in the pipeline. anyway I had to switch to other project. So just few questions:
How do you plan to handle shared interrupts? What if the interrupt is shared with the system timer, without per-driver pseudocode it would mean returning to uspace with preemptive scheduling disabled. What about devices that need low latency interrupt handling? Example i8042 - with 100Hz sampling rate and 3 packets per sample, you have 3 ms to react before information loss. Example2: display controllers buffer swap needs to be done before displaying of the next frame begins (16.6ms - time_to_display_one_frame), there might be more stuff that needs to be handled during vblank (like memory reclocking) regards, Jan On Tue, Apr 22, 2014 at 10:30 AM, Jiri Svoboda <[email protected]> wrote: > Hi, > > the problem being solved with IRQ pseudocode is that interrupt needs to be > stopped from re-ocurring somehow before we return from interrupt handler > context. That means the interrupt needs to be stopped somewhere along the > path between it's origin and destination (inclusive). > > The current approach is that this is done by the device driver installing > IRQ pseudocode that cancels the interrupt condition in the device (or > otherwise makes the device stop interrupting). An alternate approach is to > block the interrupt in the interrupt controller. I am not sure whether this > is always possible, but I think it should work for the PC, at least. > > The usefulness of a pseudocode compiler is proportional to the amount of > pseudocode that will be written. In one extreme case you can have pseudocode > for many device drivers, in the other extreme case we could have interrupt > controller drivers in the kernel, blocking interrupts in interrupt > controller and hence no pseudocode at all. Or, a middle case where device > drivers don't use pseudocode, but interrupt controller drivers are in > userspace and use pseudocode - so we have some (smaller) amount of > pseudocode. > > Having less pseudocode (albeit compiled) is preferable - an > interrupt-controller-based solution makes device drivers simpler. - although > I haven't investigated whether this will work for all platforms. > > Hopes this helps, > Jiri > > ---------- Původní zpráva ---------- > Od: Ján Veselý <[email protected]> > Komu: HelenOS development mailing list <[email protected]> > Datum: 19. 4. 2014 20:01:08 > Předmět: Re: [HelenOS-devel] Ticket #358 > > > 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 > > > _______________________________________________ > 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
