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.garciac...@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.gut...@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 <ketulshah1...@gmail.com> >> wrote: >> > Sorry wrong attachment. Kindly review the recent one. >> > >> > Thanks. >> > >> > Best Regards, >> > Ketul >> > >> > On 23 June 2015 at 20:20, Ketul Shah <ketulshah1...@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 <chr...@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@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel