Date: Mon, 5 Dec 2011 09:29:41 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? Message-ID: <CAJ-Vmo=-b96x4nH3VLciWfw1GSZ5ArrA4OXddOdwwTH7PuPztA@mail.gmail.com> In-Reply-To: <2B6F6CAC-F4EF-4958-A435-579A69862AE5@bsdimp.com> References: <A78C6CC2-A6C9-42CC-B128-871C34C201CD@lassitu.de> <2B6F6CAC-F4EF-4958-A435-579A69862AE5@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 December 2011 01:19, Warner Losh <imp@bsdimp.com> wrote: > When I was looking into this question for the Atmel chips, I was torn. = =A0On the one hand, it would be nice if there was a pin mux device. =A0On t= he other hand, it didn't map well into the device model. =A0I finally settl= ed on having per-board functions that setup the pins. =A0This is also the m= odel followed by linux. =A0Either the boot loader or the board-dependent co= de would do the setup. I think we should have a per-board set of hints which lets us dictate non-default GPIO functions and config. That way we can override what's going on in the board config without having to write C code. As i said, something like this: hint.blah.gpiofunction_set=3D"0x10000000" hint.blah.gpiofunction_clear=3D"0x00130000" 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. 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. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=-b96x4nH3VLciWfw1GSZ5ArrA4OXddOdwwTH7PuPztA>