Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Sep 2013 16:00:40 -0600
From:      Ian Lepore <ian@FreeBSD.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-embedded <freebsd-embedded@FreeBSD.org>
Subject:   Re: GPIO hint meanings
Message-ID:  <1378504840.1111.480.camel@revolution.hippie.lan>
In-Reply-To: <097A9AFF-D291-4D9F-92CC-12E5E453F7C7@bsdimp.com>
References:  <1378488150.1637.5.camel@localhost> <CAB=2f8yEx4UPc1QeHP%2BbJCDadDRvBJyvTkPjztVv4VG5uoULQw@mail.gmail.com> <097A9AFF-D291-4D9F-92CC-12E5E453F7C7@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2013-09-06 at 13:42 -0600, Warner Losh wrote:
> On Sep 6, 2013, at 12:31 PM, Luiz Otavio O Souza wrote:
> 
> > On 6 September 2013 14:22, Sean Bruno <sean_bruno@yahoo.com> wrote:
> > 
> >> I think I have a fairly firm grasp on what some of the mips/gpio hints
> >> mean, e.g.:
> >> 
> >> hint.gpio.0.pinmask
> >> hint.gpioled.0.at
> >> hint.gpioled.0.name
> >> hint.gpioled.0.pins
> >> 
> >> Fairly straightforward.
> >> 
> >> Now, what do these mean/do:
> >> 
> >> hint.gpio.0.function_set
> >> hint.gpio.0.function_clear
> >> 
> >> ?
> >> 
> >> Sean
> >> 
> >> p.s. I think I'll take this and thrash together a gpioled(4) and gpio(4)
> >> man page if I can understand better.
> >> 
> > 
> > 
> > Hi Sean,
> > 
> > Some of the GPIO pins on this SoC family (ar724x, ar71xx and ar9xxx) can be
> > set between GPIO and an alternate function. So adding a pin to function_set
> > enables this alternate function and the function_clear disables it
> > (sometimes the bootloader doesn't initialize properly those pins).
> > 
> > Each SoC has its own set of pins and functions.
> > 
> > For ar71xx the pins 0 and 1 can be used as additional SPI chip select
> > outputs, pins 9 and 10 are used for UART and there are also reserved pins
> > for a SLIC/I2S interface.
> 
> 
> We really need a pinmux/pinctl type interface for this which is standard across drivers/platforms.
> 

The more ARM SoCs I look at, the less I think we could design a single
pinmux api that works for all of them.  The number of things that can be
controlled varies from almost-nothing to chips that let you select from
one of a dozen different resistor strengths for pullup or pulldown per
pin.  And that's not to mention really crazy things like daisy-chaining
pins so the signal also goes to another pin which can be forced as an
input even though it's normally a device output.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1378504840.1111.480.camel>