I suspect that your WDM driver would be tough to get running on this
particular platform. In fact, all of your frustrations so far have had
nothing to do with WDF, but rather general PnP resource management.
So let me lay out a few things for you:
-
In general, chipsets have “IRQ steering devices” within them that allow
the motherboard to route PCI interrupts to various interrupt controller
inputs. -
The BIOS controls the IRQ steering devices and either programs them
statically (Ethernet is attached to IRQ 19, for example) or it exposes “Link
nodes” in the ACPI namespace which are used for dynamically choosing the IRQ
at run time. -
If your SMBus device is wired into the IRQ Steering device, there’s no
way to tell Windows (through the ACPI spec) that its IRQ will change if the
OS reprograms the link node. Only PCI devices can express this connection.
This event will be rare and hard to test, though it can happen. (PnpDTest
will force it.) -
If your SMBus device is wired past the steering device and directly to
an interrupt controller input, that’s better and you can’t be screwed if the
OS decides to move some PCI devices to a different IRQ. -
In either case, you need to express your IRQ (which is sort of an
antiquated term with ambiguous meaning) in terms that your ACPI BIOS can
deal with, or Windows won’t connect your interrupt internally. You have
only two choices in ACPI. Your device is either PCI or it conforms to the
rules of the ISA bus. Your device is not PCI. -
The ISA bus had only IRQs 0 through 15. You say your device is
connected to IRQ 19 or maybe 21. This is impossible to directly express. -
ACPI allows that some ISA IRQs might be wired to I/O APIC inputs that
aren’t numbered the same way that ISA IRQs are numbered. For example, it’s
fairly common for ISA IRQ 0 to be wired to I/O APIC input 2. ACPI allows
these to be specified as “ISA Vector Overrides.” See Chapter 5. -
You can convince Windows that your non-PCI device can have “system IRQ
19” by modifying the BIOS to say that some (presumably unused) ISA IRQ
actually maps to I/O APIC input 19. Then you claim that ISA IRQ in your
driver. For instance, you might claim IRQ 5, where the BIOS says 5 maps to
- This entire design is kind of dumb, because it’s going to force you to
send SMBus commands in your ISR to get your device to deassert its
interrupt, and SMBus commands are generally slow while ISRs should generally
be very fast.
Good luck anyhow.
Jake Oshins
Hyper-V I/O Architect (former interrupt guy)
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
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.
