[GSOC] GPIO status and I2C start

[Alan Cudmore]

Hi Pavel,
Thanks for the feedback, we will definitely get the parameter change in
when the code is submitted.

Alan



On Thu, Aug 21, 2014 at 8:20 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:

> Hello everybody,
>
> I am happy that the common GPIO API for RTEMS is developed
> but I have some concerns about IRQ handlers registration.
>
> On Sunday 06 of July 2014 00:58:23 Andre Marques wrote:
> > Hello,
> >
> > The Raspberry Pi GPIO interrupts are already working, and a test case is
> > available to test that [1]. A function is also provided to debounce a
> > switch if needed. The test case requires two switches and two LEDS using
> > the same setup described at [2] by only changing the pin numbers.
>
>
> https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IRQ/init.c
>
> http://wiki.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals
>
> The registered handler has no context parameter.This is unfortunate
> because there is often need to do same or similar processing
> for more interrupt sources and this way it means to write
> individual handler or trampoline for each pin.
>
> Please change registered handler prototype to same type
> as rtems_interrupt_handler used in rtems_interrupt_handler_install
>
>   typedef void (*rtems_interrupt_handler)(void *);
>
> then function prototype of gpio_enable_interrupt() should add
> void *arg and its value should be stored together with handler
> pointer and pass to the handler when called.
>
> In the fact, Linux kernel goes even more further where it
> statically or runtime allocates numbers for individual
> IO pins interrupt sources in the main interrupt table.
> Then GPIO provides only function to map GPIO number
> to IRQ source number and standard registration
> of interrupt handler is used to register to individual
> pin interrupt. That has advantage, that drivers of peripherals
> do not need to distinguish if their peripheral is connected
> to direct external IRQ source or to the GPIO pin which needs
> cascade IRQ event processing. In RTEMS that would lead to
> use of rtems_interrupt_handler_install even for GPIO IRQs.
>
> But that would require more changes. But passing of context
> to the handler is very important and fortunately RTEMS
> has switched from other handler prototypes to this standard
> years ago already.
>
> Best wishes,
>
>                 Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140821/8ec094d7/attachment-0002.html>