[alsa-devel] [PATCH 2/4] ASoC: DaVinci: Voice Codec Interface

[Mark Brown]

On Wed, Sep 23, 2009 at 10:09:57AM -0600, Miguel Aguilar wrote:
> Mark Brown wrote:

>> That'd stop you using both simultaneously but it shouldn't stop you
>> having both compiled into the kernel simultaneously.  Would it be
>> difficult to make the DMA driver do something like return -EBUSY if it
>> was started opened twice?

> [MA] But how I can tell the kernel to use one or the other one in 
> runtime?, and Why do we need to have both compiled at the same time? if 
> this is really needed What is the best way to that?

The kernel would just expose both devices to user space so the choice
would be down to the application layer.  This would give maximum
flexibility to systems, allowing them to chop and change at runtime if
they needed to for some reason (eg, using a lower quality but lower
power voice output for telephony style applications but a higer quality
higher power output for MP3 playback).  It'd also mean that for the EVM
the user would be able to use a single kernel image to evaluate both
outputs which makes life easier for things like distros.

The implementation I suggested above with returning EBUSY if the DMA is
already in use would probably work.

>> The name of the device should have no influence on the name of the clock
>> - the clock API should be able to 

> The problem is that clock name is the same as the device, by using 
> pdev->name, most of the drivers does it in this way.

The DaVinci API doesn't need that - you should be able to use a fixed
string (or even a null string) for the clock name and have the clock API
figure things out based on the struct device.  Look at how the ASP is
set up for an example.

>> I suspect that you do need a little MFD here, it sounds like all the
>> resources need to be allocated to a single device which can then dole
>> them out to the CODEC and DAI drivers.

> [MA] I haven't use MFD, can you bring me more details.

> Do you mean create just one device with the whole voice codec instead of 
> use vcif and cq0093 separately?

Sort of - see drivers/mfd for examples.  You have a device driver that
is instantiated by the platform and has all the resources allocated to
it.  It then manages allocating the resources to subdevices that do the
actual work and ensuring that the subdevices don't step on each other.

>
>>
>
>
> Thanks,
>
> Miguel Aguilar