Date: Fri, 07 Nov 2014 20:08:40 -0800 From: Rui Paulo <rpaulo@me.com> To: Warner Losh <imp@bsdimp.com> Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: libgpio Message-ID: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.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
On Nov 7, 2014, at 07:44, Warner Losh <imp@bsdimp.com> wrote: > I generally like it. Here=92s some suggestions, though many may be = hard given that our gpio interface is a bit weak. >=20 > First, there=92s no way to set multiple pins at the same time. That=92s = likely a reflection of our GPIO system, I know, but it is a deficiency. = Fortunately, most devices can tolerate multiple pins changing at = different times before a =91clock=92 or =91enable=92 pin forces them to = latch their state. OK; I'll work on an API that does this even if it's just a for loop = setting multiple pins to their state. > What the heck is g_caps? There=92s nothing at all to describe it. Not = even an indirection to look at sys/gpio.h It's what describes the pin: input/output/pullup/etc. I'll add some = documentation. I need to write a man page anyway. > 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? Right now you have to work with each individually. We could change it = so that it opens all gpio devices and provides a structure that includes = all pins. > There=92s no facilities for interrupts (usually you=92d like to say = =93wait for this line to change and let me know=94). I know that the = Atmel gpio stuff did this, but I don=92t think that made it into the = generalization that was later done. There's no kernel support for it, but the library could create a thread = to poll the pin to see if it has changed. It's wasteful, but I don't = see any better way until we have GPIO interrupts. > I=92m 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 you = don=92t normally change a bunch at a time, that=92s not so bad. I just added those to make it easy to configure pins in one shot. > Finally a question: What does Linux do here? Is there a standard = interface that we could use to leverage off applications written for = Linux? Perhaps beyond the scope of what you=92re trying to do, but any = discussion about pushing things into the base should ask the question = =93Is this the right, most useful interface?=94 That was correctly answered by Johny. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7B37033A-A7DC-4328-90E0-F33A2A008D68>