Relationship between AVStream minidriver's KSDEVICE_DISPATCH and WDM PnP dispatch

NTDEV
1

I’m studying AVStream minidriver development for USB device.
AVStream minidriver provides one KSDEVICE_DISPATCH table for PnP processing.
I think this maps to WDM PnP dispatch routine.
I have several questions about the relationship between KSDEVICE_DISPATCH
and
WDM PnP dispatch.

  1. Does minidriver’s dispatch need to call IoCallDriver to pass down PnP Irp
    just like
    WDM driver PnP dispatch does? Which driver is responsible for passing
    PnP Irp down?
  2. If AVStream class driver is responsible for passing down PnP Irp, will
    minidriver
    dispatch be called before or after PnP Irp is passed to next lower
    driver?
  3. USB WDM driver gets device/configuration descriptors and set config after
    PnP Start Irp retruns success status from lower driver.
    Should I do this in Start or PostStart dispatch of minidriver’s
    KSDEVICE_DISPATCH?

I wonder how many efforts need to do in minidriver dispatch for PnP.

Best Regards
Jack Huang

2

huangjj wrote:

I’m studying AVStream minidriver development for USB device.
AVStream minidriver provides one KSDEVICE_DISPATCH table for PnP processing.
I think this maps to WDM PnP dispatch routine.

Yes; in most cases, the translation is rather direct.

I have several questions about the relationship between KSDEVICE_DISPATCH
and WDM PnP dispatch.

  1. Does minidriver’s dispatch need to call IoCallDriver to pass down PnP Irp
    just like WDM driver PnP dispatch does? Which driver is responsible for passing
    PnP Irp down?

The AVStream wrapper (ks.sys) will take care of this. Your minidriver’s
dispatch routines just need to take whatever specific action your device
requires.

  1. If AVStream class driver is responsible for passing down PnP Irp, will
    minidriver dispatch be called before or after PnP Irp is passed to next lower
    driver?

Ks.sys will make sure the rules are followed. There are some IRPs where
a driver is supposed to handle it and then pass it down, and some where
a driver is supposed to pass it down and handle it on the way back.
Ks.sys will follow those rules.

  1. USB WDM driver gets device/configuration descriptors and set config after
    PnP Start Irp retruns success status from lower driver.
    Should I do this in Start or PostStart dispatch of minidriver’s
    KSDEVICE_DISPATCH?

I generally do it in PnpStart. More specifically, I have a separate
class that abstracts all of the USB stuff; I create that object in
PnpStart, and its constructor fetches the descriptors and sets the
configuration.

Really, it doesn’t much matter. All you need is access to the device,
and that’s available starting at PnpStart. You could even wait until a
filter was instantiated.

I wonder how many efforts need to do in minidriver dispatch for PnP.

Why? For a USB device, there’s just not that much to do. Most of it is
boilerplate, and ks.sys takes care of the boilerplate for you. My last
AVStream USB driver handles Create, Start, and Remove. That’s it.
Create is about half a dozen lines of code. My Start is complicated
because I have to modify the pin descriptors on the fly. Remove is one
line of code. The real work goes on in the filter and pin dispatches.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thanks for your help.
It helped me to understand PnP processing of AVStream more clear.

I have another questions about power management.
Does AVStream class also hanlde power management for minidriver?
Does USBCamd driver need to handle power management by itself?
or Stream class driver will handle power management for USBCamd driver?

Best Regards
Jack Huang

