Date: Sun, 4 Dec 2011 21:01:32 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Stefan Bethke <stb@lassitu.de> Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? Message-ID: <CAJ-Vmokf22zesjCeVBd4rq6GwYtHePAU9mx0WwP_UoMPj8XA4A@mail.gmail.com> In-Reply-To: <A78C6CC2-A6C9-42CC-B128-871C34C201CD@lassitu.de> References: <A78C6CC2-A6C9-42CC-B128-871C34C201CD@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, the real question is whether the SPI CS pins are actually the ones being used or not. 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. They may be needed for the mikrotik routerboard's though, I recall gonzo@ talking about something like that. 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(). The only downside which i haven't yet thought through is whether to: * 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. How's that sound? Too dirty? :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokf22zesjCeVBd4rq6GwYtHePAU9mx0WwP_UoMPj8XA4A>