Prev: PnP device recognition
Next: FileSystem: Non cached read.
From: Nicolas Aspert on 29 Apr 2008 08:24
Nicolas Aspert wrote:
> I am trying to debug a 1394 driver (source available here
> http://www-2.cs.cmu.edu/~iwan/1394/downloads/index.html).
> This driver is intended for cameras which are DCAM compliant. When
> performing an hibernation with a camera connected, a blue screen occurs
> at resume.
> I looked at the sample driver in the DDK (1394vdev) and it seems that
> the power.c has been simply copied from the sample driver.

After investigating a little more, it seems that the power management in
the 1394 samples from the ddk is not really cleanly done.
As I am not really into driver programming, any help about decent
samples would be appreciated.

I have looked here
http://www.intel.com/technology/usb/download/understanding_power_management_in_wdm.pdf

and the sample driver here
http://www.codeproject.com/KB/system/WDM_Driver_development.aspx

and they all have more elaborated processing of IRP_MN_SET_POWER

the pdf from Intel says:
"When any device receives a set system power irp, it should set its
device power to the
appropriate state (as specified in the device capabilities structure
saved in the device extension).
If this is not implemented (i.e., the driver simply passes the power irp
down the stack),
during system suspend, the device will receive the PnP
IRP_MN_REMOVE_DEVICE irp
followed by an IRP_MJ_UNLOAD. This means that the driver is actually
unloaded from the
system. On resume, the driver will be reloaded with the DRIVER_ENTRY
routine being
executed followed by the normal PnP irps that are dispatched during
enumeration (i.e.
IRP_MN_START_DEVICE, IRP_MN_QUERY_CAPABILITIES, etc.). If an application
has a
handle to the driver, that handle will be valid when the system resumes."

Is it really the case ? Apparently this is what the sample 1394 driver
from the ddk does, but is it the correct approach ?

regards
Nicolas
From: Eliyas Yakub [MSFT] on 7 May 2008 13:56
Write your driver in KMDF. You don't have worry all these pnp/power
management issues. The 1394 sample is already rewritten in KMDF
(src\kmdf\1394).

-Eliyas

"Nicolas Aspert" <elhefe(a)noemail.noemail> wrote in message
news:#Fv3tPfqIHA.1240(a)TK2MSFTNGP02.phx.gbl...
> Nicolas Aspert wrote:
>> I am trying to debug a 1394 driver (source available here
>> http://www-2.cs.cmu.edu/~iwan/1394/downloads/index.html).
>> This driver is intended for cameras which are DCAM compliant. When
>> performing an hibernation with a camera connected, a blue screen occurs
>> at resume.
>> I looked at the sample driver in the DDK (1394vdev) and it seems that the
>> power.c has been simply copied from the sample driver.
>
> After investigating a little more, it seems that the power management in
> the 1394 samples from the ddk is not really cleanly done.
> As I am not really into driver programming, any help about decent samples
> would be appreciated.
>
> I have looked here
> http://www.intel.com/technology/usb/download/understanding_power_management_in_wdm.pdf
> and the sample driver here
> http://www.codeproject.com/KB/system/WDM_Driver_development.aspx
>
> and they all have more elaborated processing of IRP_MN_SET_POWER
>
> the pdf from Intel says:
> "When any device receives a set system power irp, it should set its device
> power to the
> appropriate state (as specified in the device capabilities structure saved
> in the device extension).
> If this is not implemented (i.e., the driver simply passes the power irp
> down the stack),
> during system suspend, the device will receive the PnP
> IRP_MN_REMOVE_DEVICE irp
> followed by an IRP_MJ_UNLOAD. This means that the driver is actually
> unloaded from the
> system. On resume, the driver will be reloaded with the DRIVER_ENTRY
> routine being
> executed followed by the normal PnP irps that are dispatched during
> enumeration (i.e.
> IRP_MN_START_DEVICE, IRP_MN_QUERY_CAPABILITIES, etc.). If an application
> has a
> handle to the driver, that handle will be valid when the system resumes."
>
> Is it really the case ? Apparently this is what the sample 1394 driver
> from the ddk does, but is it the correct approach ?
>
> regards
> Nicolas

From: Nicolas Aspert on 13 May 2008 10:49
Eliyas Yakub [MSFT] wrote:
> Write your driver in KMDF. You don't have worry all these pnp/power
> management issues. The 1394 sample is already rewritten in KMDF
> (src\kmdf\1394).
>

You mean power management is _that_ broken in wdm ? ;)
If you diff the driver against the wdm sample, you can see there the
amount of undocumented stuff is not negligible, so I was still hoping to
fix the existing code...
 | 
Pages: 1
Prev: PnP device recognition
Next: FileSystem: Non cached read.