Date: Mon, 5 Dec 2011 09:01:50 -0700 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? Message-ID: <9681BA0F-B8DE-479C-98B8-6DA702A489CA@bsdimp.com> In-Reply-To: <CAJ-Vmo=-b96x4nH3VLciWfw1GSZ5ArrA4OXddOdwwTH7PuPztA@mail.gmail.com> References: <A78C6CC2-A6C9-42CC-B128-871C34C201CD@lassitu.de> <2B6F6CAC-F4EF-4958-A435-579A69862AE5@bsdimp.com> <CAJ-Vmo=-b96x4nH3VLciWfw1GSZ5ArrA4OXddOdwwTH7PuPztA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 4, 2011, at 6:29 PM, Adrian Chadd wrote: > On 5 December 2011 01:19, Warner Losh <imp@bsdimp.com> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9681BA0F-B8DE-479C-98B8-6DA702A489CA>