<div dir="ltr">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.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 18, 2015 at 8:34 AM, Federico Garcia Cruz <span dir="ltr"><<a href="mailto:federico.garciacruz@tallertechnologies.com" target="_blank">federico.garciacruz@tallertechnologies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">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. </span><div style="font-size:12.8px">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. <div>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. </div><div>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.</div><div>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.</div><div>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.</div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2015-11-13 18:28 GMT-03:00 Daniel Gutson <span dir="ltr"><<a href="mailto:daniel.gutson@tallertechnologies.com" target="_blank">daniel.gutson@tallertechnologies.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ketul,<br>
<br>
we are experiencing a deadlock that seems to be caused by<br>
<br>
+#define OBTAIN_LOCK(s) assert( rtems_semaphore_obtain(s, \<br>
+ RTEMS_WAIT, \<br>
+ RTEMS_NO_TIMEOUT \<br>
+ ) == RTEMS_SUCCESSFUL )<br>
+<br>
<br>
which differs from the previous version. Are you sure this is the<br>
intended behavior for in-interrupt context? What if the semaphore is<br>
already locked?<br>
IIUC this causes either a forever sleep or an assertion in case the<br>
semaphore cannot be acquired.<br>
<br>
Thanks,<br>
<br>
Daniel.<br>
<br>
On Tue, Jun 23, 2015 at 11:53 AM, Ketul Shah <<a href="mailto:ketulshah1993@gmail.com" target="_blank">ketulshah1993@gmail.com</a>> wrote:<br>
> Sorry wrong attachment. Kindly review the recent one.<br>
><br>
> Thanks.<br>
><br>
> Best Regards,<br>
> Ketul<br>
><br>
> On 23 June 2015 at 20:20, Ketul Shah <<a href="mailto:ketulshah1993@gmail.com" target="_blank">ketulshah1993@gmail.com</a>> wrote:<br>
>><br>
>> Hello all,<br>
>><br>
>> Sorry as I am updating you related to my GPIO API after a huge delay.<br>
>><br>
>> I have developed it and tested it on my BBB. I did some big changes in the<br>
>> API taking in the account comment(s)/suggestion(s) from my respective<br>
>> mentors.<br>
>><br>
>> I am also looking the API developed by Andre working for Raspberry Pi. Now<br>
>> I think it is a good time to merge the gpio code as API is getting more<br>
>> stable and generalized.<br>
>><br>
>> So now it is good time to take the best things from API and we can have<br>
>> common API for GPIO driver running on every embedded board.<br>
>><br>
>> Your comment(s) are welcomed.<br>
>><br>
>> Thanks.<br>
>><br>
>> Best Regards,<br>
>> Ketul<br>
>><br>
>> On 29 April 2015 at 06:39, Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br>
>>><br>
>>> [ Just catching up ]<br>
>>><br>
>>> On 26/04/2015 9:26 pm, Ben Gras wrote:<br>
>>> > All,<br>
>>> ><br>
>>> > I think the API as it is (for digital GPIO's) is pretty close to<br>
>>> > generic. I like my suggestion (gpio_* in my previous mail) better as<br>
>>> > more generic. (More configuration is hidden from the application.)<br>
>>> ><br>
>>> > Joel I just read your presentation.<br>
>>> ><br>
>>> > I have come up with a minimal GPIO API based on the above (so<br>
>>> > ultimately based on the RPI API) that just covers the GPIO digital out<br>
>>> > case but allows expansion (with more defines and functions).<br>
>>> ><br>
>>> > <a href="https://devel.rtems.org/wiki/TBR/User/BenGras" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/TBR/User/BenGras</a><br>
>>> ><br>
>>> > Is this an idea? Then we can merge this code implementing a reasonably<br>
>>> > generic API without having to flesh out the whole thing.<br>
>>> ><br>
>>><br>
>>> How do we define hardware specific details without bloating the API ?<br>
>>><br>
>>> For example on a zynq project I am working on I needed a GPIO interface<br>
>>> and I decided to use a struct to define the pin and the API takes<br>
>>> references to it. For example to control the write enable pin on a flash<br>
>>> device I have:<br>
>>><br>
>>> static const gpio_pin_def gpio_Flash_WD =<br>
>>> {<br>
>>> pin: 4,<br>
>>> output: true,<br>
>>> on: GPIO_FLASH_WD_EN,<br>
>>> outen: true,<br>
>>> volts: gpio_LVCMOS33,<br>
>>> pullup: true,<br>
>>> fast: false,<br>
>>> tristate: false<br>
>>> };<br>
>>><br>
>>> and then I have:<br>
>>><br>
>>> gpio_error ge = gpio_setup_pin(&gpio_Flash_WD);<br>
>>> if (ge != GPIO_NO_ERROR)<br>
>>> return FLASH_WRITE_LOCK_FAIL;<br>
>>><br>
>>> ....<br>
>>><br>
>>> gpio_output(gpio_Flash_WD.pin, GPIO_FLASH_WD_EN);<br>
>>><br>
>>> ....<br>
>>><br>
>>> I need to set the voltage on the pin on the Zynq but this is Zynq<br>
>>> specific.<br>
>>><br>
>>> We need a way to let a user convey specific hardware details to the BSP<br>
>>> driver through the API plus we need a light weight API with minimal<br>
>>> internal translations. This approach also lets me define an array of<br>
>>> pins and a single set up call configures them.<br>
>>><br>
>>> So you could have:<br>
>>><br>
>>> typedef struct<br>
>>> {<br>
>>> int pin; /* The pin number. */<br>
>>> bool output; /* True for output, false for input. */<br>
>>> bool on; /* True default output is on */<br>
>>> bool outen; /* True for output enable on, false for off. */<br>
>>> bool pullup; /* True to enable the pull up. */<br>
>>> bool tristate; /* True to enable tri-state. */<br>
>>> void* platform; /* Opaque hardware specific set up details. */<br>
>>> } gpio_pin_def;<br>
>>><br>
>>> where the 'platform' references a struct agreed between the BSP (or<br>
>>> device layer) and the user code. For the generic cases this is not<br>
>>> needed and NULL. It also allows layering where a device set up phase of<br>
>>> user code sets the voltages and the generic code can play with the pin<br>
>>> at a generic level, eg direction etc.<br>
>>><br>
>>> What locking is being considered in this API ?<br>
>>><br>
>>> Chris<br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
<br>
Daniel F. Gutson<br>
Chief Engineering Officer, SPD<br>
<br>
San Lorenzo 47, 3rd Floor, Office 5<br>
Córdoba, Argentina<br>
<br>
Phone: <a href="tel:%2B54%20351%204217888" value="+543514217888" target="_blank">+54 351 4217888</a> / <a href="tel:%2B54%20351%204218211" value="+543514218211" target="_blank">+54 351 4218211</a><br>
Skype: dgutson<br>
LinkedIn: <a href="http://ar.linkedin.com/in/danielgutson" rel="noreferrer" target="_blank">http://ar.linkedin.com/in/danielgutson</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div>-- <br><div><div dir="ltr"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><a href="http://www.tallertechnologies.com" style="text-decoration:none" target="_blank"><span style="font-size:16px;font-family:Arial;color:#1155cc;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap"><img src="https://lh6.googleusercontent.com/oWr5yxNDJfjF0N2yhmiSzhU9vstfXfDLCQju49Xj_5frxoG-vk_hKzOt-k3KSsZv5W5cNnZSjNmWi53XYbfiAsytvz44AptjWiDYFTLIhRiRifwjwHtlfPJmhrqmfEub1w" style="border:none" height="77" width="200"></span></a></p><p style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><br></b></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:16px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Federico Garcia Cruz</span></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Software Engineer</span></p><span class=""><p style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><br></b></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">San Lorenzo 47, 3rd Floor, Office 5</span></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Córdoba, Argentina</span></p><p style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><b style="font-weight:normal"><br></b></p><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11px;font-family:Arial;color:#000000;background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Phone:</span><span style="font-size:11px;font-family:Arial;color:#000000;background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> <a href="tel:%2B54%20351%204217888" value="+543514217888" target="_blank">+54 351 4217888</a> / <a href="tel:%2B54%20351%204218211" value="+543514218211" target="_blank">+54 351 4218211</a></span></p></span><p style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><br><a href="http://www.linkedin.com/company/taller-technologies" style="text-decoration:none" target="_blank"><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><img src="https://lh5.googleusercontent.com/-PNbLrk4FTcGDH9qlK0E9EOXNq30yjxcZdWdV1nrz0nea-2DSHK5Imha-1oItxasCqkHsragWxBQoGaM6htV8ZiSNmtX0zr_6h7l5SAekmvgRly09D1cmbVt4sQ8cKtmIQ" style="border:none" height="20px;" width="20px;"></span></a><a href="https://www.facebook.com/tallertechnologies" style="text-decoration:none" target="_blank"><span style="font-size:15px;font-family:Arial;color:rgb(17,85,204);text-decoration:underline;vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><img src="https://lh6.googleusercontent.com/35gyAmo2veV0QIAK20LuNB8ouSDb62YfPd5NEbXdxvdLdbt8aNQo4c9SSXKUhbi8L69xj0fFH9HgavVbFraoqN04JrxkLfRzwsMLY2nTfDChb5Neflw7ezpE6_LxseIKGw" style="border:none" height="19px;" width="19px;"></span></a><br></p></div></div>
</div>
<br>_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br></blockquote></div><br></div></div></div>