From owner-freebsd-embedded@FreeBSD.ORG Mon Dec 5 16:06:22 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 705C3106564A; Mon, 5 Dec 2011 16:06:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 18B358FC15; Mon, 5 Dec 2011 16:06:22 +0000 (UTC) Received: from 150.imp.bsdimp.com (150.imp.bsdimp.com [10.0.0.150] (may be forged)) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pB5G1olm044579 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 5 Dec 2011 09:01:50 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 5 Dec 2011 09:01:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9681BA0F-B8DE-479C-98B8-6DA702A489CA@bsdimp.com> References: <2B6F6CAC-F4EF-4958-A435-579A69862AE5@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 05 Dec 2011 09:01:51 -0700 (MST) Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:06:22 -0000 On Dec 4, 2011, at 6:29 PM, Adrian Chadd wrote: > On 5 December 2011 01:19, Warner Losh wrote: >=20 >> When I was looking into this question for the Atmel chips, I was = torn. On the one hand, it would be nice if there was a pin mux device. = On the other hand, it didn't map well into the device model. I finally = settled on having per-board functions that setup the pins. This is also = the model followed by linux. Either the boot loader or the = board-dependent code would do the setup. >=20 > I think we should have a per-board set of hints which lets us dictate > non-default GPIO functions and config. You are thinking too narrowly here. It should be thought of as = assigning pin function rather than some GPIO thing. On the Atmel, you = can set multiplex functions (either GPIO, or Ethernet Tx+ for this pin, = etc). I too have wanted per-board hints, possibly several sets in one kernel, = but never had the time to bring that to fruition. > That way we can override what's going on in the board config without > having to write C code. >=20 > As i said, something like this: >=20 > hint.blah.gpiofunction_set=3D"0x10000000" > hint.blah.gpiofunction_clear=3D"0x00130000" For the AR71xx, that might suffice, but it isn't adequate in general. I = also really don't like the names, since it is more of a pin function = than a GPIO function. > It'd also be useful if the device drivers would do this themselves - > eg the ar71xx USB device driver could ensure that the relevant GPIO > function wire were enabled. No. That's wrong, at least generally. The USB driver has no business = setting these things up. That's for the board level init code. The = board level init code can pass data to the USB driver saying that it set = things up for USB and the driver can then fail to attach when those pins = are setup for other things. Having tried to get all the Atmel drivers to automagically set = themselves up turned out to be a total fiasco. I tried it when I was = bringing the boards at Timing Solutions up. It worked great for the = eval board, but turned into a night mare of special case hacks when I = moved the code over to the custom board we were developing. I'd = strongly suggest that the driver is not the place to do this, any more = than the driver is the place to assign PCI resources: this sort of thing = belongs at a higher level. > But we may need to _disable_ some of these > default pins (eg if the eeprom has enabled the digital sound function > block on the SoC) so i still think having the above would work. Right, that's why I think that the board init code should be the one to = muck with the pins. Wether that is done via hints or hard-coded 'C' I = don't care too much for, but inside the driver is definitely the wrong = place to do it. Warner=