From owner-freebsd-embedded@FreeBSD.ORG Fri Sep 6 23:41:09 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 D904BE70; Fri, 6 Sep 2013 23:41:09 +0000 (UTC) (envelope-from jhein@symmetricom.com) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED4E27A6; Fri, 6 Sep 2013 23:41:09 +0000 (UTC) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r86NDaZs056695; Fri, 6 Sep 2013 17:13:36 -0600 (MDT) (envelope-from jhein@symmetricom.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.7/8.14.5) with ESMTP id r86NDKX1031321; Fri, 6 Sep 2013 17:13:20 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.7/8.14.6/Submit) id r86NDKmL031320; Fri, 6 Sep 2013 17:13:20 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21034.24976.184098.797870@gromit.timing.com> Date: Fri, 6 Sep 2013 17:13:20 -0600 From: John Hein To: Ian Lepore Subject: Re: GPIO hint meanings In-Reply-To: <1378506465.1111.489.camel@revolution.hippie.lan> 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> X-Mailer: VM 8.2.0b-trunk-1484 under 24.3.1 (i386-portbld-freebsd8.3) 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 23:41:09 -0000 Ian Lepore wrote at 16:27 -0600 on Sep 6, 2013: > 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: [snip] > > >> 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. They love their special filesystems, they do. I suspect the first hacker to add support for fancy new GPIO feature for whatever gets to pick the "filename" in the /sys/clas/gpio/gpioX tree or special value to echo > to it. https://www.kernel.org/doc/Documentation/gpio.txt > 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.)