KMDF Bus and function driver design question

I have a situation where I am designing a set of drivers for a board
with multiple functions but a single interrupt. The challenge here is
that the dozen devices on the board are either UART’s or devices whose
handling characteristics are similar to a UART (i.e. you want to process
the data at interrupt time).

Now I have done this with WDM a number of times, but would now like to
do this in KMDF, especially since the UART’s are 16550 clones. My
challenge here is to provide an interrupt handling method that will work
in this environment while requiring as few changes as possible for the
serial sample, and to make the other KMDF function drivers of the suite
have as few exceptions from the norm as possible.

I’m wondering how others have dealt with this type of design?

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can simply iterate through them and call out to their "ISR"s.

Except that calling a KMDF ISR in the FDO is not valid. Once I roll my
own I wonder how many other things start having to change because I am
no longer using an ISR but am having an ISR like routine running at
DIRQL. If I could use a stock KMDF interrupt model I would, but I am
sure the framework will be upset that there is not an interrupt in the
devices resources.

The folks I am doing the work for are going to need to maintain it, and
having things as standard as possible is highly desirable.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@broadcom.com” wrote in message
news:xxxxx@ntdev:

> I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can simply iterate through them and call out to their "ISR"s.

You’re using the term “functions” here as in “Bus X, Slot Y, Function Z”, right? As in “multi-function device”, not in “a single interrupt but multiple things that it needs to do functionally”? Sorry, but I want to be sure I’m answering the correct question.

Each FUNCTION has its own discrete set of registers, but all the FUNCTIONS share the same interrupt… is that correct?

Because if that’s the case, all you need to do is write function drivers that share interrupts like they would with any other device, right??

Peter
OSR

My understanding was that Mr. Burn is talking about single PCI function multiport chip. To allow reuse of existing UART code, he needs to simulate individual interrupts from each port, while essentially having a single vector and its ISR. And this needs to fit to KMDF model also.

So you step outside the KMDF model and use a callback interface, exported
via a BUS_INTERFACE of your own design, for running child isrs. Those child
isrs queue dpcs as needed to get back into a kmdf context. It looks to me
like WdfDpcEnqueue only requires access to a WDFDPC object, and does not
need to be called from within a framework callback context, although having
never done this I am just guessing. I have no idea what actually happens if
one uses WdfDpcWdmGetDpc to get the KDPC and then call KeInstertQueurDpc,
but one hopes that the result is that your EvtDpcFunc gets invoked. So that
looks like two ways to get from outside WDF to back into it at DPC level
after processing your interrupts.

Mark Roddy

On Fri, Apr 22, 2011 at 3:19 PM, Don Burn wrote:

> Except that calling a KMDF ISR in the FDO is not valid. Once I roll my own
> I wonder how many other things start having to change because I am no longer
> using an ISR but am having an ISR like routine running at DIRQL. If I
> could use a stock KMDF interrupt model I would, but I am sure the framework
> will be upset that there is not an interrupt in the devices resources.
>
> The folks I am doing the work for are going to need to maintain it, and
> having things as standard as possible is highly desirable.
>
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “xxxxx@broadcom.com” wrote in message
> news:xxxxx@ntdev:
>
>
> I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can
>> simply iterate through them and call out to their "ISR"s.
>>
>
>
> —
> 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
>

You can call WdfDpcEnqueueDpc from any context that you want as long as the caller is the one who allocated the WDFDPC (ie you are not sharing KMDF objects between drivers)

d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Friday, April 22, 2011 2:32 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] KMDF Bus and function driver design question

So you step outside the KMDF model and use a callback interface, exported via a BUS_INTERFACE of your own design, for running child isrs. Those child isrs queue dpcs as needed to get back into a kmdf context. It looks to me like WdfDpcEnqueue only requires access to a WDFDPC object, and does not need to be called from within a framework callback context, although having never done this I am just guessing. I have no idea what actually happens if one uses WdfDpcWdmGetDpc to get the KDPC and then call KeInstertQueurDpc, but one hopes that the result is that your EvtDpcFunc gets invoked. So that looks like two ways to get from outside WDF to back into it at DPC level after processing your interrupts.

Mark Roddy

On Fri, Apr 22, 2011 at 3:19 PM, Don Burn > wrote:
Except that calling a KMDF ISR in the FDO is not valid. Once I roll my own I wonder how many other things start having to change because I am no longer using an ISR but am having an ISR like routine running at DIRQL. If I could use a stock KMDF interrupt model I would, but I am sure the framework will be upset that there is not an interrupt in the devices resources.

The folks I am doing the work for are going to need to maintain it, and having things as standard as possible is highly desirable.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@broadcom.commailto:xxxxx” > wrote in message news:xxxxx@ntdev:

I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can simply iterate through them and call out to their "ISR"s.


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

— 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</mailto:xxxxx>

Since the overhead of the DPC is a couple orders of magnitude greater
than the work needed to be done at interrupt time I wanted to avoid the
technique. The device has a single interrupt control register and a
single interrupt status register for all twelve devices.

