[alsa-devel] Separate dma driver for cpu_dais

[jassi brar]

On Thu, Feb 18, 2010 at 7:57 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Thu, Feb 18, 2010 at 07:32:22PM +0900, jassi brar wrote:
>> On Thu, Feb 18, 2010 at 6:52 PM, Mark Brown
>
>> > Where is the code you are talking about here?  This sounds like driver
>> > code...
>
>> Ahh... it's all messed up by that samsung.git link that Joonyoung Shim shared.
>> I assumed you had a look at that. The code just a quick workaround, so
>> I didn't put it up here
>> http://git.kernel.org/?p=linux/kernel/git/kki_ap/linux-2.6-samsung.git;a=commitdiff;h=e5858948bb2c534251b65a850caf197ae880ce1f
>
> His link was to the entire tree rather than a particular bit of code, a
> bit of a needle in the haystack thing going on there (especially since
> you have actually modified the core and for looking at stuff like that
> I'd generally drill down into the platform directory before looking at
> logs or code).
Actually my patches are at the top of 2.6.29 branch(the only one that
has relevant code).
 I wanted to start separate threads for each independent topics towards
implementing a) platform per dai_link, b) dai sharing among dai_links
and c) multi-device per card, but the thread veered off. Anyways...

> The bits of that patch that make active a reference counter look good at
> first glance, could you please pull them out and submit them?
Sure I can, though I think of a few more checks to place in the code.
Will submit tomorrow from workplace.

>  Like I
> said in reply to Joonyoung it's not immediately clear to me that the
> startup and shutdown calls should be suppressed since I'd expect that at
> least some drivers are going to want to know about multiple uses (for
> example, returning -EBUSY if someone tries to have too many things
> active at once).
IMO codecs should simply do as directed by the ASOC.
The multi-instance logic has better be at one place(soc-core.c) rather than
in each codec's driver.
For that reason I modified soc-core.c rather than my device's codec
and cpu driver.

> In general for a vendor BSP I'd strongly recommend against any changes
> in the core that don't get submitted to mainline - it's more of a
> maintinance burden and makes it harder for people to take the drivers
> and use them with other kernel versions if they don't notice the change.
As explained above, I thought I had a reason to do so.