KMDF on PCI device with legacy ISA resources?

NTDEV
1

Our lab test driver controls the primary IDE channel, the secondary IDE
channel and the Bus master function for both channels. For full PCI Native
mode, it all works fine.

  • PCI IDE controllers program BAR0, BAR1, BAR2 and BAR3 to 01, which Windows
    ignores and doesn’t provide in the resource list to
    EvtDevicePrepareHardware.
  • PCI IDE controllers use ISA IRQ 14 and IRQ15.
  • PCI IDE controllers program BAR4 with the Bus master I/O address.
  • PCI IDE controller is a single device that is enumerated by the PCI bus
    driver.
    The default behavior in this case is to provide only the single BAR4 I/O
    range to EvtDevicePrepareHardware, no other I/O ranges and no interrupts.
    In this case, we use legacy I/O addresses 0x01F0 - 0x01F7, 0x03F6, 0x0170 -
    0x0177, 0x0376, the Bus master I/O address range from BAR4 in the resource
    list handed to our EvtDevicePrepareHardware() routine, and the ISA
    interrupts 14 & 15.
    – Options tried that don’t work::
  • If we specify a LogConfigOverride section in our inf we get I/O address
    0x01F0 - 0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and interrupt 14 - 15
    resources. However we don’t get the Bus master I/O resource from BAR4. We
    did not specify anything for BAR 4 in the inf. Should we have?
  • If we use no LogConfigOverride section and instead use the
    EvtDeviceFilterAddResourceRequirements() and EvtDeviceRemoveAddedResources()
    functions to add the missing I/O and interrupt resources we get the proper
    resource list. However the interrupts are allocated as PCI interrupts
    instead of ISA interrupts. Therefore the polarity is incorrect causing the
    hardware not to trigger properly when the IRQ signal is asserted.
    – Options yet to try.
  • Write a bus driver that sits on top of the PCI bus driver, enumerates our
    single device and uses the EvtDeviceResourcesQuery() and/or the
    EvtDeviceResourceRequirementsQuery() to add the I/O addresses 0x01F0 -
    0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and interrupt 14 - 15 resources to
    the Bus master BAR4 I/O resource allocated by the PCI bus driver. Or will
    our bus driver need to allocate the BAR4 I/O address as well?
  • Specify a LogConfigOverride section in our inf to get I/O address 0x01F0 -
    0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and ISA interrupt 14 - 15 resources.
    Use the EvtDeviceFilterAddResourceRequirements() and
    EvtDeviceRemoveAddedResources() functions to add the BAR4 Bus master I/O
    resource. Somehow this approach seems a bit backward.

Is there anything else we should be looking at? I’m pretty sure that this
use case is covered by KMDF, but so far, we haven’t discovered how to make
it work.

Thanks,

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

2

Has this ever worked in a WDM driver (as a baseline comparison against
WDF)? KMDF does nothing other then abstract resource list management,
we don’t do anything special vs a WDM driver in terms of extra
functionality. Writing a bus driver to assign the resources to a PDO
won’t work, the resource arbitration interfaces are not public and you
need them to move assigned hw resources around in a pnp device tree.
What is so backward about the last option you listed? That you are
doing both an INF and driver override?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D. Barila
Sent: Wednesday, June 27, 2007 12:01 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF on PCI device with legacy ISA resources?

Our lab test driver controls the primary IDE channel, the secondary IDE
channel and the Bus master function for both channels. For full PCI
Native
mode, it all works fine.

  • PCI IDE controllers program BAR0, BAR1, BAR2 and BAR3 to 01, which
    Windows
    ignores and doesn’t provide in the resource list to
    EvtDevicePrepareHardware.
  • PCI IDE controllers use ISA IRQ 14 and IRQ15.
  • PCI IDE controllers program BAR4 with the Bus master I/O address.
  • PCI IDE controller is a single device that is enumerated by the PCI
    bus
    driver.
    The default behavior in this case is to provide only the single BAR4 I/O

