[HKEY_LOCAL_MACHINE\Drivers]
"RootKey"="Drivers\BuiltIn"

[HKEY_LOCAL_MACHINE\Drivers\Builtin]

Important: Device Manager makes the Root Bus Driver run TWICE in a system with a two-phase boot.

• do bus address translation between a subordinate Bus and a Parent Bus
  
• do Device Power State changes
  
• access Configuration Data

busname _bus#_device#_function#

1. Root Bus Driver: "BuiltIn"
   
2. PCI Bus Driver: "PCI"
   
3. PC Card Bus Driver: "PCCARD"

• IOCTL_POWER_CAPABILITIES -- The Power Manager uses this IO Control Code to query a driver's supported device power states. After a driver returns from this call with the Device Power States that it supports (D0->D4), and IOCTL_POWER_SET commands (see below) that specify a supported Device Power State should succeed. If the device does not accept the command to change power state, the PM will consider the refusal as a severe error.
  
  
• IOCTL_POWER_QUERY -- (Optional) This function simply returns a driver's current power state.
  
  
• IOCTL_POWER_SET -- The Power Manager uses this IO Control Code to change the driver's power state. Power Manager only specifies valid power states reported by a driver from IOCTL_POWER_CAPABILITIES.

1. A Client Driver need to know the current power state in order to perform its function correctly. For example, the Client Driver has to make sure there is no ongoing processing on the hardware or a blocking future function request (if requests are queued) before calling the Bus Driver to turn off the hardware.
   
   
2. Driver before Windows CE 5.0 performed Power Control by itself. To make processing backwards compatible, the Power Manager needs to continue to call the Client Driver directly.

1. PM calls DeviceIoControl (IOCTL_POWER_SET) on the client Driver.
   
   
2. The Client Driver calls the SetDevicePowerState() CEDDK function which translates IOCTL_BUS_SET_POWER_STATE to the bus driver.
   
   
3. The Bus driver determines what to do base on the call from the client driver.

Init()
{
hPwrHandle = DDKPwr_Initialize(__in PFN_SETPOWERLEVEL pSetPowerLevelFn,
__in DWORD dwContext,
__in BOOL fAbortOnPMRequests,
__in DWORD dwTimeout );
};

Deinit
{
DDKPwr_Deinitialize(hPwrHandle);
}

Function_Request()
{
       HANDLE hLevelHandle = DDKPwr_RequestLevel(hPwrHandle,
__in CEDEVICE_POWER_STATE dx );
       ¦ // Do some work.
       DDKPwr_ReleaseLevel(hPwrHandle, hLevelHandle);
}

PowerMgr_Request(Dx)
{       // From Power IO Control
DDKPwr_SetDeviceLevel(hPwrHandle ,Dx , __in PFN_SETPOWERLEVELCALLBACK pCallbackFn );
}

Class DefaultBusDriver {

Public:
      // Constructor
      // Client Driver Specific function.
      // Bus Driver Function.

Protected:
      // Container for all Folders of Child Client Driver.
      // Child Folder Class Manufacture. };

class DeviceFolder {

public:
      // Constructor
      // Device Power Function
      // Device Configuration Function
      // Device Bus Address Translation Function
      // Device Driver Load and Unload Function.
}; 

• Forwards device-specific requests to a folder
  
• Manages DeviceFolder containers
  
• Performs Default Bus Translations for the IOCTL_BUS_TRANSLATE_SYSTEM_ADDRESS and IOCTL_BUS_TRANSLATE_BUS_ADDRESS IO Control Codes. It calls its parent bus driver to translate addresses or calls HalTranslateBusAddress or HalTranslateSystemAddress if it is a Root Bus Driver.
  
• Handles the basic IOCTL_BUS_IS_CHILD_REMOVED, IOCTL_BUS_NAME_PREFIX and other IO Control codes.
  
• Has a dummy function for PostInit(), which is called by IOCTL_BUS_POSTINIT

• Includes logic for creating a default bus name for use in driver loading and unloading.
  
• Perform Default Configuration Functions forwarded by the DefaultBusDriver class through IOCTL_BUS_GET_CONFIGURE_DATA and IOCTL_BUS_SET_CONFIGURE_DATA. It calls HalGetBusDataByOffset or HalSetBusDataByOffset when a request is from PCI Client Device Driver.
  
• Has a dummy function for SetPowerState which is called by the DefaultBusDriver through IOCTL_BUS_SET_POWER_STATE. The provided implementation of the PCI Bus Driver shows a good example of how to do SetPowerState for specific hardware.

class PciDeviceFolder : public DeviceFolder{
    virtual BOOL PostInit() ;
...
};
class PciBusEnum : public  DefaultBusDriver {
...
};

• PciBusEnum -- Implements the PostInit() function to overwrite the dummy implementation in the parent class. This new implementation calls two sub functions:
  1. Calls AssignChildDriver() which creates one PciDeviceFolder for each Device Instance. This also inserts the folder into a Device Folder container.
     
  2. Calls ActivateAllChildDriver() which calls DeviceFolder::LoadDevice() to load each client driver in order.
  
  
• PciDeviceFolder -- Implements the SetPowerState() to overwrite the dummy implementation in the parent class. The new method implements its actions according to the PCI PM 1.1 specification.

class BusEnum : public  DefaultBusDriver {
virtual BOOL PostInit() ;
...
};

• BusEnum -- Implements the PostInit() function to overwrite the dummy implementation in the parent class. This new implementation calls two sub functions:
  • Calls AssignChildDriver() which creates one DeviceFolder for each Device Instance referenced by a sub registry key. It then inserts the folder into a Device Folder container.
    
  • Calls ActivateAllChildDriver() which calls DeviceFolder::LoadDevice() to load drivers in order.

• Understanding Windows CE 6.0's kernel mode
  
• Replacing a COREDLL component in Windows CE 6.0
  
• Understanding Windows CE "SDKs"
  
• Windows CE6 drivers: what you need to know
  
• Understanding Windows CE 6's device driver model
  
• Differences between Windows CE 5.0 and Windows CE 6.0
  
• Video introduces 3rd-generation Windows CE kernel
  
• Driver dev kit adds Windows CE 6, Windows Mobile 6
  
• Differences between Windows CE 6 and CE 5 device drivers