On Sun, Sep 01, 2013 at 12:51:16PM +0100, Mark Brown wrote:
Like Lars-Peter says it really, really shouldn't be - what moving to DPCM should be doing with this code is mostly moving the code around a bit to pull the bits that are shared into a front end DAI. The most substantial change should be handling the enables but that shouldn't take much code at all, your curent patch does it in 35 lines and I'd not expect it to be much different in a DPCM world.
The delta between the DPCM version and the dual-DAI version is over 300 lines of change - the methods employed by these two methods are completely different.
Maybe you could look at the patch and suggest where I'm going wrong?
On Sun, Sep 01, 2013 at 09:51:21AM +0100, Russell King - ARM Linux wrote:
Can you then please explain why when I ask for help understanding DAPM in a "nice" way, the response I get is just "it's just a graph walk" and no further technical details?
Ask more detailed questions and engage in a discussion; the reason you keep on getting the same responses is that you tend to repeat the same requests a lot. Something like "I understand the big picture but I am trying to do X and need to know Y because Z" (with all of X, Y and Z being important) is usually a good approach.
When you don't even understand the "big picture", it's hard to know where to start. That's why starting off with a simple question is the right thing to do - and you expect to get a simple but informative response, so that helps you to frame more specific questions later.
If you start from a position of knowing very little, it's exceedingly difficult to ask specific questions.
The public interface for DAPM is that the widgets get created with sensible types and hooked up together then powered up as needed, if something needs to know specifics of that process like exactly when a given register will be written that's a worrying implementation detail.
| DAPM is a set of "widgets" representing various components of an | audio system. The widgets are linked together by a graph. Each | widget lives in a context - cpu, platform or codec. Some bindings | only happen within a context, others cross contexts (so linking the | CPU audio stream to the codec for example)
This last statement is not the case; you can see the route connecting code in snd_soc_dapm_add_route() - there is no case in which it will only try to match within a single context.
As I have said to you without more information it is hard to tell what problems you are seeing when you are trying this. It could be a case of trying to create routes before the widgets are added, or it could be a case of trying to create inter device links with widgets with globally duplicated names (though that would give wrong routes rather than no routes so I suspect sequencing).
Right, so, I have a widget with a stream name, and the stream name matches a CPU DAI stream.
If I register this widget against the platform DAPM context, then there is no connection between this widget and the CPU DAI streams. (Bear in mind that at the time I tried this, I had disabled the creation of the stream widgets that were overwriting the platform stream widgets - because you were not providing any useful information to work around that problem.)
If I register this widget against the CPU DAI DAPM context, the stream name is matched to the CPU DAI streams, and a connection is made between the stream widgets and my widget.
This is what I mean by "some bindings only happen within a context".