I have a specific question about porting a working WDM driver to WDF. This driver is for a device on the chipset’s SMBus.
The device is talked to over the SMBus but shares a PCI IRQ (not the SMBus IRQ). Can I write an ISA (Root), PnP WDF driver which can share a PCI IRQ?
I’ve read the posts here about using ‘IRQConfig’ in the *.INF file, but those posts all seem to be about WDM drivers. Will this work in a WDF driver? If so, how is this done in WDF?
I’ve searched through the samples on the current WDK but none of the WDF samples match what I need to do.
The assigning of the IRQ is outside of the driver, if your WDM driver
works correctly then a KMDF driver should do the same. IRQConfig will
work with KMDF just fine.
> I have a specific question about porting a working WDM driver to WDF. This driver is for a device on the chipset’s SMBus. > > The device is talked to over the SMBus but shares a PCI IRQ (not the SMBus IRQ). Can I write an ISA (Root), PnP WDF driver which can share a PCI IRQ? > > I’ve read the posts here about using ‘IRQConfig’ in the *.INF file, but those posts all seem to be about WDM drivers. Will this work in a WDF driver? If so, how is this done in WDF? > > I’ve searched through the samples on the current WDK but none of the WDF samples match what I need to do. > > Thanks
The WDM driver uses a named notification event “IoCreateNotificationEvent” to communicate with applications. Unfortunately I cannot change this behavior because the apps are not under my control.
Can a WDF driver use the same mechanism? Can I just use the WDM “IoCreateNotificationEvent” in a WDF driver?
Mm
On Dec 18, 2010 5:03 PM, > wrote: > Thanks for your quick reply, Don. > > The WDM driver uses a named notification event “IoCreateNotificationEvent” to communicate with applications. Unfortunately I cannot change this behavior because the apps are not under my control. > > Can a WDF driver use the same mechanism? Can I just use the WDM “IoCreateNotificationEvent” in a WDF driver? > > Thanks > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I don’t know whether android autocorrect got me, or I just got lost in all
the similar acronyms.
Mm
On Dec 18, 2010 6:03 PM, “Don Burn” wrote: > That is what Martin meant, there are no restrictions in calling standard > kernel calls, you don’t have to stay completely in the framework. > > > Don Burn (MVP, Windows DKD) > Windows Filesystem and Driver Consulting > Website: http://www.windrvr.com > Blog: http://msmvps.com/blogs/WinDrvr > > > > > “ulyxb12x+xxxxx@gmail.com ” < ulyxb12x+xxxxx@gmail.com > wrote in message > news:xxxxx@ntdev: > >> Thanks mm, but what about Kmdf calling out to WDM? >> >> Thanks > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Thanks Don and Martin. Your help is greatly appreciated.
One last question on this:
With an ‘IRQConfig’ in the *.INF file can I just configure the interrupt object the same way I would for a PCI device? Can I use WDF_INTERRUPT_CONFIG_INIT() and WdfInterruptCreate(), etc?
Yes if you put your definitions in the INF file they will be given to
you in the start device handling code just like PCI. Be sure to mare
the interrupt shareable, or the system will complain about a conflict
and not configure your device.
> Thanks Don and Martin. Your help is greatly appreciated. > > One last question on this: > > With an ‘IRQConfig’ in the *.INF file can I just configure the interrupt object the same way I would for a PCI device? Can I use WDF_INTERRUPT_CONFIG_INIT() and WdfInterruptCreate(), etc? > > Thanks
That’s exactly the information I’ve been searching for.
I work in the embedded world where it’s now common for embedded Windows to run on devices that have custom, unique hardware. My goal is to take advantage of the Framework.
That’s exactly the information I’ve been searching for.
I work in the embedded world where it’s now common for embedded Windows to
run on devices that have custom, unique hardware. My goal is to take
advantage of the Framework.
Well, I have this WDF driver loading and unloading, etc, using PnP, as long as I use a completely unused IRQ. WdfInterruptCreate will fail if I ask for the shared, level-triggered, PCI IRQ that is actually required. The logs indicate that Windows cannot tell if the required IRQ should be allowed to be shared.
I use IRQConfig=LS:XX in the *.INF file, and I call WdfInterruptCreate with InterruptConfig.ShareVector = WdfTrue; But only an unused IRQ will succeed.
I can get the required IRQ using IoConnectInterrupt, but I’d really like to get the WdfInterruptCreate call working. I’m hoping somebody will give me some idea on what I need to do to convince Windows that it’s alright to share the IRQ.
Can you restate your problem from the beginning, please?
You want to control a device that’s connected via the SMBus, and you current have a working WDM driver that controls this device… is that correct?
I find that, in itself, pretty interesting: In order to talk with a device on the SMBus wouldn’t you need an SMBus driver. Who’s playing the role of master on this SMBus… who talks to the controller… and by what method?
And exactly WHICH IRQ is it you’re trying to claim?
The platform is a custom, embedded platform that runs Windows-XP Embedded (SP3).
This is the only device connected to the SMBus. There is no ‘bus driver’ as this is the only device on the SMBus. The platform and image are ‘locked-down’ so there never will be another device on it’s SMBus.
It shares an IRQ with PCI devices (SATA and Ethernet). It will either be IRQ19 or IRQ22 depending on the version of the hardware. I have absolutely no control over the hardware design, it’s done and won’t change.
I wrote a WDM driver for the original platform ~ two years ago. Now there is an updated platform with a newer Intel chipset. I’m porting the driver over.
I decided to make it a KMDF driver mostly as a learning experience. The WDM version worked fine and I could have quickly ported it over, but this is a chance for me to learn about KMDF and get paid while doing it.
I see my questions weren’t specific enough. Sorry 'bout that. Your hardware configuration still isn’t clear to me.
So… is your driver going to talk directly to the SMBus CONTROLLER? In other words, you’re going to build messages to your device and program the SMBus CONTROLLER to send those messages??
And the SMBus CONTROLLER, in the BIOS, is programmed to use an ordinary IRQ (and not an SMI or whatever)?
So, don’t you simply want to write a driver for the SMBus CONTROLLER… and have its PnP resources assigned to you?
Yes, my driver talks directly to the SMBus controller on the Intel chipset. My driver builds the messages and directly programs the SMBus controller.
Since nobody else will ever use the SMBus there is no SMBus bus driver. From what I could find Microsoft has never provided a generic SMBus bus driver for Windows-XP (like Microsoft does for other buses). Writing a standalone device driver that controls the SMBus seemed like the quickest and easiest approach.
The IRQ (shared PCI, level triggered) connects directly to the device, not the SMBus controller. Neither the BIOS nor any other code programs the SMBus controller to generate any type of interrupt. Since this is the only device on the SMBus there is no worry about collisions with other SMBus devices. The device in question is a (custom) user-interface whose inputs are completely asynchronous. That’s why it was designed to share an IRQ.
As far as I can tell Windows-XP does not provide generic PnP services to the SMBus. I would have to write a bus driver to provide PnP, and then I would have to write a device driver for my device to work with that bus driver. Since this is a custom, locked-down, platform which will never have another device on the SMBus this seemed like the long way around.
Well, they HAVE… but in fairness it never WORKED. And it was removed from the WDK as of Vista.
This is a platform of your design? Because the SMBUS is usually used to route things like POST codes and even Serial Presence Detect / Timing info.
But that doesn’t matter in any case.
AH, OK… things are a BIT more clear now. You’re talking to your DEVICE over the SMBus… and you’re using the SMBus ports for that (presumably, you’re claiming these resources properly??)… but your actual DEVICE is the one that’s generating the IRQ.
So, you know when to do a (for example) READ from your device (via the SMBus) when your device generates an interrupt. Or something like that. I don’t really care about the details, I just want to make sure I basically understand your hardware config.
And you don’t control the BIOS for this system?
Correct. Never has, never will.
Hmmmm… Given what you’ve just said, I *suspect* that you will *not* be able to specify an interrupt in your INF file and get that to work. This DOES work in WDM, you say?? REALLY?
Your other option would be to inject the IRQ as part of Filter Resource Requirements…