Re: ASoC: Dynamic CODEC DAI

[Patrick Lai <plai@codeaurora.org>]

On 11/29/2011 5:49 AM, Mark Brown wrote:
> On Mon, Nov 28, 2011 at 04:49:18PM -0800, Patrick Lai wrote:
>
>> In CODEC driver, I will declare codec dai for each port.
>> Then, I will enhance ASoC framework to take a list of CODEC DAIs and
>> pass list of CODEC DAIs back to callback function such as startup,
>> hw_param, prepare, trigger. I believe this approach will not require
>> massive amount of change to framework.
>
> The above is really vauge so it's hard to comment in any detail.
The thing is that in order for DAPM to figure out which path to enable,
AIF_IN and AIF_OUT widgets must be associated with stream name(e.g HiFi
  Playback) as part of CODEC DAI definition. Now, with the grouping
requirement, CODEC DAI definition with fixed number of channels will
not work as interconnect table defined in the CODEC driver establishes
relationship of AIF pins and codec dai stream name which now would have
to be machine base. Another approach would be having machine driver
define AIF pins, interconnect table and CODEC DAIs for CODEC driver. I
would think this approach would bear too much burden on the machine
driver developer. Instead, each slimbus port on the CODEC, by
definition, is a mono CODEC DAI. Extending DAI link definition to take
a list of CODEC dais allows machine driver to group the ports. Passing
back the CODEC DAI list to CODEC driver allows CODEC driver know which 
slimbus ports are associated with given pcm stream. As on the CPU side,
instead of burdening CPU driver from knowing what ports and enumeration
address of CODEC, we have concept of shared data channel IDs. So, both
CODEC driver and CPU driver communicate to SLIMBUS driver to set up
data channels using the channel ID. CPU and CODEC independently can
setup their own SLIMBUS ports. Machine driver assigns channel ID to
both CPU and CODEC drivers.

  I'm
> not sure it's worth trying to be too non-invasive, anything controlling
> hardware is going to have to understand what's going on at the physical
> level anyway and the host side is going to have to interoperate with the's
> Slimbus framework.  The core is also going to need to know about the
> channel groups to allocate and destroy them as required.
I presume you are referring to soc-core, with the approach I propose
above, I think soc-core does not have to be aware of SLIMBUS framework.
On the other hand, my approach will not be able to utilize run-time
grouping ability offered by SLIMBUS as ports are pre-assigned at
compile time. So, However, we are talking about drastic change. with
SLIMBUS, we can run-time create new pcm device as long as there are
enough SLIMBUS ports ignoring the fact that ports on my CODEC cannot
connect to all mic inputs. Entire framework built on static number of
pcm devices please correct me if I am wrong.


  It seems like
> being more explicit might be easier.
>
> Also note that the work on submitting your Silmbus driver core to
> mainline appears totally stalled, there was just an initial posting but
> no followup.
I guess slimbus driver guy is completely swamped now as SLIMBUS is new
and it takes a lot of effort to stablize.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.