From: Tony Lindgren <tony@atomide.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
linux-kernel@vger.kernel.org, Merlijn Wajer <merlijn@wizzup.org>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Sebastian Reichel <sre@kernel.org>,
"Arthur D ." <spinal.by@gmail.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
Date: Thu, 20 Feb 2020 12:13:38 -0800 [thread overview]
Message-ID: <20200220201338.GW37466@atomide.com> (raw)
In-Reply-To: <40a803e2-6a08-2c73-0312-666441716daa@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:08]:
> On 18/02/2020 17.28, Tony Lindgren wrote:
> > Right. I'm not attached to the dummy dai, but looks like currently
> > snd-soc-audio-graph-card won't work without it.
>
> The generic cards will link up a dummy dai/codec when it is needed by DPMC.
Not sure what should be fixed here..
> > And we potentially
> > do need a place to configure TDM slot specific stuff for mcbsp.
>
> Yes, but you still have one port and one endpoint should not change the
> configuration which is already in used for the other endpoint.
OK so what's the fix for snd-soc-audio-graph-card expecting a
separate DAI then?
> > Oh, I think there are Android apps to do that though.. Never tried
> > if they work on droid4. But if they do, doing a register dump of
> > mcbsp3 would show up how it's configured.
>
> I don't see how you could record the data from the line which is
> connected to McBSP_DX pin (the pin is output).
>
> But I might be missing something.
Yeah I don't know either, but the pins we have muxed for
mcbsp3 are:
/* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */
OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)
/* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */
OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)
/* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */
OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)
/* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */
OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)
Isn't the data receive there as mcbsp3_dr?
> > I think the link for the patches you posted is patching the
> > snd-soc-audio-graph-card already?
>
> Yes it does, but the functionality is there via custom machine drivers.
> What I afraid is that such a complex wiring as the Droid4 have it might
> be not possible to use a generic - fits everything - driver without
> making it a customized one ;)
>
> Otho, if the only thing is the machine level DAPM switching and linking
> the paths then it might be relatively straight forward to extend the
> simple-card family.
Yeah or maybe it just needs to be handled directly in the cpcap,
mdm6600 codec drivers?
> > Right. So right now it seems that for snd-soc-audio-graph-card
> > needs the dummy dai, but it's unclear what would need to be
> > changed to not use a dummy dai for mcbsp.
>
> Since simple-card family can and will connect up dummy dai/codec when
> needed based on the setup, I would look at that and make it do so.
Oh so make simple-card spin up the dummy dai instead of mcbsp?
> > The dts snippets I posted earlier do follow the graph bindings
> > as far as I know. But just to confirm, do you see any need to
> > move things around there?
>
> It also states that a port is a physical port which can have multiple
> endpoints. But multiple endpoint != DAI. port == dai.
I guess I'm getting really confused now.. Are you saying
the dts needs to be changed too now?
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Aaro Koskinen <aaro.koskinen@iki.fi>,
"Arthur D ." <spinal.by@gmail.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>,
Merlijn Wajer <merlijn@wizzup.org>, Pavel Machek <pavel@ucw.cz>,
Sebastian Reichel <sre@kernel.org>
Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
Date: Thu, 20 Feb 2020 12:13:38 -0800 [thread overview]
Message-ID: <20200220201338.GW37466@atomide.com> (raw)
In-Reply-To: <40a803e2-6a08-2c73-0312-666441716daa@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:08]:
> On 18/02/2020 17.28, Tony Lindgren wrote:
> > Right. I'm not attached to the dummy dai, but looks like currently
> > snd-soc-audio-graph-card won't work without it.
>
> The generic cards will link up a dummy dai/codec when it is needed by DPMC.
Not sure what should be fixed here..
> > And we potentially
> > do need a place to configure TDM slot specific stuff for mcbsp.
>
> Yes, but you still have one port and one endpoint should not change the
> configuration which is already in used for the other endpoint.
OK so what's the fix for snd-soc-audio-graph-card expecting a
separate DAI then?
> > Oh, I think there are Android apps to do that though.. Never tried
> > if they work on droid4. But if they do, doing a register dump of
> > mcbsp3 would show up how it's configured.
>
> I don't see how you could record the data from the line which is
> connected to McBSP_DX pin (the pin is output).
>
> But I might be missing something.
Yeah I don't know either, but the pins we have muxed for
mcbsp3 are:
/* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */
OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)
/* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */
OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)
/* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */
OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)
/* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */
OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)
Isn't the data receive there as mcbsp3_dr?
> > I think the link for the patches you posted is patching the
> > snd-soc-audio-graph-card already?
>
> Yes it does, but the functionality is there via custom machine drivers.
> What I afraid is that such a complex wiring as the Droid4 have it might
> be not possible to use a generic - fits everything - driver without
> making it a customized one ;)
>
> Otho, if the only thing is the machine level DAPM switching and linking
> the paths then it might be relatively straight forward to extend the
> simple-card family.
Yeah or maybe it just needs to be handled directly in the cpcap,
mdm6600 codec drivers?
> > Right. So right now it seems that for snd-soc-audio-graph-card
> > needs the dummy dai, but it's unclear what would need to be
> > changed to not use a dummy dai for mcbsp.
>
> Since simple-card family can and will connect up dummy dai/codec when
> needed based on the setup, I would look at that and make it do so.
Oh so make simple-card spin up the dummy dai instead of mcbsp?
> > The dts snippets I posted earlier do follow the graph bindings
> > as far as I know. But just to confirm, do you see any need to
> > move things around there?
>
> It also states that a port is a physical port which can have multiple
> endpoints. But multiple endpoint != DAI. port == dai.
I guess I'm getting really confused now.. Are you saying
the dts needs to be changed too now?
Regards,
Tony
next prev parent reply other threads:[~2020-02-20 20:14 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 17:16 [alsa-devel] [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card Tony Lindgren
2020-02-11 17:16 ` Tony Lindgren
2020-02-12 8:02 ` [alsa-devel] " Peter Ujfalusi
2020-02-12 8:02 ` Peter Ujfalusi
2020-02-12 8:02 ` Peter Ujfalusi
2020-02-12 14:35 ` [alsa-devel] " Tony Lindgren
2020-02-12 14:35 ` Tony Lindgren
2020-02-14 0:34 ` [alsa-devel] " Sebastian Reichel
2020-02-14 0:34 ` Sebastian Reichel
2020-02-14 1:34 ` [alsa-devel] " Tony Lindgren
2020-02-14 1:34 ` Tony Lindgren
2020-02-14 13:04 ` [alsa-devel] " Sebastian Reichel
2020-02-14 13:04 ` Sebastian Reichel
2020-02-14 17:09 ` [alsa-devel] " Tony Lindgren
2020-02-14 17:09 ` Tony Lindgren
2020-02-18 14:04 ` Sebastian Reichel
2020-02-18 14:04 ` Sebastian Reichel
2020-02-18 14:19 ` Tony Lindgren
2020-02-18 14:19 ` Tony Lindgren
2020-02-18 16:35 ` Sebastian Reichel
2020-02-18 16:35 ` Sebastian Reichel
2020-02-14 12:41 ` [alsa-devel] " Peter Ujfalusi
2020-02-14 12:41 ` Peter Ujfalusi
2020-02-14 12:49 ` [alsa-devel] " Mark Brown
2020-02-14 12:49 ` Mark Brown
2020-02-14 17:05 ` [alsa-devel] " Tony Lindgren
2020-02-14 17:05 ` Tony Lindgren
2020-02-14 20:05 ` [alsa-devel] " Mark Brown
2020-02-14 20:05 ` Mark Brown
2020-02-14 17:03 ` [alsa-devel] " Tony Lindgren
2020-02-14 17:03 ` Tony Lindgren
2020-02-17 1:38 ` [alsa-devel] " Kuninori Morimoto
2020-02-17 1:38 ` Kuninori Morimoto
2020-02-17 5:25 ` [alsa-devel] " Kuninori Morimoto
2020-02-17 5:25 ` Kuninori Morimoto
2020-02-17 12:09 ` [alsa-devel] " Peter Ujfalusi
2020-02-17 12:09 ` Peter Ujfalusi
2020-02-17 23:10 ` Tony Lindgren
2020-02-17 23:10 ` Tony Lindgren
2020-02-17 23:36 ` Tony Lindgren
2020-02-17 23:36 ` Tony Lindgren
2020-02-18 15:26 ` Peter Ujfalusi
2020-02-18 15:26 ` Peter Ujfalusi
2020-02-18 15:34 ` Tony Lindgren
2020-02-18 15:34 ` Tony Lindgren
2020-02-18 12:43 ` Peter Ujfalusi
2020-02-18 12:43 ` Peter Ujfalusi
2020-02-18 15:28 ` Tony Lindgren
2020-02-18 15:28 ` Tony Lindgren
2020-02-20 14:07 ` Peter Ujfalusi
2020-02-20 14:07 ` Peter Ujfalusi
2020-02-20 20:13 ` Tony Lindgren [this message]
2020-02-20 20:13 ` Tony Lindgren
2020-02-21 14:07 ` Peter Ujfalusi
2020-02-21 14:07 ` Peter Ujfalusi
2020-02-18 21:16 ` Sebastian Reichel
2020-02-18 21:16 ` Sebastian Reichel
2020-02-20 14:15 ` Peter Ujfalusi
2020-02-20 14:15 ` Peter Ujfalusi
2020-02-20 20:15 ` Tony Lindgren
2020-02-20 20:15 ` Tony Lindgren
2020-02-21 13:20 ` Peter Ujfalusi
2020-02-21 13:20 ` Peter Ujfalusi
2020-02-21 18:08 ` Tony Lindgren
2020-02-21 18:08 ` Tony Lindgren
2020-02-20 20:47 ` Sebastian Reichel
2020-02-20 20:47 ` Sebastian Reichel
-- strict thread matches above, loose matches on Subject: below --
2021-01-24 9:27 Pavel Machek
2021-01-25 11:43 ` Péter Ujfalusi
2021-01-28 6:35 ` Tony Lindgren
2021-01-28 6:35 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200220201338.GW37466@atomide.com \
--to=tony@atomide.com \
--cc=aaro.koskinen@iki.fi \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jarkko.nikula@bitmer.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=pavel@ucw.cz \
--cc=peter.ujfalusi@ti.com \
--cc=spinal.by@gmail.com \
--cc=sre@kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.