From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 4 13:59:07 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 B9CB7106564A; Sun, 4 Dec 2011 13:59:07 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 81F928FC0C; Sun, 4 Dec 2011 13:59:07 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id B4E3BAC6DC; Sun, 4 Dec 2011 14:59:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Stefan Bethke In-Reply-To: Date: Sun, 4 Dec 2011 14:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF1FBB8-2A6B-49E1-88ED-E46ED23DAD87@lassitu.de> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) 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: Sun, 04 Dec 2011 13:59:07 -0000 Am 04.12.2011 um 14:01 schrieb Adrian Chadd: > Well, the real question is whether the SPI CS pins are actually the > ones being used or not. I'll try and break CS1 and see what happens=85 > I'm pretty sure the SPI flash is actually being talked to via > bitbanged GPIO, rather than the actual ar71xx/ar91xx SPI interface. > So those chip selects aren't strictly needed. I couldn't tell. The register definitions in ar71xxreg.h seem to = indicate that there is hardware support for SPI, and that CS1 and CS2 = (but not CS0) share the pins with GPIO, but looking at the code in = ar71xx_spi.c seems to do bit banging for transmit and register read for = reception. Does the SPI support only have a shift register for = reception? > They may be needed for the mikrotik routerboard's though, I recall > gonzo@ talking about something like that. >=20 > I think we can just work around this by having a boot-time machine > dependent "function mask" hint which we set to define which on-board > peripherals are enabled. > It can be machdep rather than generic, as we'd likely set it up early > - eg, ar71xx_machdep.c::platform_start(). >=20 > The only downside which i haven't yet thought through is whether to: >=20 > * just write a raw value to the function register, which means we > would override whatever the bootloader revision says; or > * have two hints - one "clear these bits" and one "set these bits" in > the GPIO function register, so we can override what the bootloader > code does at startup. That way if it, for example, initialises the > sound pins, we don't have to know that unless we want to use the GPIO > pins shared by the sound interface. >=20 > How's that sound? Too dirty? :) Hhm. How about the ar71xx_spi.c driver claiming CS0 and optionally CS1 and = CS2 (again via hint?), and setting the GPIO function bits accordingly? = Or only activate CS1 and CS2 if we have SPI bus children that claim = them? Stefan --=20 Stefan Bethke Fon +49 151 14070811