[PATCH RFC 10/13] ASoC: kirkwood-t5325: add DAPM links between codec and cpu DAI

Russell King - ARM Linux linux at arm.linux.org.uk
Mon Aug 5 10:56:44 EDT 2013

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:
> > On Mon, Aug 05, 2013 at 12:27:33PM +0100, Mark Brown wrote:
> > > This doesn't look good - this is adding DAPM routes which should
> > > correspond to the DAI link that's already been configured.
> > No, you're wrong there:
> > CPU DAI:				Codec DAI
> > dma-playback	--->	i2sdo	--->	Playback
> > 		`-->	spdifdo -> not connected
> > dma-capture	<---	i2sdi	<---	Capture
> > 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.
> > 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.

More information about the linux-arm-kernel mailing list