From: Viorel Suman <viorel.suman@nxp.com>
To: "nicoleotsuka@gmail.com" <nicoleotsuka@gmail.com>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"timur@kernel.org" <timur@kernel.org>,
"Xiubo.Lee@gmail.com" <Xiubo.Lee@gmail.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Daniel Baluta <daniel.baluta@nxp.com>,
"tiwai@suse.com" <tiwai@suse.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
Fabio Estevam <fabio.estevam@nxp.com>,
"perex@perex.cz" <perex@perex.cz>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC PATCH] ASoC: fsl: Add Audio Mixer CPU DAI driver
Date: Thu, 3 Jan 2019 15:56:46 +0000 [thread overview]
Message-ID: <1546531006.14398.83.camel@nxp.com> (raw)
In-Reply-To: <CAGoOwPQvc5w05NOVsp6Qw-Ee3CJJCcaU2Dtzwbf+7bUe_kFEbA@mail.gmail.com>
Hi Nicolin,
Thank you for your feedback, same here - just back from vacation.
On Jo, 2018-12-27 at 01:24 +0800, Nicolin Chen wrote:
> Hi Viorel,
>
> Sorry for the late response, having been on a long vacation.
>
> The code looks pretty clean. Just some small concerns/questions
> below.
>
> On Wed, Dec 19, 2018 at 12:30 AM Viorel Suman <viorel.suman@nxp.com>
> wrote:
> >
> >
> > This patch implements Audio Mixer CPU DAI driver for NXP iMX8 SOCs.
> > The Audio Mixer is a on-chip functional module that allows mixing
> > of
> > two audio streams into a single audio stream.
> >
> > Audio Mixer datasheet is available here:
> > https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
> >
> > Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
> > ---
> > .../devicetree/bindings/sound/fsl,amix.txt | 45 ++
> > sound/soc/fsl/Kconfig | 7 +
> > sound/soc/fsl/Makefile | 3 +
> > sound/soc/fsl/fsl_amix.c | 554
> > +++++++++++++++++++++
> > sound/soc/fsl/fsl_amix.h | 101 ++++
> I aimn't against the naming here, but it seems to be AUDMIX in RM?
>
> Would it be better to align with that? It's your decision though.
To me "AUDMIX" sounds more like some RTL high level integration module,
I would prefer to keep it as it is if there is no strong reason to
rename it.
>
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl,amix.txt
> > b/Documentation/devicetree/bindings/sound/fsl,amix.txt
> > +=================================
> > + - compatible : Compatible list, contains "fsl,imx8qm-
> > amix"
> > +
> > + - reg : Offset and length of the register
> > set for the device.
> > +
> > + - clocks : Must contain an entry for each entry in
> > clock-names.
> > +
> > + - clock-names : Must include the "ipg" for
> > register access.
> > +
> > + - power-domains : Must contain the phandle to the AMIX
> > power domain node
> > +
> > +Device driver configuration example:
> > +======================================
> > + amix: amix@59840000 {
> > + compatible = "fsl,imx8qm-amix";
> > + reg = <0x0 0x59840000 0x0 0x10000>;
> > + clocks = <&clk IMX8QXP_AUD_AMIX_IPG>;
> > + clock-names = "ipg";
> > + power-domains = <&pd_amix>;
> > + };
> From the description of DT and RM, I don't see how it connects to
> SAIs.
>
> Are they fixed to SAI0 and SAI1 in imx8qm? Wondering if it'd be
> better to have such information in the doc.
Please check chapter "16.1.2.2 Audio Mixer" in RM: it has two dedicated
SAI interfaces, SAI4 and SAI5. Audio Mixer operates on bit clock of one
of these interfaces.
>
> >
> > diff --git a/sound/soc/fsl/fsl_amix.c b/sound/soc/fsl/fsl_amix.c
> +static const char
> + *width_sel[] = { "16b", "18b", "20b", "24b", "32b", },
> + *pol_sel[] = { "Positive edge", "Negative edge", },
> [...]
> +static const struct soc_enum fsl_amix_enum[] = {
> +/* FSL_AMIX_CTR enums */
> [...]
> +SOC_ENUM_SINGLE_S(FSL_AMIX_CTR, FSL_AMIX_CTR_OUTWIDTH_SHIFT,
> width_sel),
> +SOC_ENUM_SINGLE_S(FSL_AMIX_CTR, FSL_AMIX_CTR_OUTCKPOL_SHIFT,
> pol_sel),
>
> Should we handle the width in hw_param()?
The width of AMIX output (mixed) stream may be different than the width
of the input streams, the assumption is that the user may want to
control it from userspace.
>
> Why do we change pol here? It feels like against set_fmt().
You're right, will remove it in the next version.
>
> >
> > +static int fsl_amix_dai_set_fmt(struct snd_soc_dai *dai, unsigned
> > int fmt)
> > +{
> > + /* For playback the AMIX is slave, and for record is master
> > */
> > + switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
> > + case SND_SOC_DAIFMT_CBM_CFM:
> > + case SND_SOC_DAIFMT_CBS_CFS:
> So it's used either for playback or capture only, not both at same
> time?
From IP functional perspective AMIX capture is the result of AMIX
playback - AMIX output represents the resulting mixed audio stream
routed to SAI4 RX signals (bit & frame clocks and data). So once we
have playback on either SAI4 or SAI5 (or both) - we can capture the
AMIX output on SAI4.
I guess it would be nice to send the machine driver as part of this
patchset also - it defines two input SAI interfaces as frontends and
AMIX - as backend. Userspace sees only two SAI interfaces exposed, both
of them having playback enabled, and only SAI4 having capture enabled.
>
> Thanks
> Nicolin
Thank you,
Viorel
next prev parent reply other threads:[~2019-01-03 15:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 16:30 [RFC PATCH] ASoC: fsl: Add Audio Mixer CPU DAI driver Viorel Suman
2018-12-26 17:24 ` Nicolin Chen
2019-01-03 15:56 ` Viorel Suman [this message]
2019-01-03 18:25 ` Rob Herring
2019-01-03 19:21 ` Viorel Suman
2019-01-03 20:03 ` Nicolin Chen
2019-01-04 8:52 ` Viorel Suman
2018-12-28 23:32 ` Rob Herring
2019-01-03 13:47 ` Viorel Suman
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=1546531006.14398.83.camel@nxp.com \
--to=viorel.suman@nxp.com \
--cc=Xiubo.Lee@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=daniel.baluta@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=lgirdwood@gmail.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=nicoleotsuka@gmail.com \
--cc=perex@perex.cz \
--cc=robh+dt@kernel.org \
--cc=timur@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).