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
