Latched interrupts and InterruptActiveHigh (was: Mixed Legacy/PnP resources)

Doron,

We implemented this, and it almost works flawlessly. The issue is that this
is a legacy Edge-Triggered (Latched) interrupt line, but the Framework (or
maybe the kernel) appears to be triggering on the trailing edge of the
pulse. You might ask "so what, how long is the pulse, anyway?" Well, it
turns out that it appears to really be a level-high triggered interrupt
(WdfInterruptActiveHigh / InterruptActiveHigh), even though we've specified
that it's latched, so we're not getting the proper behavior. If we specify
Latched, we don't get an ISR, and if we specify LevelSensitive, we get an
ISR storm when we aren't interrupting. Seems like we might be able to
resolve it if we could set the Polarity to InterruptActiveHigh, we might be
able to make it work, but that appears to be a read-only property available
only through WdfInterruptGetInfo().

Here's the relevant snippet:

#define PRIMARY_VECTOR (14)
IO_RESOURCE_DESCRIPTOR descriptor;
RtlZeroMemory(&descriptor, sizeof(descriptor));
descriptor.Option = 0;
descriptor.Type = CmResourceTypeInterrupt;
descriptor.ShareDisposition = CmResourceShareDeviceExclusive;
descriptor.Flags = CM_RESOURCE_INTERRUPT_LATCHED;
descriptor.u.Interrupt.MinimumVector = PRIMARY_VECTOR;
descriptor.u.Interrupt.MaximumVector = PRIMARY_VECTOR;
descriptor.u.Interrupt.AffinityPolicy = IrqPolicyMachineDefault;
descriptor.u.Interrupt.PriorityPolicy = IrqPriorityNormal;
descriptor.u.Interrupt.TargetedProcessors = KeQueryActiveProcessors();
status = WdfIoResourceListAppendDescriptor(pciIdeConfig, &descriptor);

(I think) We've tried all the possible combinations of Shared/Exclusive and
Level/Latched, and nothing has worked. Any suggestions for places to look
for places we've made a mistake in setting stuff up?

Thanks,

Phil

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

"Doron Holan" wrote in message
news:xxxxx@ntdev...
You can use EvtDeviceFilterAddResourceRequirements to add resources to
the resource requirements list(s). If you add resources, you will need
to remove them in EvtDeviceRemoveAddedResources so that PCI.sys does not
see them and get confused by the extra resources it did not assign to
you. You do not want to use IoReportResourceForDection, bad mojo in a
pnp driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D. Barila
Sent: Monday, June 04, 2007 3:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Mixed Legacy/PnP resources (was: Is it possible to
assign multiple interrupts to the same WDFDEVICE?)

OK, we did that, and it worked, in as much as we got the IO addresses
and
the interrupts that we forced in the inf in the resource list passed
into
EvtDevicePrepareHardware. The trouble we're seeing now is that the BAR
for
the Bus Master registers, which is programmed by the OS before the call,

isn't part of that resource list.

So the generic question is, how can I handle mixed PnP/Lgacy resources
without stepping outside of the KMDF model? If I were to dive into WDM,
I'd
just allow the OS to pass me the single BAR for the BM registers, then
claim
the IO ranges using IoReportResourceForDetection, and attach to the
interrupts using IoConnectInterrupt for vectors 14 and 15.

Is there a way to approximate the same process in KMDF? Is it a valid
pattern for a driver that isn't technically a bus driver (we don't
expose
any child devices to the OS, each HBA is one monolithic dev to the OS)
to
use the EvtDeviceResourceYYY routines to accomplish this? Is there a
callback that has the existing resources (the BM BAR) to which I can add
the
additional legacy IO ranges and interrupts that I'm currently specifying
in
the inf?

Thanks,

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

"Doron Holan" wrote in message
news:xxxxx@ntdev...
You create a WDFINTERRUPT per hw interrupt you will be assigned. On the
start device irp processing (before EvtDevicePrepareHardware is called),
KMDF walks the list of assigned resources (the cm resource list) and
pairs up each created WDFINTERRUPT to a hw interrupt in the list. This
will automatically assign vector, etc based on the assigned resources.
KMDF doesn't care how the hw resources were assigned, if you forced them
through an INF, so be it.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Monday, May 14, 2007 12:33 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Is it possible to assign multiple interrupts to the
same WDFDEVICE?

We're doing a test/diag driver for legacy PCI-IDE hardware, which uses
the well known legacy IDE IO ranges and interrupts. Those of you
familiar with those animals know that they use IRQ 14 for the primary
IDE channel, and IRQ 15 for the secondary, even though they are one PCI
function.

I see that the WdfInterruptCreate() doc says that I should call it twice
for this hardware, I'm not sure I understand how that's going to get
hooked up to the interrupts I want, since I can't actually indicate
which interrupt vectors I want to grab. Is this the part that the PnP
manager just does automagically because I've put the required resources
in the INF?

Thanks,

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

---
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
ListServer/Forum

You can’t specify the interrupt polarity, and I doubt that is your problem. Interrupt polarity is normally (always?) hardwired in the PC. For legacy/ISA devices it is raising edge active. I don’t know why KMDF has such a polarity member, but I guess it is there just in case it might be needed in the future. You can see that the HAL and Pnp Manager don’t seem to have a concept of interrupt polarity.

Your description sounds as the card is not generating interrupts, or that at least they are not seen by the CPU(s) for some reason. It may be a Bios problem? The interrupt storm you see is just an artifact of configuring the interrupt controller in level sensitive mode (active low). The non-active state for a legacy hardware is low, which would be seen as active in level mode.

