From owner-freebsd-embedded@FreeBSD.ORG Fri Sep 6 22:27:50 2013 Return-Path: Delivered-To: freebsd-embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5728B632 for ; Fri, 6 Sep 2013 22:27:50 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2BBFF2E09 for ; Fri, 6 Sep 2013 22:27:49 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VI4VI-0000Zk-S4; Fri, 06 Sep 2013 22:27:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r86MRkWg073156; Fri, 6 Sep 2013 16:27:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/qNVVlXwxDTaF0SwpJLmFc Subject: Re: GPIO hint meanings From: Ian Lepore To: Warner Losh In-Reply-To: References: <1378488150.1637.5.camel@localhost> <097A9AFF-D291-4D9F-92CC-12E5E453F7C7@bsdimp.com> <1378504840.1111.480.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Sep 2013 16:27:45 -0600 Message-ID: <1378506465.1111.489.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-embedded X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 22:27:50 -0000 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 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. 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.) -- Ian