Date: Sun, 4 Dec 2011 14:59:05 +0100 From: Stefan Bethke <stb@lassitu.de> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? Message-ID: <7FF1FBB8-2A6B-49E1-88ED-E46ED23DAD87@lassitu.de> In-Reply-To: <CAJ-Vmokf22zesjCeVBd4rq6GwYtHePAU9mx0WwP_UoMPj8XA4A@mail.gmail.com> References: <A78C6CC2-A6C9-42CC-B128-871C34C201CD@lassitu.de> <CAJ-Vmokf22zesjCeVBd4rq6GwYtHePAU9mx0WwP_UoMPj8XA4A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7FF1FBB8-2A6B-49E1-88ED-E46ED23DAD87>