[PATCH] Beagle BSP Improvements (GPIO driver)
Gedare Bloom
gedare at rtems.org
Wed Nov 18 15:28:04 UTC 2015
I think this was discussed before. I don't see a ticket on this issue. It
may be worth filing one. I see e-mail from July from TallerTech folks about
the server problem.
On Wed, Nov 18, 2015 at 8:34 AM, Federico Garcia Cruz <
federico.garciacruz at tallertechnologies.com> wrote:
> 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>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151118/53d1497d/attachment-0001.html>
More information about the devel
mailing list