123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106 |
- The U-Boot Driver Model Project
- ===============================
- GPIO analysis
- =============
- Viktor Krivak <viktor.krivak@gmail.com>
- 2012-02-24
- I) Overview
- -----------
- At this moment U-Boot provides standard API that consists of 7 functions.
- int gpio_request(unsigned gpio, const char *label)
- int gpio_free(unsigned gpio)
- int gpio_direction_input(unsigned gpio)
- int gpio_direction_output(unsigned gpio, int value)
- int gpio_get_value(unsigned gpio)
- void gpio_set_value(unsigned gpio, int value)
- Methods "gpio_request()" and "gpio_free()" are used for claiming and releasing
- GPIOs. First one should check if the desired pin exists and if the pin wasn't
- requested already elsewhere. The method also has a label argument that can be
- used for debug purposes. The label argument should be copied into the internal
- memory, but only if the DEBUG macro is set. The "gpio_free()" is the exact
- opposite. It releases the particular pin. Other methods are used for setting
- input or output direction and obtaining or setting values of the pins.
- II) Approach
- ------------
- 1) Request and free GPIO
- ------------------------
- The "gpio_request()" implementation is basically the same for all boards.
- The function checks if the particular GPIO is correct and checks if the
- GPIO pin is still free. If the conditions are met, the method marks the
- GPIO claimed in it's internal structure. If macro DEBUG is defined, the
- function also copies the label argument to the structure. If the pin is
- already locked, the function returns -1 and if DEBUG is defined, certain
- debug output is generated, including the contents of the label argument.
- The "gpio_free()" function releases the lock and eventually deallocates
- data used by the copied label argument.
- 2) Internal data
- ----------------
- Internal data are driver specific. They have to contain some mechanism to
- realise the locking though. This can be done for example using a bit field.
- 3) Operations provided by the driver
- ------------------------------------
- The driver operations basically meet API that is already defined and used.
- Except for "gpio_request()" and "gpio_free()", all methods can be converted in
- a simple manner. The driver provides the following structure:
- struct gpio_driver_ops {
- int (*gpio_request)(struct instance *i, unsigned gpio,
- const char *label);
- int (*gpio_free)(struct instance *i, unsigned gpio);
- int (*gpio_direction_input)(struct instance *i, unsigned gpio);
- int (*gpio_direction_output)(struct instance *i, unsigned gpio,
- int value);
- int (*gpio_get_value)(struct instance *i, unsigned gpio);
- void (*gpio_set_value)(struct instance *i, unsigned gpio, int value);
- }
- III) Analysis of in-tree drivers
- --------------------------------
- 1) altera_pio.c
- ---------------
- Meets standard API. Implements gpio_request() properly. Simple conversion
- possible.
- 2) at91_gpio.c
- --------------
- Don't meet standard API. Need some other methods to implement.
- 3) da8xx_gpio.c
- ---------------
- Meets standard API. Implements gpio_request() properly. Simple conversion
- possible.
- 4) kw_gpio.c
- ------------
- Doesn't meet standard API. Needs some other methods to implement and move some
- methods to another file.
- 5) mpc83xx_gpio.c
- -----------------
- Meets standard API. Doesn't implement gpio_request() properly (only checks
- if the pin is valid). Simple conversion possible.
- 6) mvgpio.c
- -----------
- Meets standard API. Doesn't implement gpio_request() properly (only checks
- if the pin is valid). Simple conversion possible.
- 7) mvgpio.h
- -----------
- Wrong placement. Will be moved to another location.
- 8) mvmfp.c
- ----------
- Wrong placement. Will be moved to another location.
|