range to EvtDevicePrepareHardware, no other I/O ranges and no
interrupts.
In this case, we use legacy I/O addresses 0x01F0 - 0x01F7, 0x03F6,
0x0170 -
0x0177, 0x0376, the Bus master I/O address range from BAR4 in the
resource
list handed to our EvtDevicePrepareHardware() routine, and the ISA
interrupts 14 & 15.
– Options tried that don’t work::

  • If we specify a LogConfigOverride section in our inf we get I/O
    address
    0x01F0 - 0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and interrupt 14 - 15
    resources. However we don’t get the Bus master I/O resource from BAR4.
    We
    did not specify anything for BAR 4 in the inf. Should we have?
  • If we use no LogConfigOverride section and instead use the
    EvtDeviceFilterAddResourceRequirements() and
    EvtDeviceRemoveAddedResources()
    functions to add the missing I/O and interrupt resources we get the
    proper
    resource list. However the interrupts are allocated as PCI interrupts
    instead of ISA interrupts. Therefore the polarity is incorrect causing
    the
    hardware not to trigger properly when the IRQ signal is asserted.
    – Options yet to try.
  • Write a bus driver that sits on top of the PCI bus driver, enumerates
    our
    single device and uses the EvtDeviceResourcesQuery() and/or the
    EvtDeviceResourceRequirementsQuery() to add the I/O addresses 0x01F0 -
    0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and interrupt 14 - 15 resources
    to
    the Bus master BAR4 I/O resource allocated by the PCI bus driver. Or
    will
    our bus driver need to allocate the BAR4 I/O address as well?
  • Specify a LogConfigOverride section in our inf to get I/O address
    0x01F0 -
    0x01F7, 0x03F6, 0x0170 - 0x0177, 0x0376 and ISA interrupt 14 - 15
    resources.
    Use the EvtDeviceFilterAddResourceRequirements() and
    EvtDeviceRemoveAddedResources() functions to add the BAR4 Bus master I/O

resource. Somehow this approach seems a bit backward.

Is there anything else we should be looking at? I’m pretty sure that
this
use case is covered by KMDF, but so far, we haven’t discovered how to
make
it work.

Thanks,

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

“Doron Holan” wrote in message
news:xxxxx@ntdev…
> Has this ever worked in a WDM driver (as a baseline comparison against
> WDF)?

Atapi.sys ring a bell? The apparent difference being that Atapi.sys is a
port driver, a bus driver of some kind, and it also seems to have a private
functional interface with PCIIDEX, though I’m not 100% sure of that.

> KMDF does nothing other then abstract resource list management,
> we don’t do anything special vs a WDM driver in terms of extra
> functionality. Writing a bus driver to assign the resources to a PDO
> won’t work, the resource arbitration interfaces are not public and you
> need them to move assigned hw resources around in a pnp device tree.
> What is so backward about the last option you listed? That you are
> doing both an INF and driver override?

Seems kind of goofy to ask PCI to read the BAR for me to get a value that
PCI put there, and would happily give me, except for the fact that I
provided a set of legacy resources in the inf. But if that’s what we need
to do, that’s what we need to do.

Thanks,

Phil
–
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

4

Phil Barila wrote:

“Doron Holan” wrote in message news:xxxxx@ntdev…
>> Has this ever worked in a WDM driver (as a baseline comparison against
>> WDF)?
>
> Atapi.sys ring a bell? The apparent difference being that Atapi.sys is a
> port driver, a bus driver of some kind, and it also seems to have a private
> functional interface with PCIIDEX, though I’m not 100% sure of that.

It is possible that you would need to replicate the atapi-pciide(x) model:

One device stack for getting the PCI pnp resources (the bus master interface, in your case). And other device stack for getting the legacy resources. I suspect you can’t add a legacy IRQ to a device with PCI.SYS as the PDO.

If you check how resources are handled in the in-box drivers, you’ll see they are indeed like that. The PCI BAR is allocated to the pciide device stack, and the legacy resources are allocated for devices enumerated by atapi. In turn atapi.sys is a bus driver, connecting both stacks.