[PATCH] Beagle BSP Improvements (GPIO driver)

[Chris Johns]

 [ Just catching up ]

On 26/04/2015 9:26 pm, Ben Gras wrote:
> All,
> 
> I think the API as it is (for digital GPIO's) is pretty close to
> generic. I like my suggestion (gpio_* in my previous mail) better as
> more generic. (More configuration is hidden from the application.)
> 
> Joel I just read your presentation.
> 
> I have come up with a minimal GPIO API based on the above (so
> ultimately based on the RPI API) that just covers the GPIO digital out
> case but allows expansion (with more defines and functions).
> 
> https://devel.rtems.org/wiki/TBR/User/BenGras
> 
> Is this an idea? Then we can merge this code implementing a reasonably
> generic API without having to flesh out the whole thing.
> 

How do we define hardware specific details without bloating the API ?

For example on a zynq project I am working on I needed a GPIO interface
and I decided to use a struct to define the pin and the API takes
references to it. For example to control the write enable pin on a flash
device I have:

static const gpio_pin_def gpio_Flash_WD =
{
  pin:      4,
  output:   true,
  on:       GPIO_FLASH_WD_EN,
  outen:    true,
  volts:    gpio_LVCMOS33,
  pullup:   true,
  fast:     false,
  tristate: false
};

and then I have:

   gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);
   if (ge != GPIO_NO_ERROR)
       return FLASH_WRITE_LOCK_FAIL;

   ....

    gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);

   ....

I need to set the voltage on the pin on the Zynq but this is Zynq specific.

We need a way to let a user convey specific hardware details to the BSP
driver through the API plus we need a light weight API with minimal
internal translations. This approach also lets me define an array of
pins and a single set up call configures them.

So you could have:

typedef struct
{
    int   pin;       /* The pin number. */
    bool  output;    /* True for output, false for input. */
    bool  on;        /* True default output is on */
    bool  outen;     /* True for output enable on, false for off. */
    bool  pullup;    /* True to enable the pull up. */
    bool  tristate;  /* True to enable tri-state. */
    void* platform;  /* Opaque hardware specific set up details. */
} gpio_pin_def;

where the 'platform' references a struct agreed between the BSP (or
device layer) and the user code. For the generic cases this is not
needed and NULL. It also allows layering where a device set up phase of
user code sets the voltages and the generic code can play with the pin
at a generic level, eg direction etc.

What locking is being considered in this API ?

Chris