Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

KMDF Bus and function driver design question

Don_Burn_1Don_Burn_1 Member Posts: 4,311
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

Comments

  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    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" <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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    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
    >
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,428
    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.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

    --- 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
    d
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    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" <xxxxx@microsoft.com> 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.com<mailto:xxxxx@broadcom.com>" <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
    >
    > --- 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
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    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.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
    >>
    >> --- 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
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space