WDF EvtIoStop, are interrupts hooked when this callback is called?

Discussion in 'Windows Vista Drivers' started by Harison213, Feb 15, 2007.

  1. Harison213

    Harison213 Guest

    Hi,

    I have a driver which can have some requests which are only completed after
    receiving an appropriate interrupt. These requests are marked as pending
    until the interrupt is received.

    If such a request is pending when system tries to sleep, Windows will
    prevent the transition until the request is somehow handled e.g. cancelled or
    completed. WDF provides EvtIoStop callback functionality where you can call
    WdfRequestStopAcknowledge to enable the system transition to a lower power
    state.

    The Framework calls EvtIoStop before calling EvtInterruptDisable. The
    problem is, and I couldn't find this documented anywhere, does the Framework
    disconnect the interrupt object before calling EvtIoStop? In other words, if
    I acknowledge a stop request, which means I shouldn't try to access the
    hardware anymore, can I make sure that I won't receive any interrupts in the
    short period of time between EvtIoStop being called until EvtInterruptDisable
    is called?

    Thanks,
    Harison213
     
    Harison213, Feb 15, 2007
    #1
    1. Advertisements

  2. I don't think any interrupts are disconnected on going low power, KMDF or
    no KMDF.

    Interrupts must be _disabled using a hardware register of your device_ (or
    the stray interrupt during Resuming Windows phase will hang the machine) on
    going low-power, but IoDisconnectInterrupt is NOT necessary to be called while
    going low-power.
     
    Maxim S. Shatskih, Feb 15, 2007
    #2
    1. Advertisements

  3. Maxim, please read about KMDF before you speak (authoritatively) about it
    ;). KMDF will disconnect the interrupt via IoDisconnectInterrupt if your
    device is power pagable (the default, you would have to explicitly mark it
    as non power pagable). By calling IoDisconnectInterrupt, we reduce the
    window of an interrupt storm if this is the last interrup enabled on the
    particular IRQ.

    the pwr down sequence is this
    EvtDeviceSelfManagedIoSuspend
    <stop all power managed queues, EvtIoStop can be called>
    EvtDeviceD0ExitPreinterruptsDisabled
    EvtInterruptDisable - this is where you program the hardware to disable the
    interrupt
    <KMDF disconnects the interrupt>
    EvtDeviceD0Exit

    Harison, if you need the interrupt active during EvtIoStop, then there is a
    window between where the last EvtIoStop is called and EvtInterruptDisable
    where you can get interrupts. If you don't need the interrupt during
    EvtIoStop, you can disable the interrupt on your own in
    EvtDeviceSelfManagedIoSuspend

    d
     
    Doron Holan [MS], Feb 16, 2007
    #3
  4. Harison213

    Harison213 Guest

    Doran, thanks for your comment.

    The driver is using power-managed queues, and I have the option of either
    disabling interrupts in EvtIoStop or not - I'd rather not to!

    The actual question is, if I don't disable the interrupts in EvtIoStop and I
    receive an interrupt after calling WdfRequestStopAcknowledge in EvtIoStop
    (but before EvtInterruptDisable is called) documentation says you shouldn't
    access the hardware. However, by receiving the interrupt, not only I'm going
    to access the hardware - few register accesses though - but also I will queue
    a DPC object in order to complete the pending request.

    Considering above situation:
    1. Is it alright to access the hardware after WdfRequestStopAcknowledge is
    called (e.g. in the ISR)? Documentation says you shouldn't.
    2. If you postpone the processing of a request by calling
    WdfRequestStopAcknowledge in EvtIoStop, can you complete that same request
    _before_ EvtIoResume for that request is called? E.g. you postpone the
    request, then receive an interrupt just before EvtInterruptDisable (before
    leaving D0), and you try to complete the request. Is this allowed?

    Thanks,
    Harison
     
    Harison213, Feb 16, 2007
    #4
  5. After EvtIoStop if you are only accessing the hardware in the Isr - not in
    the DPC - then you are fine. The fact that ISR is running after EvtIoStop
    means that the device hasn't been powered down yet (because framework asks
    you to disable the interrupt at DIRQL before calling D0Exit). The reason you
    cannot access the hardware in the DPC is because your DPC could be racing
    with the thread that's powering-down the device on another processor. So to
    be safe you should call WdfDpcCancel(dpc, TRUE) in D0Exit to make sure that
    DpcForIsr has run to completion before powering down the device. It's
    possible that framework might be doing this but I'm not sure. I will let you
    know.

    As to question of completing the acknowledged request in the DPC, yes you
    can do that. We allow completing an acknowledged request before EvtIoResume.

    -Eliyas
     
    Eliyas Yakub [MSFT], Feb 17, 2007
    #5
  6. Scratch my previous response. I did get that right.

    The simple answer is that you can access the hardware in Isr and DpcForIsr
    after EvtIoStop. After stopping all the power managed queues, the framework
    asks the driver to disable the interrupt at DIRQL and then it flushes the
    dpcs to make sure the DpcForIsr has run to completion before calling
    D0Exit.

    So if you have to complete an already stop-acknowledged request in the Dpc,
    you can do that.

    -Eliyas
     
    Eliyas Yakub [MSFT], Feb 17, 2007
    #6
  7. Harison213

    Harison213 Guest

    Eliyas, thanks for your comment. It couldn't be more clarifying than this :)
     
    Harison213, Feb 19, 2007
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.