[PATCH] Beagle BSP Improvements (GPIO driver)
Federico Garcia Cruz
federico.garciacruz at tallertechnologies.com
Wed Nov 18 13:34:37 UTC 2015
We were wrong about the deadlock, the semaphore is causing that we cannot
set or clear a GPIO output pin inside a GPIO interrupt handler.
We've found that the problem is the way the beaglebone's bsp dispatches the
interrupts: the dispatcher disables the current interrupt vector, dispaches
the interrupt and then it enables again the interrupt vector.
The generic_bank_gpio function also disables the interrupt and then it
enables it again (if not threaded), but as you can see there's an
inconsistency in the way both functions interact.
A time ago I was working with some USB driver for the beaglebone and I
tried to use the RTEMS interrupt server without succes. I found that when
an interrupt is threaded the interrupt vector has to be enabled by the
server thread after this has serviced the interrupt and cleared the
corresponding interrupt flags.
At this moment if you try to use the interrupt server in the beaglebone you
would see that the board hangs because the interrupt vector is enabled by
the dispatcher and then the interrupts flags are never cleared by the
thread because the interrupt is called over and over and any thread can run.
Also we've seen that if we comment the vector disable/enable in the
generic_bank_isr of the shared/gpio.c interrupts work fine but we know this
patch fixes the beaglebone gpio interrupt problem but it could bring a lot
of problems on others bsp.
2015-11-13 18:28 GMT-03:00 Daniel Gutson <
daniel.gutson at tallertechnologies.com>:
> Hi Ketul,
>
> we are experiencing a deadlock that seems to be caused by
>
> +#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s, \
> + RTEMS_WAIT, \
> + RTEMS_NO_TIMEOUT \
> + ) ==
> RTEMS_SUCCESSFUL )
> +
>
> which differs from the previous version. Are you sure this is the
> intended behavior for in-interrupt context? What if the semaphore is
> already locked?
> IIUC this causes either a forever sleep or an assertion in case the
> semaphore cannot be acquired.
>
> Thanks,
>
> Daniel.
>
> On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah <ketulshah1993 at gmail.com>
> wrote:
> > Sorry wrong attachment. Kindly review the recent one.
> >
> > Thanks.
> >
> > Best Regards,
> > Ketul
> >
> > On 23 June 2015 at 20:20, Ketul Shah <ketulshah1993 at gmail.com> wrote:
> >>
> >> Hello all,
> >>
> >> Sorry as I am updating you related to my GPIO API after a huge delay.
> >>
> >> I have developed it and tested it on my BBB. I did some big changes in
> the
> >> API taking in the account comment(s)/suggestion(s) from my respective
> >> mentors.
> >>
> >> I am also looking the API developed by Andre working for Raspberry Pi.
> Now
> >> I think it is a good time to merge the gpio code as API is getting more
> >> stable and generalized.
> >>
> >> So now it is good time to take the best things from API and we can have
> >> common API for GPIO driver running on every embedded board.
> >>
> >> Your comment(s) are welcomed.
> >>
> >> Thanks.
> >>
> >> Best Regards,
> >> Ketul
> >>
> >> On 29 April 2015 at 06:39, Chris Johns <chrisj at rtems.org> wrote:
> >>>
> >>> [ 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
> >>
> >>
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
>
> Daniel F. Gutson
> Chief Engineering Officer, SPD
>
> San Lorenzo 47, 3rd Floor, Office 5
> Córdoba, Argentina
>
> Phone: +54 351 4217888 / +54 351 4218211
> Skype: dgutson
> LinkedIn: http://ar.linkedin.com/in/danielgutson
>
--
<http://www.tallertechnologies.com>
Federico Garcia Cruz
Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211
<http://www.linkedin.com/company/taller-technologies>
<https://www.facebook.com/tallertechnologies>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151118/548769de/attachment.html>
More information about the devel
mailing list