Hi Mark, Thanks for your feedback! On Wed, Aug 19, 2009 at 9:00 PM, Mark Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Aug 19, 2009 at 08:25:28PM +0900, Kuninori Morimoto wrote: >> + /* enable FSI */ >> + gpio_request(GPIO_FN_FSIMCKB, NULL); >> + gpio_request(GPIO_FN_FSIMCKA, NULL); >> + gpio_request(GPIO_FN_FSIOASD, NULL); >> + gpio_request(GPIO_FN_FSIIABCK, NULL); >> + gpio_request(GPIO_FN_FSIIALRCK, NULL); >> + gpio_request(GPIO_FN_FSIOABCK, NULL); >> + gpio_request(GPIO_FN_FSIOALRCK, NULL); >> + gpio_request(GPIO_FN_CLKAUDIOAO, NULL); >> + gpio_request(GPIO_FN_FSIIBSD, NULL); >> + gpio_request(GPIO_FN_FSIOBSD, NULL); >> + gpio_request(GPIO_FN_FSIIBBCK, NULL); >> + gpio_request(GPIO_FN_FSIIBLRCK, NULL); >> + gpio_request(GPIO_FN_FSIOBBCK, NULL); >> + gpio_request(GPIO_FN_FSIOBLRCK, NULL); >> + gpio_request(GPIO_FN_CLKAUDIOBO, NULL); >> + gpio_request(GPIO_FN_FSIIASD, 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. Cheers, / magnus _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel