[PATCH] Beagle BSP Improvements (GPIO driver)

[Daniel Gutson]

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