[alsa-devel] [PATCH 4/7] Alchemy: DB1200 AC97+I2S audio support.
manuel.lauss at googlemail.com
Mon Jun 8 16:48:23 CEST 2009
[Removed linux-mips and Ralf from CC]
On Mon, Jun 8, 2009 at 3:45 PM, Mark
Brown<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Jun 08, 2009 at 03:11:39PM +0200, Manuel Lauss wrote:
>> All 3 drivers are now platform_devices -- and now I still have the
>> same problem as
>> before: I can't really share the whole struct resource; i need to allocate
>> a new resource struct, fill in the dma ids and register the dma device with it.
> It's not terribly clear from what you're saying but it *sounds* like for
> your platform the DMA driver should be essentially a library for the DAI
> driver, registered by the DAI driver when it probes. Otherwise could
> you please go into a bit more detail about what you mean when you say
> you need to "allocate a new resource struct..." and so on - when do you
> need to allocate the resource struct and why do you need to do this?
You are right in this case. It's time for me to reevaluate the architecture
of the au1x asoc drivers.
>> I can't shake the feeling that there's something wrong with the whole asoc
>> device model (and that asoc was designed with pxa2xx devices in mind which
>> have single audio units with fixed resources that the driver code can
>> hardcode inside it).
> Could you articulate what your concerns are here in more detail?
What annoys me most is the need to actually have the machine code file
in the first place. Or more precisely, the location of it. It should
where the rest of the board code lives.
The other thing is the "soc_audio" platform device itself. Instead of reg-
istering a platform device for soc audio, how about a function call to
setup an asoc device. Multiple calls create multiple alsa devices,
the argument describes the audio fabric.
> Please submit anyway but at some point someone is going to have to
> convert the driver - I'm intending to leave as long a transition period
> as I can but at some point it's going to block other enhancements.
I attached an untested patch (an addon to the patch which started this thread)
which does this. Please have a look and tell me if this is what
I'll run-test this on real hardware as soon as I get access to it again.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 21110 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20090608/82c55484/attachment-0001.dll
More information about the Alsa-devel