Using the GPIO Client Interface in a device driver

Configuration and initialization

When a device driver uses input and output from GPIO, typically the driver is a PDD and GPIO is a kernel extension, the driver being a client of GPIO. Unlike all other hardware implementations except Resource Manager, a GPIO implementation must have an initial state reflecting the configuration of the pins as determined by the hardware connected to them and by the OS Loader (NLoader). GPIO therefore needs to be configured at boot, and this is done using the Hardware Configuration Repository (HCR) which is also a kernel extension. For this reason, HCR must be loaded at boot before GPIO and any other kernel extension which uses pins. HCR supplies the following items of data to GPIO.

• The number of pin banks.

• The base address of all pin banks.

• The total number of pins.

• What functions are not supported by the hardware.

HCR also supplies GPIO with the following data about individual pins.

For each pin:

• The numeric value corresponding to the logical pin name.

• The run mode pin direction.

• The alternate mode value, if the pin is to be used in alternate mode.

• The run mode pin bias.

• The pin configuration for power saving mode if the SOC supports power saving.

For each output pin:

• The value of the state corresponding to the logical state

For each input pin:

• The debounce time

• The wakeup trigger, if the pin is configured in GPIO mode

For each input pin used as an interrupt source:

• The input trigger configuration

GPIO uses these values as arguments of the appropriate API functions to set the values. For instance, if the debounce time for a certain pin has been retrieved, that value is passed to a call to SetDebounceTime().

Some pins are not constrained by hardware and need to be configured by the client in the mode required for its own operation. For each pin not constrained by hardware the client must:

• Set the pin to GPIO enabled.

• Set the pin direction.

• Set the pin bias.

• Set the numeric value of alternative modes where needed.

Power-aware drivers may need to configure the input pins which they use to wake up the system and the driver itself so it can respond to signals on those pins. Some output pins may also need to be configured.

Steady state of the client

Once initialization is complete, the client enters its 'steady state' and begins operations.

If the client is using the pins to input and output data it calls the GPIO functions SetOutputState() and GetInputState() as required.

If the client driver is using pins as a source of interrupts it must define an interrupt service routine (ISR) to be dispatched by the interrupt handler. After an interrupt the client must stop the GPIO hardware from interrupting the CPU with calls to the GPIO APIs GetMaskedInterruptState() and ClearInterrupt().

Unloading and stopping the client

When the client is unloaded it must disable the interupts with calls to the GPIO functions DisableInterrupt() and UnbindInterrupt() and set the output pins to idle with calls to the GPIO functions SetOutputState() and SetPinMode(), and it must also set the output pins to idle when it is stopped.