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>,
"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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
WARNING: multiple messages have this Message-ID (diff)
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
WARNING: multiple messages have this Message-ID (diff)
From: Viorel Suman <viorel.suman@nxp.com>
To: "nicoleotsuka@gmail.com" <nicoleotsuka@gmail.com>
Cc: dl-linux-imx <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"timur@kernel.org" <timur@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Xiubo.Lee@gmail.com" <Xiubo.Lee@gmail.com>,
Fabio Estevam <fabio.estevam@nxp.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"tiwai@suse.com" <tiwai@suse.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
Daniel Baluta <daniel.baluta@nxp.com>,
"perex@perex.cz" <perex@perex.cz>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.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:56 UTC|newest]
Thread overview: 23+ 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
2018-12-26 17:24 ` Nicolin Chen
2018-12-26 17:24 ` Nicolin Chen
2019-01-03 15:56 ` Viorel Suman [this message]
2019-01-03 15:56 ` Viorel Suman
2019-01-03 15:56 ` Viorel Suman
2019-01-03 18:25 ` Rob Herring
2019-01-03 18:25 ` Rob Herring
2019-01-03 18:25 ` Rob Herring
2019-01-03 19:21 ` Viorel Suman
2019-01-03 19:21 ` Viorel Suman
2019-01-03 19:21 ` Viorel Suman
2019-01-03 20:03 ` Nicolin Chen
2019-01-03 20:03 ` Nicolin Chen
2019-01-04 8:52 ` Viorel Suman
2019-01-04 8:52 ` Viorel Suman
2019-01-04 8:52 ` Viorel Suman
2018-12-28 23:32 ` Rob Herring
2018-12-28 23:32 ` Rob Herring
2019-01-03 13:47 ` Viorel Suman
2019-01-03 13:47 ` Viorel Suman
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=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 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.