Date: Sun, 9 Nov 2014 12:11:25 -0200 From: Luiz Otavio O Souza <lists.br@gmail.com> To: Rui Paulo <rpaulo@me.com> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org>, embedded@freebsd.org Subject: Re: libgpio Message-ID: <CAB=2f8yqfsKzYcQjkAYyma0eJ0GYh6Ma8n3pw4kETg9trWXEbg@mail.gmail.com> In-Reply-To: <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com> References: <B3B50210-8AE9-411A-84B1-AE6C10494149@me.com> <58908C87-6046-4873-87B1-74995EFA72D1@bsdimp.com> <7B37033A-A7DC-4328-90E0-F33A2A008D68@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 November 2014 02:08, Rui Paulo wrote: > On Nov 7, 2014, at 07:44, Warner Losh wrote: >> 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. Tha= t=E2=80=99s likely a reflection of our GPIO system, I know, but it is a def= iciency. Fortunately, most devices can tolerate multiple pins changing at d= ifferent times before a =E2=80=98clock=E2=80=99 or =E2=80=98enable=E2=80=99= 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 sett= ing multiple pins to their state. We can support this at kernel. Most of gpio controllers provides direct access to the state of a group of pins usually accessed as 'banks' (generally 32 bits/pins wide, but it is not unusual smaller sizes - 8 bits on i2c expanders). We should add the support to do the direct read and write to these banks. This is a task already in the GPIO TODO list (at https://wiki.freebsd.org/FreeBSD/GPIO). > >> What the heck is g_caps? There=E2=80=99s 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 docu= mentation. 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=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 = know that the Atmel gpio stuff did this, but I don=E2=80=99t think that mad= e it into the generalization that was later done. > > There's no kernel support for it, but the library could create a thread t= o poll the pin to see if it has changed. It's wasteful, but I don't see an= y better way until we have GPIO interrupts. The proper implementation for this will only happen when (arm/)intrng is complete. But i think i'll commit what i have for now, which can only work for direct gpio childs (and soon userland), but it is better than what we have today. > >> 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 y= ou don=E2=80=99t normally change a bunch at a time, that=E2=80=99s not so b= ad. > > 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 interfa= ce that we could use to leverage off applications written for Linux? Perhap= s beyond the scope of what you=E2=80=99re trying to do, but any discussion = about pushing things into the base should ask the question =E2=80=9CIs this= the right, most useful interface?=E2=80=9D > > That was correctly answered by Johny. Well... For RPi, they teach how to access and program the GPIO controller via mapped memory (http://elinux.org/RPi_Low-level_peripherals#C). There are many libraries implementing GPIO stuff this way (with the arduino API for example). But then, everything is mostly polled (they are possibly intended for hobby stuff). Rui, as for libgpio, please go for it. Luiz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB=2f8yqfsKzYcQjkAYyma0eJ0GYh6Ma8n3pw4kETg9trWXEbg>