[alsa-devel] [PATCH 3/3] Add FSI-AK464x sound support for ms7724se
magnus.damm at gmail.com
Wed Aug 19 16:18:13 CEST 2009
On Wed, Aug 19, 2009 at 11:02 PM, Mark
Brown<broonie at opensource.wolfsonmicro.com> 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 at opensource.wolfsonmicro.com> 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? =)
More information about the Alsa-devel