Is that a device integrated in the motherboard? Otherwise, how the legacy interrupt lines are connected to the interrupt controller?

The polarity can be specified (whether it is configurable, I don’t know)
for a message based interrupt according to the WDK (see the doc pages
for IO_INTERRUPT_MESSAGE_INFO, IO_CONNECT_INTERRUPT_PARAMETERS
(MessageBased), and IoConnectInterruptEx).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rahul.net
Sent: Tuesday, June 19, 2007 7:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Latched interrupts and InterruptActiveHigh (was:
Mixed Legacy/PnP resources)

You can’t specify the interrupt polarity, and I doubt that is your
problem. Interrupt polarity is normally (always?) hardwired in the PC.
For legacy/ISA devices it is raising edge active. I don’t know why KMDF
has such a polarity member, but I guess it is there just in case it
might be needed in the future. You can see that the HAL and Pnp Manager
don’t seem to have a concept of interrupt polarity.

Your description sounds as the card is not generating interrupts, or
that at least they are not seen by the CPU(s) for some reason. It may be
a Bios problem? The interrupt storm you see is just an artifact of
configuring the interrupt controller in level sensitive mode (active
low). The non-active state for a legacy hardware is low, which would be
seen as active in level mode.

Is that a device integrated in the motherboard? Otherwise, how the
legacy interrupt lines are connected to the interrupt controller?


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

More info: This is legacy ISA compatibility stuff, but our resources
claimed by adding them to the list show up in Device Manager as PCI. I
think that's the root of the problem. How can we indicate that we are
claiming ISA bus resources instead of PCI resources here? I could sort of
see how you might claim an ISA port address by specifying subtractive
decode, although that seems like the default, since the only flag in
evidence is actually CM_RESOURCE_PORT_POSITIVE_DECODE, and it certainly
doesn't apply to an interrupt, in any case.

In answer to Jorge, it's the onboard IDE adapter in the chipset. As they
have ever been since the first ones, it's still an ISA widget when in full
compatibility mode.

Thanks,

Phil

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

"Philip D. Barila" wrote in message
news:xxxxx@ntdev...
> Doron,
>
> We implemented this, and it almost works flawlessly. The issue is that
> this is a legacy Edge-Triggered (Latched) interrupt line, but the
> Framework (or maybe the kernel) appears to be triggering on the trailing
> edge of the pulse. You might ask "so what, how long is the pulse,
> anyway?" Well, it turns out that it appears to really be a level-high
> triggered interrupt (WdfInterruptActiveHigh / InterruptActiveHigh), even
> though we've specified that it's latched, so we're not getting the proper
> behavior. If we specify Latched, we don't get an ISR, and if we specify
> LevelSensitive, we get an ISR storm when we aren't interrupting. Seems
> like we might be able to resolve it if we could set the Polarity to
> InterruptActiveHigh, we might be able to make it work, but that appears to
> be a read-only property available only through WdfInterruptGetInfo().

You are right, this explains why it is implemented in KMDF. But the polarity type is a new concept in Vista for message based interrupts. It doesn’t exist (or at least is not exposed) in earlier OS versions. It surely doesn’t make sense to be configurable for ISA (or conventional PCI) *line based* interrupts.

Doron Holan wrote:

The polarity can be specified (whether it is configurable, I don’t know)
for a message based interrupt according to the WDK (see the doc pages
for IO_INTERRUPT_MESSAGE_INFO, IO_CONNECT_INTERRUPT_PARAMETERS
(MessageBased), and IoConnectInterruptEx).

Phil Barila wrote:

More info: This is legacy ISA compatibility stuff, but our resources
claimed by adding them to the list show up in Device Manager as PCI. I
think that’s the root of the problem.

My knowledge about PCI-IDE is mostly from the theory, so the following might not be 100% accurate in your case:

PCI-IDE controllers have two different operation modes. They can work in “compatiblity” or “native PCI” mode. Some support one mode only, others both. But never both at the same time.

When in compatibility mode, the controller behaves as a legacy ISA device. It decodes fixed I/O addreses and uses fixed legacy IRQ lines. It *ignores* the PCI BAR setting, and it doesn’t use PCI interrupts. PCI *configuration space* is still available.

When in native PCI mode, it behaves like a standard PCI device. I/O locations are decoded according to the BAR, interrupts are fully configurable and are (obviously) level sensitive.

If your device supports both modes, then it might be much easier to use PCI-native mode. You might need to configure the default mode with BIOS. Or in the worst case, your driver would need to enable PCI-native mode on the card. Then, forget about all the compatiblity/legacy stuff.

If your device doesn’t support PCI-native, then you have (from the point of view of the Pnp manager) two different devices. A PCI device, only for the purpose of accessing the configuration space, which might be required at the minimum for enabling the device. And a diffent, ISA/legacy device, with fixed I/O resources.

Note, if you can configure the BAR and access the card using the BAR I/O locations, then it means your device does support PCI-native mode. Further, it means it is working in PCI-native mode, and then the legacy IRQs are *disabled*.

**************************************************
HELLO! STEVE SPANO HAS A NEW EMAIL ADDRESS

IT IS NOW STEVE@FL-ENG.COM

THIS EMAIL ACCOUNT WILL TERMINATE ON 6/15/07
**************************************************

steven spano wrote:

*************************************
HELLO! STEVE SPANO HAS A NEW EMAIL ADDRESS

IT IS NOW xxxxx@FL-ENG.COM

THIS EMAIL ACCOUNT WILL TERMINATE ON 6/15/07
*************************************

THANKS, STEVE SPANO!

(Does anyone have Jesse Spano’s email address?)