Hi all,
I’m writting a kernel driver using KMDF.
Currently in the event callback:EvtDevicePrepareHardware, there is the interrupt resource type:CmResourceTypeInterrupt which I can get the Interrupt.Vector and store it in my device context storage.So, is this Interrupt.Vector unique for all devices in the system?
And as the interrupt event callback:EvtInterruptIsr provide the WDFINTERRUPT object, I use the WdfInterruptGetInfo on the object to get the WDF_INTERRUPT_INFO structure. In the WDF_INTERRUPT_INFO contains the Vector. Can i use this to verify with the Interrupt.Vector to check whether the interrupt is for my device?
Will very appreciate for any advice/guidance.
Thank you.
No.
Well, you’ll get back the same value that you got in your EvtDevicePrepareHardware, but that’s not helpful.
You don’t really WANT to check if the interrupt is “for your device” exactly – In your ISR, you want to interrogate the registers on your device to see if your device is currently requesting an interrupt. If your device IS requesting an interrupt, then you service your device. If your device is NOT requesting an interrupt, you do nothing further on your device (in this case, you have a shared interrupt and your device does not need service).
Remember, on the PCI (family) bus, there’s no real concept of who “owns” an interrupt. Interrupts are level-triggered signals, and more than one device at a time can be asserting the interrupt. Windows sorts all this out for you (essentially). So, all you have to worry about in your ISR is checking to see if your device is currently requesting an interrupt.
Peter
OSR
I think that KMDF hides the interrupt vector knowledge from you and you can
just forget about what is this.
ISRs never check the vector number even in WDM. For a WDM/PnP driver, the
only place where it sees this number is in MN_START_DEVICE, just to transfer it
from the IRP’s resource list to IoConnectInterrupt.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Hi all,
>
> I’m writting a kernel driver using KMDF.
>
> Currently in the event callback:EvtDevicePrepareHardware, there is the
interrupt resource type:CmResourceTypeInterrupt which I can get the
Interrupt.Vector and store it in my device context storage.So, is this
Interrupt.Vector unique for all devices in the system?
>
> And as the interrupt event callback:EvtInterruptIsr provide the WDFINTERRUPT
object, I use the WdfInterruptGetInfo on the object to get the
WDF_INTERRUPT_INFO structure. In the WDF_INTERRUPT_INFO contains the Vector.
Can i use this to verify with the Interrupt.Vector to check whether the
interrupt is for my device?
>
> Will very appreciate for any advice/guidance.
>
> Thank you.
>
Let me add a little to what Peter said.
Newer devices may use message-signaled interrupts. In fact, they are
required by the PCI-X and PCI-Express specs. In this case, a
well-designed device will have left some record in memory indicating
that a transaction is complete and it may not be necessary to actually
poll the device registers. You may find that you can determine
whether your device has interrupted just by examining in-memory
structures.
–
Jake Oshins
former Interrupt Guy
Microsoft
This post confers no rights and implies no warranties.
wrote in message news:xxxxx@ntdev…
>
>
> No.
>
>
>
> Well, you’ll get back the same value that you got in your
> EvtDevicePrepareHardware, but that’s not helpful.
>
> You don’t really WANT to check if the interrupt is “for your device”
> exactly – In your ISR, you want to interrogate the registers on
> your device to see if your device is currently requesting an
> interrupt. If your device IS requesting an interrupt, then you
> service your device. If your device is NOT requesting an interrupt,
> you do nothing further on your device (in this case, you have a
> shared interrupt and your device does not need service).
>
> Remember, on the PCI (family) bus, there’s no real concept of who
> “owns” an interrupt. Interrupts are level-triggered signals, and
> more than one device at a time can be asserting the interrupt.
> Windows sorts all this out for you (essentially). So, all you have
> to worry about in your ISR is checking to see if your device is
> currently requesting an interrupt.
>
> Peter
> OSR
>
>