[PATCH] Beagle BSP Improvements (GPIO driver)

[Gedare Bloom]

Try to get send-email to work. Split your patch into two, the generic
GPIO code (that should overlap substantially with Andre's), and the
BBB driver. Can the gpio.c test case be written without having to
specify the BSP? I mean, does beagleboneblack.h need to be included
there? We won't commit BSP-specific test cases to RTEMS (currently).
Check the coding conventions and fix the style problems. I've
mentioned these before.

Gedare

On Tue, Jun 23, 2015 at 10: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