Searched hist:ae7123f876357a81fc4c393239a378f1058cad5e (Results 1 – 2 of 2) sorted by relevance
| /openbmc/u-boot/include/asm-generic/ |
| H A D | gpio.h | diff ae7123f876357a81fc4c393239a378f1058cad5e Mon Jan 05 21:05:27 CST 2015 Simon Glass <sjg@chromium.org> dm: gpio: Add a native driver model API
So far driver model's GPIO uclass just implements the existing GPIO API.
This has some limitations:
- it requires manual device tree munging to support GPIOs in device tree
(fdtdec_get_gpio() and friends)
- it does not understand polarity
- it is somewhat slower since we must scan for the GPIO device each time
- Global GPIO numbering can change if other GPIO drivers are probed
- it requires extra steps to set the GPIO direction and value
The new functions have a dm_ prefix where necessary to avoid name conflicts
but we can remove that when it is no-longer needed. The new struct gpio_desc
holds all required information about the GPIO. For now this is intended to
be stored by the client requesting the GPIO, but in future it might be
brought into the uclass in some way.
With these changes the old GPIO API still works, and uses the driver model
API underneath.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| /openbmc/u-boot/drivers/gpio/ |
| H A D | gpio-uclass.c | diff ae7123f876357a81fc4c393239a378f1058cad5e Mon Jan 05 21:05:27 CST 2015 Simon Glass <sjg@chromium.org> dm: gpio: Add a native driver model API
So far driver model's GPIO uclass just implements the existing GPIO API.
This has some limitations:
- it requires manual device tree munging to support GPIOs in device tree
(fdtdec_get_gpio() and friends)
- it does not understand polarity
- it is somewhat slower since we must scan for the GPIO device each time
- Global GPIO numbering can change if other GPIO drivers are probed
- it requires extra steps to set the GPIO direction and value
The new functions have a dm_ prefix where necessary to avoid name conflicts
but we can remove that when it is no-longer needed. The new struct gpio_desc
holds all required information about the GPIO. For now this is intended to
be stored by the client requesting the GPIO, but in future it might be
brought into the uclass in some way.
With these changes the old GPIO API still works, and uses the driver model
API underneath.
Signed-off-by: Simon Glass <sjg@chromium.org>
|