On Mon, Aug 05, 2013 at 03:40:54PM +0100, Mark Brown wrote:

On Mon, Aug 05, 2013 at 12:33:10PM +0100, Russell King - ARM Linux wrote:

quoted

On Mon, Aug 05, 2013 at 12:27:33PM +0100, Mark Brown wrote:

quoted

quoted

This doesn't look good - this is adding DAPM routes which should
correspond to the DAI link that's already been configured.

quoted

No, you're wrong there:

quoted

CPU DAI:				Codec DAI
dma-playback	--->	i2sdo	--->	Playback
		`-->	spdifdo -> not connected
dma-capture	<---	i2sdi	<---	Capture

quoted

And the intermediate level is needed to determine which outputs from
the chip are wired up.

Right, and that's exactly what the dai_links are doing - they're showing
what's hanging off each of the DAIs.

quoted

And don't even say "use dpcm" - if you say that, I want _you_ to write
it because dpcm is totally and utterly unusable as it currently stands -
as you can see from all the emails I've sent over the weekend.

I'm going to tell you to work with the framework rather than around it;

Work with the fscking undocumented framework.  If you want that, then
sodding well document this pile of crap.  If not, stop telling people
to "work around it".

adding routes that link the CODEC and CPU together in parallel with the
links set up for the DAIs is not something that seems like it's going to
continue to work sensibly going forwards.

So you're *TOTALLY* missing why I've had to do that.  Tell me, how can
the CPU DAI detect which of its frigging outputs are connected to the
codec without doing the above?  Show me how your crappy subsystem is
supposed to work.  Document the sodding thing.

If you don't do this, don't expect people to understand it.  Don't
expect people not to find "other solutions" around the utter shite that
I've had to deal with ALL FRIGGING WEEKEND.

These patches stay as they are until you get a clue about what's required
to drive this hardware and start providing some sensible assistance with
your undocumented code.