Hi Mark,
Thanks for your feedback!
On Wed, Aug 19, 2009 at 9:00 PM, Mark Brownbroonie@opensource.wolfsonmicro.com 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