[alsa-devel] [PATCH 4/7] Alchemy: DB1200 AC97+I2S audio support.

[Mark Brown]

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.

I don't understand the problem you're seeing here?  I don't see any
fundamental difference between the before and after pictures in terms of
what you're saying.  Note that there is no requirement that the DMA
driver be a separate device - it can be if you want but if you want to
make it part of the DAI driver that works too.  As I say, the DAI and
DMA drivers can peer into each other's implementations as much as they
like.  They're split up since on most CPUs the same DMA back end is used
by all the DAIs the CPU supports so there's normally some opportunity
for code sharing but they're never truly independent of each other.

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?

In the overwhelming majority of systems I've seen there are no resources
associated with the actual machine driver itself - all the resources are
for the DMA and DAI.

> Btw, the davinci-evm in asoc-git also registers mmio and dma from within
> the machine code.

Not in the davinci branch I pointed you at, there the drivers have been
converted to use the standard device model for this.  The old DaVinci
code you were looking at predates the ability to register things
separately.

> 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?

Previously I've heard a lot of people complaining (with reason) about
the fact that it didn't use the standard device model at all, especially
for the CODECs, but this is the first time I've ever heard any concerns
about the standard device model.  The problems you're mentioning with
hard coding things are problems which are for most people fixed by using
the standard device model and passing the resources for the DAIs up from
the architecture code using the standard mechanisms since it makes it
trivial to add or move new instances of the same IP block.

Doing this by putting everything into the machine drivers gets a bit
tricky once you have multiple DAIs in play on a single card since it
gets more error prone to tie the resources to the DAIs.

> To put an end to this thread:  I really don't want to change the machine code
> or dai drivers at this time, because I have the feeling that it's a few steps
> backwards.  If you don't agree with this then I'll leave the audio parts out of

It'd be really good to try to understand and address your concerns now
before we've been through the transition for more machines - the longer
it's left the harder it will be to change.  The drivers don't have to
change now, I just want to understand what your concerns are.

> the submission; I don't really care if it goes in or not, I just saw
> it as a nice
> sample machine driver for both AC97 and I2S on Alchemy.

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.