From owner-freebsd-embedded@FreeBSD.ORG Fri Sep 6 22:57:06 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 A013CED4 for ; Fri, 6 Sep 2013 22:57:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 679C42FFE for ; Fri, 6 Sep 2013 22:57:06 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so4060578obc.21 for ; Fri, 06 Sep 2013 15:57:05 -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=froPnki3d3SfX/AZM4yo7dsRgKY5Xa8rU58hVtmjXec=; b=IwvxUPqcDmk9byYPrao5GAzKfrtBlcYN+cooi2PJp+ZkuQ2XK+Z2ieyNA7fWIAb+es BAhLi7rD716Fm76WzAtfpU+Y6mWnGH/WG3MzcClTrOcFSJ38ZSZE5FJRVcz9Tm9kUcTV CCDkC0Kt+IJgBXvKha48Pliw2xIfhAn+fa1jiCJPXimU1F4fD0lucI95RPP0fQmNcvzK uSoled4NjKM3mPHpKMjJwqUhlkmp00IbI5mWPi7jX0NH7GtLtCFhiVF+Lx7F1C5GkBp3 jAMQKqqP3zMK2Z65GzoOZ5uXlFstKPg9d4F2KPwdMlMLtZ55q+og/9QS77hAs1Ny+EKx dkMQ== X-Gm-Message-State: ALoCoQmpybtRfdgr2Uw+CtR87p38m+lULftFsqBRkCTqUbKPeJ71XF3aL5ram98uVSJRMsRi6ZP1 X-Received: by 10.182.246.39 with SMTP id xt7mr3661596obc.16.1378507911146; Fri, 06 Sep 2013 15:51:51 -0700 (PDT) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id y1sm133396oek.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 15:51:49 -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: <1378506465.1111.489.camel@revolution.hippie.lan> Date: Fri, 6 Sep 2013 16:51:47 -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> <1378506465.1111.489.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:57:06 -0000 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: >>=20 >>> 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. >>=20 >> Linux is able to have one, although I'm not sure how they handle the = daisy-chain... that's a new one on me... >>=20 >=20 > 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...=20 > 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... Warner=