Date: Fri, 6 Sep 2013 16:51:47 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-embedded <freebsd-embedded@FreeBSD.org> Subject: Re: GPIO hint meanings Message-ID: <E6F64811-B28B-4B79-AC2D-1407E03E6ADF@bsdimp.com> In-Reply-To: <1378506465.1111.489.camel@revolution.hippie.lan> References: <1378488150.1637.5.camel@localhost> <CAB=2f8yEx4UPc1QeHP%2BbJCDadDRvBJyvTkPjztVv4VG5uoULQw@mail.gmail.com> <097A9AFF-D291-4D9F-92CC-12E5E453F7C7@bsdimp.com> <1378504840.1111.480.camel@revolution.hippie.lan> <A42A2E89-E650-4FF4-ACE3-556A8FF02E22@bsdimp.com> <1378506465.1111.489.camel@revolution.hippie.lan>
index | next in thread | previous in thread | raw e-mail
On Sep 6, 2013, at 4:27 PM, Ian Lepore wrote: > On Fri, 2013-09-06 at 16:13 -0600, Warner Losh wrote: >> On Sep 6, 2013, at 4:00 PM, Ian Lepore wrote: >> >>> 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. >> >> Linux is able to have one, although I'm not sure how they handle the daisy-chain... that's a new one on me... >> > > Maybe they just don't, since it's a weird enough thing that probably > nothing uses it. I only discovered it because the datasheet said it was > a potential workaround for an erratum that had to do with a device not > handling a pin properly. Yea, I think that linux doesn't implement that level... > The semi-related thing I've been pondering lately is clock and power > management. I don't even care about dynamic stuff, just a simple common > way for a driver to figure out what clock(s) and/or power need to be on > for it to run, and a common api for turning them on would be nice. > (Whether clocks and power should be two separate APIs or not is a basic > question.) I think the two are interrelated enough they need to at lest be co-releated. But I'd love to see that... Warnerhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E6F64811-B28B-4B79-AC2D-1407E03E6ADF>