“Tim Roberts” …
> huangjj wrote:
>> I’m studying AVStream minidriver development for USB device.
>> AVStream minidriver provides one KSDEVICE_DISPATCH table for PnP
>> processing.
>> I think this maps to WDM PnP dispatch routine.
>>
>
> Yes; in most cases, the translation is rather direct.
>
>> I have several questions about the relationship between KSDEVICE_DISPATCH
>> and WDM PnP dispatch.
>>
>> 1. Does minidriver’s dispatch need to call IoCallDriver to pass down PnP
>> Irp
>> just like WDM driver PnP dispatch does? Which driver is responsible for
>> passing
>> PnP Irp down?
>>
>
> The AVStream wrapper (ks.sys) will take care of this. Your minidriver’s
> dispatch routines just need to take whatever specific action your device
> requires.
>
>> 2. If AVStream class driver is responsible for passing down PnP Irp, will
>> minidriver dispatch be called before or after PnP Irp is passed to next
>> lower
>> driver?
>>
>
> Ks.sys will make sure the rules are followed. There are some IRPs where
> a driver is supposed to handle it and then pass it down, and some where
> a driver is supposed to pass it down and handle it on the way back.
> Ks.sys will follow those rules.
>
>> 3. USB WDM driver gets device/configuration descriptors and set config
>> after
>> PnP Start Irp retruns success status from lower driver.
>> Should I do this in Start or PostStart dispatch of minidriver’s
>> KSDEVICE_DISPATCH?
>>
>
> I generally do it in PnpStart. More specifically, I have a separate
> class that abstracts all of the USB stuff; I create that object in
> PnpStart, and its constructor fetches the descriptors and sets the
> configuration.
>
> Really, it doesn’t much matter. All you need is access to the device,
> and that’s available starting at PnpStart. You could even wait until a
> filter was instantiated.
>
>> I wonder how many efforts need to do in minidriver dispatch for PnP.
>>
>
> Why? For a USB device, there’s just not that much to do. Most of it is
> boilerplate, and ks.sys takes care of the boilerplate for you. My last
> AVStream USB driver handles Create, Start, and Remove. That’s it.
> Create is about half a dozen lines of code. My Start is complicated
> because I have to modify the pin descriptors on the fly. Remove is one
> line of code. The real work goes on in the filter and pin dispatches.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

4

huangjj wrote:

Thanks for your help.
It helped me to understand PnP processing of AVStream more clear.

I have another questions about power management.
Does AVStream class also hanlde power management for minidriver?

Yes, as much as it can. Most AVStream drivers don’t need power
handlers. Have you looked at the samples and read the documentation?

Does USBCamd driver need to handle power management by itself?
or Stream class driver will handle power management for USBCamd driver?

Again, have you read the documentation and look at the sample? You
should be able to answer this question from them.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Sorry…I did read the sample code and document.
Do you mean AVStream and stream class driver handle power management Irp for
minidriver?
Yes, I didn’t find power management Irp handler in these minidrivers.

I try to find information about power management support of AVStream and
stream class in DDK document.
But I didn’t find much information.
In avshws sample code, set power dispatch is not set.
Doesn’t it need to change internal state while power state is changed?

Do AVStream and stream class also support selective suspend feature?
Could you tell me where I can find these information?

Best Regards
Jack Huang

“Tim Roberts” …
> huangjj wrote:
>> Thanks for your help.
>> It helped me to understand PnP processing of AVStream more clear.
>>
>> I have another questions about power management.
>> Does AVStream class also hanlde power management for minidriver?
>>
>
> Yes, as much as it can. Most AVStream drivers don’t need power
> handlers. Have you looked at the samples and read the documentation?
>
>> Does USBCamd driver need to handle power management by itself?
>> or Stream class driver will handle power management for USBCamd driver?
>>
>
> Again, have you read the documentation and look at the sample? You
> should be able to answer this question from them.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

6

huangjj wrote:

Sorry…I did read the sample code and document.
Do you mean AVStream and stream class driver handle power management Irp for
minidriver?

They handle the boilerplate stuff, which is what makes power management
so icky in WDM.

Yes, I didn’t find power management Irp handler in these minidrivers.

Of course, because those are simulations. There is no power to manage.

I try to find information about power management support of AVStream and
stream class in DDK document.
But I didn’t find much information.
In avshws sample code, set power dispatch is not set.
Doesn’t it need to change internal state while power state is changed?

No, because there is no real hardware. There’s no power to manage.

Do AVStream and stream class also support selective suspend feature?
Could you tell me where I can find these information?

Why? Selective suspend isn’t usually an issue for an AVStream device.
When a device isn’t streaming, it can be in a low-power state where it’s
just maintaining its parameters. When you start streaming, you can do
whatever you need to do to bring the power up. You don’t want to
suspend it while it is streaming.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.