[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200214200537.GR4827@sirena.org.uk>
Date: Fri, 14 Feb 2020 20:05:37 +0000
From: Mark Brown <broonie@...nel.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
Aaro Koskinen <aaro.koskinen@....fi>,
"Arthur D ." <spinal.by@...il.com>,
Jarkko Nikula <jarkko.nikula@...mer.com>,
Merlijn Wajer <merlijn@...zup.org>,
Pavel Machek <pavel@....cz>, Sebastian Reichel <sre@...nel.org>
Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio
graph card
On Fri, Feb 14, 2020 at 09:05:59AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@...nel.org> [200214 12:50]:
> > We really shouldn't need dummy DAIs at all I think, if we do it feels
> > like there's a problem. It's quite possible that there is actually a
> > problem here though...
> It's dummy in the droid4 voice call case as mcbsp is not the clock-master
> and there's nothing to configure for mcbsp.
If the McBSP is doing anything at all it should still be properly
represented with the actual device rather than a dummy otherwise we'll
most likely get confused at some point. If it's not doing anything then
we shouldn't even need the dummy. But perhaps I'm confused about this
particular system, I remember some of the OMAP designs were a bit fun.
> But I guess in some cases mcbsp could be the clock-master and then the
> secondary DAI would have ops.
It'd be a bit of an unusual clock design for a phone but yeah.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists