Fwd: Re: [GSOC] rtems GPIO API

[Chris Nott]

My two cents:

On 22/05/2014 3:30 PM, Andre Marques wrote:
> Hello,
>
> I will start my GSOC project with a GPIO driver for the RPi BSP, and
> part of the GPIO driver code will not be specific to the RPi but to
> any board with a GPIO interface. With code reuse in mind and since I
> did not found any "generic" API for the GPIO interface in the RTEMS
> code base, I intend to propose here an initial *rough* draft of what
> this API may look like.
>
> To initialize the API:
>
> rtems_gpio_initialize (struct gpio_config)
>
> which would initialize the API with a specific GPIO peripheral
> configuration: number of gpio pins, gpio register addresses, ...
>
> To set a gpio pin as input or output (the direction would be a macro):
>
> rtems_gpio_direction (int gpio, int direction)
>
> To set a gpio pull resistor (either pull up/down or no pull resistor):
>
> rtems_gpio_set_Pull (int gpio, int pull)
You probably want to add push-pull/open drain as a pin option.

Some targets would have drive strength or other options as well, that
may be useful to add in the GPIO API ?

>
> Some GPIO I/O:
>
> rtems_gpio_set(int gpio)
> rtems_gpio_clr (int gpio)
> rtems_gpio_read_value (int gpio)
Is it your intention to abstract GPIO as separate single-bit ports? It
might be better to keep the GPIO in natural groupings, otherwise doing
I/O through this API you would lose the ability to toggle multiple pins
in a GPIO group at once, which is sometimes important.

>
> And interrupt management:
>
> rtems_int_enable (int gpio, rtems_interrupt_level int)
> rtems_int_disable (int gpio)
> rtems_int_clear (int gpio)
Interrupts may be a little tricky to abstract in an API. The interrupt
capability for GPIO pins varies a lot.

Also you would need to be able to be able to configure what causes an
interrupt, ie. edge capture options etc.

I think what you are proposing is a good idea, but I think it might be
worth taking a quick survey of the existing platforms supported in RTEMS
to get an idea of the capabilities of the hardware before specifying the
API.

Also, this is only my opinion. I am not really sure what the intention
is with regards to driver API in RTEMS. I expect there is probably going
to be a choice between generic/flexible and performance. For example -
do you support multiple _types_ of GPIO controller? Ie. some kind of
GPIO device driver, which will require call-through-pointer tables and
is going to be a little slower. I am looking at implementing a USB
device API which has the same choice, and so far I think it is safe for
USB to only provide one kind of USB device core "driver" per target, and
thus avoid a layer of indirection.

>
> Would appreciate some feedback on this.
>
> --Andre Marques.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel