Hi Mark,
On Mon, Jun 8, 2009 at 12:20 PM, Mark
Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jun 08, 2009 at 11:43:41AM +0200, Manuel Lauss wrote:
>> On Mon, Jun 8, 2009 at 11:25 AM, Mark
>> Brown<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> > If this is going to go in during the merge window I'm happy for it to go
>> > in via the MIPS tree but otherwise I'd much rather it goes via ASoC in
>> > case API changes cause merge issues. I don't know what you prefer,
>> > Ralf?
>
>> I'd rather have it all go through the MIPS tree; this is the only patch of
>> 7 which touches files outside it, and it depends on another one to
>> apply cleanly.
>
> Well, like I say if it's going via MIPS I'd really prefer it to go in
> this merge window. If not then I'd expect that splitting out the
> architecture parts from the machine driver as I suggested ought to deal
> with the merge issues.
I'll split it in two: pure ASoC part and pure board part. Agreed?
>> I'd actually love to move this file to the actual board code, however due
>> to the way ASoC is organized this isn't at all possible. This is one of two
>> things I don't like about ASoC: the machine registration is extremely awkward
>> compared to other platform drivers. (the other being that ASoC doesn't
>> support multiple machines [i.e. I could actually run both AC97 and I2S
>> simultaneously one of my boards, as independent sound cards])
>
> I've got a board sitting on my desk here which has multiple sound
> systems. Unfortunately the architecture code for it is a bit of a
> shambles at this point so it's more trouble to work on the platform
> than it's worth at the minute.
Alchemy's can have up to 4 PSCs with variable base addresses and variable
functions. Currently, ASoC can't handle more than 1 AC97 codec (no idea
how to pass DAI private data to the ac97 callbacks), and I also don't see how
to handle for instance 2 I2S machines with a WM8731 attached to each
(i.e. how do I tell ASoC that wm8731 at bus0/0x1b belongs to machine A
and wm8731 at bus0/0x1c belongs to machine B?)
This isn't a problem with the DB1200, as AC97 and I2S are connected to
the same PSC, but the DB1550 and DB1300 do have independent AC97 and
I2S.
>> >> +static struct resource psc1_res[] = {
>
>> > If you conver the I2S driver to use the standard device probing model
>> > this could all me moved into the architecture code rather than placed in
>> > machine drivers.
>
>> Again, I'd love to, but can't: the AC97/I2S/DBDMA drivers extract base address
>> and DMA information from the platform device resource structure; however
>> I can't just copy the resource info from the this db1200_sound platform_driver
>> to the soc_audio platform driver because the driver core complains about
>> resource conflicts (two platform_devices sharing the same resources).
>> Unless I missed a flag which needs to be passed to the resource.flags member?
>
> If you move the selection of the switch position to the architecture
> code then it can arrange to register only the device that is in use in
> the current configuration. If the DMA and DAI drivers both need the
> same resources they can cooperate with each other - the system will only
> bring the card on-line once both the DMA and DAI driver are present.
I think you misuderstood me. Could you point out an in-kernel machine which
already implements what you suggested?
The AC97/I2S dai drivers (psc-ac97/psc-i2s) extract the base address of the PSC
they're supposed to drive from the platform_device passed via the probe()
callbacks, these in turn are called when a "soc_audio" platform device
is called.
I need to set either the ac97 or I2S platform data for soc_audio based on the
switch setting. I can't register a "db1200_audio" platform device in the board
code which in turn registers the "soc_audio" device and have them share
the PSC mmio/irq/dma resources.
Manuel Lauss
