On Wed, Aug 19, 2009 at 11:02 PM, Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Aug 19, 2009 at 10:46:34PM +0900, Magnus Damm wrote: >> On Wed, Aug 19, 2009 at 9:00 PM, Mark >> Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > >> >> + gpio_request(GPIO_FN_FSIMCKA, NULL); > >> > Is this something that the FSI driver should do for itself? It looks >> > like there's no pin options here, just fixed functions for FSI A or B so >> > replicating per-board seems redundant. On the other hand, if it's >> > idiomatic for SH better keep it this way. > >> These GPIO_FN_ values are processor specific, sh7724 in this case. I >> suspect we will see the FSI block reused in future processors so >> keeping processor-specific bits out of the driver itself may be a good >> plan. Long term I'd be more than happy to pass along processors >> specific GPIOs to each driver, but at this point I don't know any >> clean and standard way to do that. > > Is it possible to build kernels for more than one processor? The way > the code looks that's not the case... At this point on SuperH we first select processor and then board(s) after that. So the kernel is configured to run on one specific processor model. But the FSI block may show up in other processors and the pinmux configuration will most likely be different at that point. We usually keep the pinmux configuration in the board setup code and the let the driver "just work" and never touch any GPIOs unless the driver comes with GPIO support. Does it make sense? =) / magnus _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
