keyboard IRQ handler - Minix

This is a discussion on keyboard IRQ handler - Minix ; Hi all, As I see in a minix related document before, for obtain the keyboard input, the TTY driver does a inport() and strobe it back to acknoledge it. So when reading the Minix 3 source i was expected to ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: keyboard IRQ handler

  1. keyboard IRQ handler

    Hi all,

    As I see in a minix related document before, for obtain the keyboard
    input, the TTY driver does a inport() and strobe it back to acknoledge
    it. So when reading the Minix 3 source i was expected to find a
    interrupt handler with IRQ_STROBE policy for keyboard.

    I was surprised when I found this call on kb_init_once();

    sys_irqsetpolicy(KEYBOARD_IRQ, IRQ_REENABLE, &irq_hook_id))

    How keyboard IRQ handler acts for read inputs in MINIX3? Does it uses
    the generic_handler()? If yes, Does this generic handler is used for
    read some data from keyboard or only to notify and REENABLE interrups?
    Why?

    Thanks,

  2. Re: keyboard IRQ handler

    All,

    > I was surprised when I found this call on kb_init_once();
    >
    > sys_irqsetpolicy(KEYBOARD_IRQ, IRQ_REENABLE, &irq_hook_id))
    >
    > How keyboard IRQ handler acts for read inputs in MINIX3? Does it uses
    > the generic_handler()? If yes, Does this generic handler is used for
    > read some data from keyboard or only to notify and REENABLE interrups?
    > Why?


    Yes, as the tty driver is outside the kernel address space,
    generic_handler() is called for those irq's, which sends a notify() to
    TTY. IRQ_REENABLE simply means that the irq is automatically unmasked
    when it is raised, instead of it being unmasked explicitly (by the
    driver) with a call to sys_irqenable().

    As acknowledging irq's to the device (as opposed to the interrupt
    controller) is device-dependent, there's no practical way to ackowledge
    them in the kernel. An example of a device driver that acknowledges irqs
    explicitly and needs to have the irq disabled until it is explicitly
    re-enabled is at_wini (see ack_irqs()).

    =Ben



  3. Re: keyboard IRQ handler

    On 31 ene, 06:39, Ben Gras wrote:
    > All,
    >
    > > I was surprised when I found this call on kb_init_once();

    >
    > > sys_irqsetpolicy(KEYBOARD_IRQ, IRQ_REENABLE, &irq_hook_id))

    >
    > > How keyboard IRQ handler acts for read inputs in MINIX3? Does it uses
    > > the generic_handler()? If yes, Does this generic handler is used for
    > > read some data from keyboard or only to notify and REENABLE interrups?
    > > Why?

    >
    > Yes, as the tty driver is outside the kernel address space,
    > generic_handler() is called for those irq's, which sends a notify() to
    > TTY. IRQ_REENABLE simply means that the irq is automatically unmasked
    > when it is raised, instead of it being unmasked explicitly (by the
    > driver) with a call to sys_irqenable().
    >
    > As acknowledging irq's to the device (as opposed to the interrupt
    > controller) is device-dependent, there's no practical way to ackowledge
    > them in the kernel. An example of a device driver that acknowledges irqs
    > explicitly and needs to have the irq disabled until it is explicitly
    > re-enabled is at_wini (see ack_irqs()).
    >
    > =Ben


    Ok, today I compared MINIX3 generic_handler() vs Jorrit Thesis
    generic_handler(). It is not the same code as I initially think. There
    is no IRQ_READ_PORT, IRQ_STROBE, IRQ_WRITE_PORT, etc policies.

    So now I m suposing there isn't any handler who read/write IO ports,
    right? But what happened with Jorrit proposal on use multi predefined
    policies for handlers like exposed on his master thesis for MINIX 3?

    Vesmar,

+ Reply to Thread