From: Murugesan on 18 Nov 2009 00:56 Actually I am interested in performing initialization of h/w first, only after which interrupt enabling comes into picture. That's why I did everything in selfmanaged-io, instead of collapsing my sequence of operation b/w EvtInterruptEnable, EvtDeviceD0EntryPostInterruptsEnabled & Selfmanaged IO. Does failing to enable interrupts in EvtInterruptEnable or EvtDeviceD0EntryPostInterruptsEnabled callbacks makes the interrupt handler not to be invoked ? Do they really have any relation ? "Doron Holan [MSFT]" wrote: > you should use EvtInterruptEnable and EvtDeviceD0EntryPostInterruptsEnabled > for the work you are doing in self managed io > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > news:7FE38A6D-FFDE-4D59-8537-ECB31B99A319(a)microsoft.com... > > Thanks for your inputs. I've programmed my h/w correctly. The only > > variance > > is like, > > my h/w initialization & enabling interrupts has been done in the context > > of > > SelfManagedIoInit() callback, which is called after D0entry callback. Also > > i > > am sure that the framework retreived the interrupt resource > > information(mainly IRQ) by checking with WdfInterruptGetInfo(). > > > > Murugesan > > > > "Doron Holan [MSFT]" wrote: > > > >> are your programming your hw to generate the interrupt and route it > >> correctly? are you programming your hw correctly in D0Entry? > >> > >> d > >> > >> -- > >> > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > >> news:70DE1BF5-1409-408C-B30F-C2E527AD636C(a)microsoft.com... > >> > Hi all, > >> > > >> > I am working with a PCI based WDF function driver. I've created an > >> > interrupt object using wdfinterruptcreate() & initialized the > >> > WDF_INTERRUPT_CONFIG with ISR handler, DPC routine. From the WDF > >> > documentation, i found that the framework takes care of adding > >> > interrupt > >> > resource information when the device moves into D0 state. Now the > >> > problem > >> > is, > >> > after doing all this initialization my interrupt handler doesn't gets > >> > invoked > >> > when my hardware raises an interrupt after the device moves into D0 > >> > state > >> > eventhough all the interrupts has been enabled. I could notice that the > >> > framework has added the interrupt resource information to the interrupt > >> > object, by using WdfInterruptGetInfo() in the context of > >> > SelfManagedIoInit > >> > callback. Am I missing anything related with the interrupt handling? > >> > > >> > Thanks, > >> > Murugesan > >> > >> . > >> > . >
From: Doron Holan [MSFT] on 20 Nov 2009 18:37 the kmdf callbacks are just an abstraction, you can choose to use the abstraction or not. if you need to initialize before the interrupt is enabled, do that in EvtDeviceD0Entry, enable the interrupt in EvtInterruptEnable d -- This posting is provided "AS IS" with no warranties, and confers no rights. "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message news:D20534EA-16EB-472D-9BDF-DA11C37E693F(a)microsoft.com... > Actually I am interested in performing initialization of h/w first, only > after which interrupt enabling comes into picture. That's why I did > everything in selfmanaged-io, instead of collapsing my sequence of > operation > b/w EvtInterruptEnable, EvtDeviceD0EntryPostInterruptsEnabled & > Selfmanaged > IO. > > Does failing to enable interrupts in EvtInterruptEnable or > EvtDeviceD0EntryPostInterruptsEnabled callbacks makes the interrupt > handler > not to be invoked ? Do they really have any relation ? > > > "Doron Holan [MSFT]" wrote: > >> you should use EvtInterruptEnable and >> EvtDeviceD0EntryPostInterruptsEnabled >> for the work you are doing in self managed io >> >> d >> >> -- >> >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message >> news:7FE38A6D-FFDE-4D59-8537-ECB31B99A319(a)microsoft.com... >> > Thanks for your inputs. I've programmed my h/w correctly. The only >> > variance >> > is like, >> > my h/w initialization & enabling interrupts has been done in the >> > context >> > of >> > SelfManagedIoInit() callback, which is called after D0entry callback. >> > Also >> > i >> > am sure that the framework retreived the interrupt resource >> > information(mainly IRQ) by checking with WdfInterruptGetInfo(). >> > >> > Murugesan >> > >> > "Doron Holan [MSFT]" wrote: >> > >> >> are your programming your hw to generate the interrupt and route it >> >> correctly? are you programming your hw correctly in D0Entry? >> >> >> >> d >> >> >> >> -- >> >> >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> >> >> >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message >> >> news:70DE1BF5-1409-408C-B30F-C2E527AD636C(a)microsoft.com... >> >> > Hi all, >> >> > >> >> > I am working with a PCI based WDF function driver. I've created an >> >> > interrupt object using wdfinterruptcreate() & initialized the >> >> > WDF_INTERRUPT_CONFIG with ISR handler, DPC routine. From the WDF >> >> > documentation, i found that the framework takes care of adding >> >> > interrupt >> >> > resource information when the device moves into D0 state. Now the >> >> > problem >> >> > is, >> >> > after doing all this initialization my interrupt handler doesn't >> >> > gets >> >> > invoked >> >> > when my hardware raises an interrupt after the device moves into D0 >> >> > state >> >> > eventhough all the interrupts has been enabled. I could notice that >> >> > the >> >> > framework has added the interrupt resource information to the >> >> > interrupt >> >> > object, by using WdfInterruptGetInfo() in the context of >> >> > SelfManagedIoInit >> >> > callback. Am I missing anything related with the interrupt handling? >> >> > >> >> > Thanks, >> >> > Murugesan >> >> >> >> . >> >> >> . >>
From: Murugesan on 23 Nov 2009 01:19 Thanks for your info Doron. I'll try that. "Doron Holan [MSFT]" wrote: > the kmdf callbacks are just an abstraction, you can choose to use the > abstraction or not. if you need to initialize before the interrupt is > enabled, do that in EvtDeviceD0Entry, enable the interrupt in > EvtInterruptEnable > > d > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > news:D20534EA-16EB-472D-9BDF-DA11C37E693F(a)microsoft.com... > > Actually I am interested in performing initialization of h/w first, only > > after which interrupt enabling comes into picture. That's why I did > > everything in selfmanaged-io, instead of collapsing my sequence of > > operation > > b/w EvtInterruptEnable, EvtDeviceD0EntryPostInterruptsEnabled & > > Selfmanaged > > IO. > > > > Does failing to enable interrupts in EvtInterruptEnable or > > EvtDeviceD0EntryPostInterruptsEnabled callbacks makes the interrupt > > handler > > not to be invoked ? Do they really have any relation ? > > > > > > "Doron Holan [MSFT]" wrote: > > > >> you should use EvtInterruptEnable and > >> EvtDeviceD0EntryPostInterruptsEnabled > >> for the work you are doing in self managed io > >> > >> d > >> > >> -- > >> > >> This posting is provided "AS IS" with no warranties, and confers no > >> rights. > >> > >> > >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > >> news:7FE38A6D-FFDE-4D59-8537-ECB31B99A319(a)microsoft.com... > >> > Thanks for your inputs. I've programmed my h/w correctly. The only > >> > variance > >> > is like, > >> > my h/w initialization & enabling interrupts has been done in the > >> > context > >> > of > >> > SelfManagedIoInit() callback, which is called after D0entry callback. > >> > Also > >> > i > >> > am sure that the framework retreived the interrupt resource > >> > information(mainly IRQ) by checking with WdfInterruptGetInfo(). > >> > > >> > Murugesan > >> > > >> > "Doron Holan [MSFT]" wrote: > >> > > >> >> are your programming your hw to generate the interrupt and route it > >> >> correctly? are you programming your hw correctly in D0Entry? > >> >> > >> >> d > >> >> > >> >> -- > >> >> > >> >> This posting is provided "AS IS" with no warranties, and confers no > >> >> rights. > >> >> > >> >> > >> >> "Murugesan" <Murugesan(a)discussions.microsoft.com> wrote in message > >> >> news:70DE1BF5-1409-408C-B30F-C2E527AD636C(a)microsoft.com... > >> >> > Hi all, > >> >> > > >> >> > I am working with a PCI based WDF function driver. I've created an > >> >> > interrupt object using wdfinterruptcreate() & initialized the > >> >> > WDF_INTERRUPT_CONFIG with ISR handler, DPC routine. From the WDF > >> >> > documentation, i found that the framework takes care of adding > >> >> > interrupt > >> >> > resource information when the device moves into D0 state. Now the > >> >> > problem > >> >> > is, > >> >> > after doing all this initialization my interrupt handler doesn't > >> >> > gets > >> >> > invoked > >> >> > when my hardware raises an interrupt after the device moves into D0 > >> >> > state > >> >> > eventhough all the interrupts has been enabled. I could notice that > >> >> > the > >> >> > framework has added the interrupt resource information to the > >> >> > interrupt > >> >> > object, by using WdfInterruptGetInfo() in the context of > >> >> > SelfManagedIoInit > >> >> > callback. Am I missing anything related with the interrupt handling? > >> >> > > >> >> > Thanks, > >> >> > Murugesan > >> >> > >> >> . > >> >> > >> . > >> > . >
First
|
Prev
|
Pages: 1 2 Prev: WDF Wait Lock Usage Next: Problem attaching WinDbg to target after WDK7600 upgrade |