Plug and Play support for I2C

This article describes plug and play support for devices that support HID over the I²C transport.

Driver Loading

Windows loads the HID I²C class driver based on a compatible identifier match between a hardware identifier and the INF. The identifier is generated by the Advanced Configuration and Power Interface (ACPI). The hardware identifier is generated for the I²C device node in ACPI. All HID I²C compatible devices must expose the compatibility identifier, in addition to a unique hardware identifier.

The ACPI 5.0 Specification includes support for HID Class Devices. the ACPI definitions for HID I²C are as follows.

Every HID I²C device must provide the following mandatory fields:

• Compatible ID
• Hardware ID
• Hardware Revision
• Current Resource Settings
• Device Specific Method

Refer to the Advanced Configuration and Power Interface (ACPI) 5.0 specification for additional information.

The following provides an example of a hardware IDs and compatible IDs for a random HID I²C device. These details are based on a sample device that reports itself as a HID with one top-level collection of class "vendor specific".

Advanced Configuration and Power Interface (ACPI) generates the following Hardware IDs and Compatible IDs to load the HID I²C Transport driver:

Hardware Identifiers: Compatible Identifiers

ACPI\Vid_xxxx&Pid_yyyy&Rev_zzzz;: ACPI\PNP0C50

ACPI\Vid_xxxxPid_yyyy;:

ACPI\xxxxyyyy;:

In the previous example, the Hardware ID was generated by using the values extracted from the _HID ACPI method for the sample device. The Compatible ID is generated by using the values extracted from the _CID ACPI method for the sample device. The Compatible ID for a HID over I2C must always be PNP0C50 for version 1.0.

Note  If you supply an INF, you should only use the hardware identifiers in the left column of the previous table. (Do not use the compatible identifier in the right column.)

The Hardware ID for the HID Client device node generated by the HIDClass.sys component is as follows:

Hardware Identifier: Compatible Identifier

HID\VEN_MSFT&DEV_0010&REV_0002&Col01;: N/A

-HID\VEN_MSFT&DEV_0010&Col01 HID\MSFT0010&Col01;: N/A

-HID\*MSFT0010Col01: N/A

-HID_DEVICE_UP:FF00_U:0001;: N/A

-HID_DEVICE: N/A

The Hardware ID is generated by HIDClass.sys and is identical for all transports. This identifier is based on values passed to HIDClass.sys from HIDI2C.sys (extracted from ACPI).

Device enumeration sequence

Once a HID I²C device driver (HIDI2C.Sys ) is loaded, it starts to communicate with the device over the I²C bus. The first operation the driver performs is the device enumeration sequence.

The following list gives the enumeration sequence. Note that the order of this list may change in future versions of Windows.

1. Retrieve ACPI Source Language (ASL) code for HID I²C DEVICE from System BIOS.

2. Retrieve HID Descriptor from the Device.

   • Write HID Descriptor Address
   • Read HID Descriptor

3. Issue a SET_POWER to the Device.

   • Write SET_POWER Command

4. Issue a RESET (Host Initiated Reset) to the Device.

   • Write RESET Command
   • Device asserts GPIO interrupt
   • Read value (0x00 0x00) from input register

5. Retrieve report descriptor from the device.

   • Write report descriptor address
   • Read report descriptor

If the HOST fails to successfully complete any of steps 1-5 with the DEVICE, the HIDI²C driver may load with error value of Code 10. There is no retry logic built into any of these commands.

Note: Steps 4 and 5 may be done in parallel to optimize for time on I²C. Since report descriptors are (a) static and (b) quite long, Windows 8 may issue a request for 5 while it is waiting for a response from the device on 4.

Supported HID I²C commands

HIDI2C.SYS driver supports the following commands: