Simple Peripheral Bus (SPB)

This topic covers recommendations for Simple Peripheral Bus in Windows 10.Windows includes support for low-power, simple buses, such as Inter Integrated Circuit (I²C) and (I²C) and Simple Peripheral Interface (SPI), using framework extensions of the Kernel Mode Driver Framework (KMDF) architecture. Controller drivers are not provided in-box. Chipset vendors, OEMs, or IHVs must develop a controller driver implemented in KMDF. The architecture provides flexible device configuration topologies supporting simultaneous use of buses for control and data transactions, as well as GPIO for signaling and interrupts. The complete device definition is defined through Advanced Configuration and Power Interface (ACPI).

In Windows, buses are supported through KMDF controller drivers. With the aid of the KMDF platform, the controller driver is used predominantly to define the hardware-specific interfaces necessary to enable controller function.

The Windows infrastructure supports devices that share buses, buses that are multiplexed on the same line, and device configuration through ACPI. Windows uses ACPI as the primary means for device identification, configuration, and control.

The following table summarizes the support for the Simple Peripheral Bus.

Design considerations for SPB

The following are some generic considerations for SPB:

• SPB is not a Plug and Play bus. Peripheral devices typically have fixed connections to an SPB and cannot be removed. System manufacturers must ensure accurate information in ACPI to enumerate the SPB-connected peripheral devices for the Plug and Play manager, and specifies the hardware resources that are dedicated to each device.

• There is no in-band interrupt support for SPB. Most peripherals support device signaling through a separate interrupt (often GPIO based) mechanism, and accurately mapped in ACPI.

• Windows provides support for the SPB Class Extension (spbcx.sys) in Windows 8 and beyond. SoC partners are responsible for developing and redistributing their appropriate SPB Controller driver.

• Peripheral drivers for SPB devices are generally provided by SPB Device partners. Microsoft provides one class driver for SPB devices for HID over I²C (hidi2c.sys).

• Device classes may provide HLK requirements or WEG guidance around the following topics related to I²C:

  • Sharing I²C controller with other devices
  • Preferred I²C signaling speed
  • Power management and wake scenarios over I²C and GPIO.

• Inter Integrated Circuit (I²C): I²C is the primary bus that is validated as part of SPB and is highly recommended on SoC systems.

  Microsoft provides Windows Hardware Compatibility Program requirements for I²C. Use the Windows Hardware Lab Kit (HLK) to test devices against those requirements.

• Simple Peripheral Interface (SPI): Support for SPI is optional and up to the SoC partner. The Windows Hardware Compatibility Program does not contain any requirements specific to SPI bus.

Support for SPB across systems

Microsoft supports SPB on Arm systems and x86/x64 platforms (running in S3 configurations). Microsoft supports SPB on platforms running in both Connected Standby (CS) and S3 configurations.

Please contact your platform provider for drivers and support.

There are a number of device scenarios that leverage SPB for connectivity. I²C is available on CS and S3 traditional power model. Modern SoCs with on-SoC sensor low power cores can implement non-I²C solutions as needed.

Devices on removable docks/ports should also follow the guidance around docking scenarios, also included in the WEG. Some of those devices may make more sense over buses like USB rather than I²C.

SPB framework extension

The SPB framework extension library extends the Windows Driver Framework to support SPB drivers. The SPB framework simplifies development of an SPB controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests (as compared to the "bottom-half", which is driven by the top-half and controls the hardware). The SPB Framework Extension is a KMDF extension library. It handles the up-front processing of SPB request and the sequence in which they are handed to the controller driver. The SPB framework extension is designed to support I²C and SPI buses, and may be appropriate for other buses with similar semantics.

Serial Framework extension

The serial framework extension library extends the Windows driver framework to support serial controller drivers. Similarly to the SPB framework, the serial framework simplifies development of a serial controller driver and improves the compatibility between peripheral drivers and the controller driver by providing common implementation of the "top-half" of the driver that processes I/O requests. The serial framework extension is a KMDF extension library. It handles the up-front processing of the calls to the serial APIs and the sequence in which they are handed to the controller driver. The serial framework extension is designed to support the modern UART controllers and simplify controller driver implementation and diagnosability.

I²C and UART HLK requirements

There are Hardware Compatibility Program requirements for I²C and UART controllers. Requirements for SPI are being considered for the future as well. The logo requirements are primarily intended for SoC silicon vendors for the bus interface hardware and the associated controller drivers. OEMs and ODMs are not required to revalidate the hardware or controller driver but are welcome to run the tests if desired. Special set-up steps are required to validate these requirements. The setup includes the following:

• An open system with accessible I²C /UART pins/ports
• Modifications in ACPI to expose the I²C/ UART test device to software
• A specific test device (WITT) attached to the system under validation

For additional set-up information, please refer to the Hardware Lab Kit (HLK) documentation.

Peripheral drivers

Peripherals are enumerated by ACPI and are generally static. Peripheral function drivers determine their appropriate bus resources by interacting with the framework extensions. Peripherals and controllers are not hierarchical, and peripherals may use several SPB, GPIO, Serial, and other high speed buses. Peripheral drivers that access embedded devices, such as sensors, input devices, modems, and radios, may be written in kernel mode or user mode. These drivers may be portable across different ODM or OEM board configurations as long as ACPI is updated appropriately.

Firmware

Controller ACPI settings and bus parameters are vendor-specific and dependent on the particular controller. The following table summarizes the ACPI settings for the controller and the peripheral bus.

For an ACPI example, see How to Get the Connection Settings for a Device. For more information about how to integrate devices on low power buses, see Accessing GPIO, I2C, and UART Devices.

Tools and technical reference