From owner-freebsd-embedded@FreeBSD.ORG Fri Sep 6 22:13:36 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 047A4143 for ; Fri, 6 Sep 2013 22:13:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDE2A2D69 for ; Fri, 6 Sep 2013 22:13:35 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h1so4516274oag.38 for ; Fri, 06 Sep 2013 15:13:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6QEnzEJ8kmC8Ek7/IJ2oGR9OzMgeT/xXK0QAesnOWsQ=; b=ZyxOHw1141A0IuvRfUoLcxvTV5/aT8UL9/r1z9FgBpvqQB6g7Y3DvdpvPPqs5V+QuA Zk45ZSJDiX6Xzc07tEo+rPewVjQ5h77GhgzYkGweNn+gmc2REBYvyORgJqt2PdDhHF40 6FEKlSOng4w+R+0L88V5JFr17Wj780BuJ/KiVibQmSt4xqI8gsOsWCbBb6B4wENY9U9g 2a/K+l3ZxWoI6rbnWv74xWcFZ8GeIGRTmjRyrBHe8vYs8EHS111612I7SNSJiJRQBVOs HE49URixPHIQDxsJl0B7sTp6dtULREigzNTF53m8NiPyO+/ZbSlVQz0FH/jRt+xF7Gwr qW0w== X-Gm-Message-State: ALoCoQn+OCLE4m/VoLQtcAVIxVfOlXzhTVLprPtRTg3dJhmaf4UxU/Z6p98L/J93uMIsZk0itXOw X-Received: by 10.182.96.100 with SMTP id dr4mr3554165obb.22.1378505609539; Fri, 06 Sep 2013 15:13:29 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id bq4sm4837159obb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 15:13:28 -0700 (PDT) Sender: Warner Losh Subject: Re: GPIO hint meanings Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1378504840.1111.480.camel@revolution.hippie.lan> Date: Fri, 6 Sep 2013 16:13:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1378488150.1637.5.camel@localhost> <097A9AFF-D291-4D9F-92CC-12E5E453F7C7@bsdimp.com> <1378504840.1111.480.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) 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:13:36 -0000 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: >>=20 >>> On 6 September 2013 14:22, Sean Bruno wrote: >>>=20 >>>> I think I have a fairly firm grasp on what some of the mips/gpio = hints >>>> mean, e.g.: >>>>=20 >>>> hint.gpio.0.pinmask >>>> hint.gpioled.0.at >>>> hint.gpioled.0.name >>>> hint.gpioled.0.pins >>>>=20 >>>> Fairly straightforward. >>>>=20 >>>> Now, what do these mean/do: >>>>=20 >>>> hint.gpio.0.function_set >>>> hint.gpio.0.function_clear >>>>=20 >>>> ? >>>>=20 >>>> Sean >>>>=20 >>>> p.s. I think I'll take this and thrash together a gpioled(4) and = gpio(4) >>>> man page if I can understand better. >>>>=20 >>>=20 >>>=20 >>> Hi Sean, >>>=20 >>> 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). >>>=20 >>> Each SoC has its own set of pins and functions. >>>=20 >>> 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. >>=20 >>=20 >> We really need a pinmux/pinctl type interface for this which is = standard across drivers/platforms. >>=20 >=20 > 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... Warner=