none
SPB driver shall register for 2 interrupts? one for its own and other for GPIO assigned to it. RRS feed

  • Question

  • I have small question where I am trying to add one GPIO resource to I2C driver.

    There is one device XYZ connected to this GPIO pin.

    I2C driver has its own interrupt allocated but I want to assign one GPIO interrupt as well in UEFI.

    I have done that in UEFI and I can see that in EvtDevicePrepareHardware, I get that interrupt resource properly.

    My question is if I2C driver will get interrupt (or its ISR will get triggered) if XYZ device sends interrupt?

    Or do I need to write another ISR handler for handling interrupts regarding this GPIO pin?

    So there will be two ISR handlers inside my I2C driver. One for regular i2c transfer complete interrupt and another for external device triggerred GPIO interrupt.

    Let me know if existing ISR routine enough or I need to write another ISR.

    Thanks.

    Thursday, November 29, 2012 12:29 PM

Answers

  • You will need to create two WDFINTERRUPT objects, either in EvtDeviceAdd or EvtDevicePrepareHardware, as documented here. Even though you need to create two objects, you could hook them up to the same ISR if you wanted to.
    Tuesday, December 4, 2012 2:30 AM
  • What you are assuming is correct. The only thing to watch out for is no other device must be receiving the GPIO pin as an interrupt resource. If the GPIO pin is exclusively assigned to your device, then it is fine.
    • Marked as answer by Prafull S Monday, December 10, 2012 8:44 AM
    Friday, December 7, 2012 5:07 PM

All replies

  • You will need to create two WDFINTERRUPT objects, either in EvtDeviceAdd or EvtDevicePrepareHardware, as documented here. Even though you need to create two objects, you could hook them up to the same ISR if you wanted to.
    Tuesday, December 4, 2012 2:30 AM
  • However you need to be careful here. In your scenario when XYZ is generating the interrupt, do you expect want both XYZ driver and I2C driver to have an ISR for that interrupt? The ISRs for those 2 drivers would be called one after the other. You must *not* take a dependency on the order in which the ISRs are called. So if the ISR for the first driver acknowledges the interrupt, your ISR for the second driver would not get called.

    pg - This posting is provided "AS IS" with no warranties, and confers no rights.


    Wednesday, December 5, 2012 6:13 PM
  • Okay. What I want here is write two ISRs. Named as ISRforI2C and ISRforXYZ. Now create two WDFINTERRUPT objects. Named as IntrObjForI2C and IntrObjForXYZ.

    Hook ISRForI2C with IntrObjForI2C and ISRForXYZ with IntrObjForXYZ.

    Then can I expect that ISRforI2C will trigger when I2C controller completes transfer?

    Also same way ISRForXYZ will trigger when XYZ device toggles GPIO pin?

    Is it possible that if XYZ device sends GPIO interrupt will result in ISRForI2C to get called? I don't think so but please confirm.

    Same way I expect if I2C transfer complets then only I shall get call for ISRForI2C and shall not get call for ISRForXYZ.

    Please clarify so it will solve my confusion.


    • Edited by Prafull S Friday, December 7, 2012 12:24 PM spell mistake
    Friday, December 7, 2012 11:10 AM
  • What you are assuming is correct. The only thing to watch out for is no other device must be receiving the GPIO pin as an interrupt resource. If the GPIO pin is exclusively assigned to your device, then it is fine.
    • Marked as answer by Prafull S Monday, December 10, 2012 8:44 AM
    Friday, December 7, 2012 5:07 PM
  • Thanks Rahul. That solves my doubt.
    Monday, December 10, 2012 8:45 AM
  • Rahul, I am seeing a weird issue.

    The GPIO resource allocated to SPB driver stops sending interrupt after some time.

    I checked that GPIO interrupt is disabled.

    I think it is happening because WDF puts SPB driver in D3 and prior to that disables all interrupts associate with it.

    Any idea how I can modify the spb driver so that it will be always in D0 state?

    WDF or windows shall not call D0 entry/exit calls for that.

    Can you give guidance how to do that?

    Wednesday, December 26, 2012 2:12 PM
  • Again, I am assuming this is for testing purposes only.

    Yes, WDF will automatically disable interrupts before putting the device in Dx. Your I2C controller may be going to Dx because it has registered an idle timeout with WDF (WdfDeviceAssignS0IdleSettings). If you remove that, your device should stay in D0.

    Wednesday, December 26, 2012 7:31 PM
  • Thanks Rahul. If I disable reporting D0Entry and D0Exit function, it works fine.

    Do you know how i can solve this problem with supporting D3 state?

    I find sometime, my i2c driver is in sleep. Then there is GPIO interrupt from XYZ device but my I2C driver's ISRForXYZ does not get called. (as mentioned earlier GPIO interrupt is assigned to I2C driver for special case)

    Then I rechecked and I saw that WDF still disables GPIO interrupt so it does not get it.

    Any idea how to solve with supporting D3 state to I2C driver? Is there any support for WDF for this?

    Thursday, January 3, 2013 8:23 AM
  • You are enabled for wake, the interrupt shoild trigger wake. Otherwise, your device should not be generating interrupts in low power

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, January 3, 2013 3:26 PM
  • Dear Holan:

    How to enable for wake for generating interrupt in low power?

    Tuesday, March 12, 2013 11:26 PM
  • Hi Rahul / Doron,

    by "You are enabled for wake, the interrupt shoild trigger wake"

    Any idea how we can enable interrupt while device is in D3 using above method? Suppose device has property to get interrupt even in sleeping state. (HID type of device?)

    Wednesday, September 11, 2013 5:55 AM