Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Nov 2014 08:33:33 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "freebsd-arm@freebsd.org" <arm@freebsd.org>, "freebsd-embedded@freebsd.org" <embedded@freebsd.org>, Rui Paulo <rpaulo@me.com>
Subject:   Re: libgpio
Message-ID:  <CAJ-VmokCe3smZPQmTtz2QXf5Wou-gUV%2BWO3RX3=1o-=MFYc2BA@mail.gmail.com>
In-Reply-To: <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com>
References:  <B3B50210-8AE9-411A-84B1-AE6C10494149@me.com> <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

Yes, it'd be nice to (later) add an API call that takes multiple pin
updates (and reads multiple pin updates.) That way higher speed, time
critical stuff can be done for drivers that grow this feature and can
do batched/timestamped GPIO events.



-adrian


On 7 November 2014 07:44, Warner Losh <imp@bsdimp.com> wrote:
>
> On Nov 6, 2014, at 11:41 PM, Rui Paulo <rpaulo@me.com> wrote:
>
>> Hi,
>>
>> Some time ago, I wrote a gpio library as a way to interact with the kern=
el gpio driver in a more sensible way (hiding the details of opening a /dev=
 file, handling all the ioctls, etc.).
>>
>> Here's the project code:
>>
>>       https://bitbucket.org/rpaulo/libgpio/src
>>
>> Here's the header file:
>>
>>       https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf=
667a5c06bbade8d/libgpio.h?at=3Ddefault
>>
>> It looks like some people started using the library and I was wondering =
if it would be a good candidate for the base system.  I would rewrite gpioc=
tl to use it and I'm open to changing the library API.
>>
>> Any comments?
>
> I generally like it. Here=E2=80=99s some suggestions, though many may be =
hard given that our gpio interface is a bit weak.
>
> First, there=E2=80=99s no way to set multiple pins at the same time. That=
=E2=80=99s likely a reflection of our GPIO system, I know, but it is a defi=
ciency. Fortunately, most devices can tolerate multiple pins changing at di=
fferent times before a =E2=80=98clock=E2=80=99 or =E2=80=98enable=E2=80=99 =
pin forces them to latch their state.
>
> What the heck is g_caps? There=E2=80=99s nothing at all to describe it. N=
ot even an indirection to look at sys/gpio.h
>
> For systems that have multiple GPIO devices (some have a few hundred I/O =
lines that can be addressed), how
> do you handle that? Do you just kinda have to know these details?
>
> There=E2=80=99s no facilities for interrupts (usually you=E2=80=99d like =
to say =E2=80=9Cwait for this line to change and let me know=E2=80=9D). I k=
now that the Atmel gpio stuff did this, but I don=E2=80=99t think that made=
 it into the generalization that was later done.
>
> I=E2=80=99m not sure that I like the gpio_pin_* helper functions causing =
the thing to change, rather than operating on a gpio_config_t. But since yo=
u don=E2=80=99t normally change a bunch at a time, that=E2=80=99s not so ba=
d.
>
> Finally a question: What does Linux do here? Is there a standard interfac=
e that we could use to leverage off applications written for Linux? Perhaps=
 beyond the scope of what you=E2=80=99re trying to do, but any discussion a=
bout pushing things into the base should ask the question =E2=80=9CIs this =
the right, most useful interface?=E2=80=9D
>
> Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokCe3smZPQmTtz2QXf5Wou-gUV%2BWO3RX3=1o-=MFYc2BA>