I am looking to balance the performance with the goal of keeping things
simple and as close to the original serial sample as possible.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Doron Holan” wrote in message
news:xxxxx@ntdev:

> You can call WdfDpcEnqueueDpc from any context that you want as long as the caller is the one who allocated the WDFDPC (ie you are not sharing KMDF objects between drivers)
>
> d
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
> Sent: Friday, April 22, 2011 2:32 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] KMDF Bus and function driver design question
>
> So you step outside the KMDF model and use a callback interface, exported via a BUS_INTERFACE of your own design, for running child isrs. Those child isrs queue dpcs as needed to get back into a kmdf context. It looks to me like WdfDpcEnqueue only requires access to a WDFDPC object, and does not need to be called from within a framework callback context, although having never done this I am just guessing. I have no idea what actually happens if one uses WdfDpcWdmGetDpc to get the KDPC and then call KeInstertQueurDpc, but one hopes that the result is that your EvtDpcFunc gets invoked. So that looks like two ways to get from outside WDF to back into it at DPC level after processing your interrupts.
>
>
> Mark Roddy
>
> On Fri, Apr 22, 2011 at 3:19 PM, Don Burn > wrote:
> Except that calling a KMDF ISR in the FDO is not valid. Once I roll my own I wonder how many other things start having to change because I am no longer using an ISR but am having an ISR like routine running at DIRQL. If I could use a stock KMDF interrupt model I would, but I am sure the framework will be upset that there is not an interrupt in the devices resources.
>
> The folks I am doing the work for are going to need to maintain it, and having things as standard as possible is highly desirable.
>
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> “xxxxx@broadcom.commailto:xxxxx” > wrote in message news:xxxxx@ntdev:
>
> I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can simply iterate through them and call out to their "ISR"s.
>
>
> —
> 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
>
> — 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</mailto:xxxxx>

Right, but you still have to push data back to applications at dpc level. So
you do you work in your child isr routines invoked directly from the bus
driver’s isr, they queue dpcs as needed to complete requests. Looks to me
like there is very little WDF dependency in SerialISR and it could be
readily converted to have none.

Mark Roddy

On Fri, Apr 22, 2011 at 6:04 PM, Don Burn wrote:

> Since the overhead of the DPC is a couple orders of magnitude greater than
> the work needed to be done at interrupt time I wanted to avoid the
> technique. The device has a single interrupt control register and a single
> interrupt status register for all twelve devices.
>
> I am looking to balance the performance with the goal of keeping things
> simple and as close to the original serial sample as possible.
>
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev:
>
> You can call WdfDpcEnqueueDpc from any context that you want as long as
>> the caller is the one who allocated the WDFDPC (ie you are not sharing KMDF
>> objects between drivers)
>>
>> d
>> From: xxxxx@lists.osr.com [mailto:
>> xxxxx@lists.osr.com] On Behalf Of Mark Roddy
>> Sent: Friday, April 22, 2011 2:32 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] KMDF Bus and function driver design question
>>
>> So you step outside the KMDF model and use a callback interface, exported
>> via a BUS_INTERFACE of your own design, for running child isrs. Those child
>> isrs queue dpcs as needed to get back into a kmdf context. It looks to me
>> like WdfDpcEnqueue only requires access to a WDFDPC object, and does not
>> need to be called from within a framework callback context, although having
>> never done this I am just guessing. I have no idea what actually happens if
>> one uses WdfDpcWdmGetDpc to get the KDPC and then call KeInstertQueurDpc,
>> but one hopes that the result is that your EvtDpcFunc gets invoked. So that
>> looks like two ways to get from outside WDF to back into it at DPC level
>> after processing your interrupts.
>>
>>
>> Mark Roddy
>>
>> On Fri, Apr 22, 2011 at 3:19 PM, Don Burn >> xxxxx@acm.org>> wrote:
>> Except that calling a KMDF ISR in the FDO is not valid. Once I roll my own
>> I wonder how many other things start having to change because I am no longer
>> using an ISR but am having an ISR like routine running at DIRQL. If I
>> could use a stock KMDF interrupt model I would, but I am sure the framework
>> will be upset that there is not an interrupt in the devices resources.
>>
>> The folks I am doing the work for are going to need to maintain it, and
>> having things as standard as possible is highly desirable.
>>
>>
>>
>> Don Burn (MVP, Windows DKD)
>> Windows Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>>
>>
>>
>> “xxxxx@broadcom.commailto:xxxxx” >> mailto:xxxxx> wrote in message news:xxxxx@ntdev:
>>
>>
>> I suppose you’ll have raw PDOs per UART’s instance. Your “main” ISR can
>> simply iterate through them and call out to their "ISR"s.
>>
>>
>> —
>> 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
>>
>> — 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
>>
>
>
> —
> 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
></mailto:xxxxx></mailto:xxxxx>