All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viorel Suman <viorel.suman@nxp.com>
To: "robh@kernel.org" <robh@kernel.org>,
	"nicoleotsuka@gmail.com" <nicoleotsuka@gmail.com>
Cc: dl-linux-imx <linux-imx@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Cosmin Samoila <cosmin.samoila@nxp.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"timur@kernel.org" <timur@kernel.org>,
	"viorel.suman@gmail.com" <viorel.suman@gmail.com>,
	"Xiubo.Lee@gmail.com" <Xiubo.Lee@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	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>,
	"S.j. Wang" <shengjiu.wang@nxp.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: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
Date: Tue, 22 Jan 2019 11:39:39 +0000	[thread overview]
Message-ID: <1548157178.13051.19.camel@nxp.com> (raw)
In-Reply-To: <20190121152335.GA12284@bogus>

Hi Rob,

On Lu, 2019-01-21 at 09:23 -0600, Rob Herring wrote:
> On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote:
> > 
> > On Fri, Jan 18, 2019 at 01:16:24PM +0000, Viorel Suman wrote:
> > > 
> > > > 
> > > > > 
> > > > > 1. Moved "dais" node from machine driver DTS node to device
> > > > > driver
> > > > > DTS node
> > > > >   as suggested by Rob.
> > > > That was not what I suggested. You still have a virtual node
> > > > which
> > > > looks to me to be unnecessary.
> > > To me removing virtual node implies that AUDMIX machine driver
> > > (imx-
> > > audmix.c + virtual node) shall be removed and machine driver code
> > > merged into device driver (fsl_audmix.c + device node) - please
> > > let me
> > > know if my understanding is wrong.
> > We could use a non-DT configuration right? From the driver logic,
> > DT just registers a device corresponding to the machine driver so
> > that it can probe(). We could register one in fsl_audmix instead.
> > Please refer to how fsl_ssi registers the sound card device. The
> > machine driver can get audmix_np from the parent device pointer,
> > and I think that's all you need.
> Yes.

Thank you, sent V4 which implements the approach suggested by Nicolin.

> 
> > 
> > Or maybe someone else would provide a better way. But it'd work.
> Or the machine driver could create the audmix device. That probably 
> makes less sense, but either way there doesn't have to be a 1-1 
> correspondence of DT nodes and (platform) devices.
> 
> I'm not an ASoC expert, but why can't the machine driver just control
> the audmix directly (with DAIs as separate drivers)? Is the audmix
> ever going to a be a component for a different machine driver?
> 
> Rob

Currently I'm not aware of any information with regard to if audmix is
ever going to work with other DAIs than SAI. Howerver from audmix IP
block integration perspective the only requirement is that the input
DAI must be connected to audmix over I2S bus, possible DAI options are
SAI, ESAI, etc - I think the approach to mix both device and machine
drivers into a single entity is not the best way to go.

/Viorel

WARNING: multiple messages have this Message-ID (diff)
From: Viorel Suman <viorel.suman@nxp.com>
To: "robh@kernel.org" <robh@kernel.org>,
	"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>,
	"S.j. Wang" <shengjiu.wang@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"viorel.suman@gmail.com" <viorel.suman@gmail.com>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	Cosmin Samoila <cosmin.samoila@nxp.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
Date: Tue, 22 Jan 2019 11:39:39 +0000	[thread overview]
Message-ID: <1548157178.13051.19.camel@nxp.com> (raw)
In-Reply-To: <20190121152335.GA12284@bogus>

Hi Rob,

On Lu, 2019-01-21 at 09:23 -0600, Rob Herring wrote:
> On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote:
> > 
> > On Fri, Jan 18, 2019 at 01:16:24PM +0000, Viorel Suman wrote:
> > > 
> > > > 
> > > > > 
> > > > > 1. Moved "dais" node from machine driver DTS node to device
> > > > > driver
> > > > > DTS node
> > > > >   as suggested by Rob.
> > > > That was not what I suggested. You still have a virtual node
> > > > which
> > > > looks to me to be unnecessary.
> > > To me removing virtual node implies that AUDMIX machine driver
> > > (imx-
> > > audmix.c + virtual node) shall be removed and machine driver code
> > > merged into device driver (fsl_audmix.c + device node) - please
> > > let me
> > > know if my understanding is wrong.
> > We could use a non-DT configuration right? From the driver logic,
> > DT just registers a device corresponding to the machine driver so
> > that it can probe(). We could register one in fsl_audmix instead.
> > Please refer to how fsl_ssi registers the sound card device. The
> > machine driver can get audmix_np from the parent device pointer,
> > and I think that's all you need.
> Yes.

Thank you, sent V4 which implements the approach suggested by Nicolin.

> 
> > 
> > Or maybe someone else would provide a better way. But it'd work.
> Or the machine driver could create the audmix device. That probably 
> makes less sense, but either way there doesn't have to be a 1-1 
> correspondence of DT nodes and (platform) devices.
> 
> I'm not an ASoC expert, but why can't the machine driver just control
> the audmix directly (with DAIs as separate drivers)? Is the audmix
> ever going to a be a component for a different machine driver?
> 
> Rob

Currently I'm not aware of any information with regard to if audmix is
ever going to work with other DAIs than SAI. Howerver from audmix IP
block integration perspective the only requirement is that the input
DAI must be connected to audmix over I2S bus, possible DAI options are
SAI, ESAI, etc - I think the approach to mix both device and machine
drivers into a single entity is not the best way to go.

/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: "robh@kernel.org" <robh@kernel.org>,
	"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>,
	"S.j. Wang" <shengjiu.wang@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"viorel.suman@gmail.com" <viorel.suman@gmail.com>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	Cosmin Samoila <cosmin.samoila@nxp.com>,
	"perex@perex.cz" <perex@perex.cz>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers
Date: Tue, 22 Jan 2019 11:39:39 +0000	[thread overview]
Message-ID: <1548157178.13051.19.camel@nxp.com> (raw)
In-Reply-To: <20190121152335.GA12284@bogus>

Hi Rob,

On Lu, 2019-01-21 at 09:23 -0600, Rob Herring wrote:
> On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote:
> > 
> > On Fri, Jan 18, 2019 at 01:16:24PM +0000, Viorel Suman wrote:
> > > 
> > > > 
> > > > > 
> > > > > 1. Moved "dais" node from machine driver DTS node to device
> > > > > driver
> > > > > DTS node
> > > > >   as suggested by Rob.
> > > > That was not what I suggested. You still have a virtual node
> > > > which
> > > > looks to me to be unnecessary.
> > > To me removing virtual node implies that AUDMIX machine driver
> > > (imx-
> > > audmix.c + virtual node) shall be removed and machine driver code
> > > merged into device driver (fsl_audmix.c + device node) - please
> > > let me
> > > know if my understanding is wrong.
> > We could use a non-DT configuration right? From the driver logic,
> > DT just registers a device corresponding to the machine driver so
> > that it can probe(). We could register one in fsl_audmix instead.
> > Please refer to how fsl_ssi registers the sound card device. The
> > machine driver can get audmix_np from the parent device pointer,
> > and I think that's all you need.
> Yes.

Thank you, sent V4 which implements the approach suggested by Nicolin.

> 
> > 
> > Or maybe someone else would provide a better way. But it'd work.
> Or the machine driver could create the audmix device. That probably 
> makes less sense, but either way there doesn't have to be a 1-1 
> correspondence of DT nodes and (platform) devices.
> 
> I'm not an ASoC expert, but why can't the machine driver just control
> the audmix directly (with DAIs as separate drivers)? Is the audmix
> ever going to a be a component for a different machine driver?
> 
> Rob

Currently I'm not aware of any information with regard to if audmix is
ever going to work with other DAIs than SAI. Howerver from audmix IP
block integration perspective the only requirement is that the input
DAI must be connected to audmix over I2S bus, possible DAI options are
SAI, ESAI, etc - I think the approach to mix both device and machine
drivers into a single entity is not the best way to go.

/Viorel

  reply	other threads:[~2019-01-22 11:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 12:46 [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers Viorel Suman
2019-01-17 12:46 ` Viorel Suman
2019-01-17 12:46 ` [PATCH v3 1/4] ASoC: fsl: Add Audio Mixer CPU DAI driver Viorel Suman
2019-01-17 12:46   ` Viorel Suman
2019-01-17 12:46 ` [PATCH v3 2/4] ASoC: add fsl_audmix DT binding documentation Viorel Suman
2019-01-17 12:46   ` Viorel Suman
2019-01-26  1:49   ` Nicolin Chen
2019-01-26  1:49     ` Nicolin Chen
2019-01-17 12:46 ` [PATCH v3 3/4] ASoC: fsl: Add Audio Mixer machine driver Viorel Suman
2019-01-17 12:46   ` Viorel Suman
2019-01-17 12:46 ` [PATCH v3 4/4] ASoC: add imx-audmix DT binding documentation Viorel Suman
2019-01-17 12:46   ` Viorel Suman
2019-01-17 16:18 ` [PATCH v3 0/4] Add NXP AUDMIX device and machine drivers Rob Herring
2019-01-17 16:18   ` Rob Herring
2019-01-18 13:16   ` Viorel Suman
2019-01-18 13:16     ` Viorel Suman
2019-01-18 13:16     ` Viorel Suman
2019-01-18 19:46     ` Nicolin Chen
2019-01-18 19:46       ` Nicolin Chen
2019-01-18 19:46       ` Nicolin Chen
2019-01-21 15:23       ` Rob Herring
2019-01-21 15:23         ` Rob Herring
2019-01-21 15:23         ` Rob Herring
2019-01-22 11:39         ` Viorel Suman [this message]
2019-01-22 11:39           ` Viorel Suman
2019-01-22 11:39           ` Viorel Suman
2019-01-22 11:19       ` Viorel Suman
2019-01-22 11:19         ` Viorel Suman
2019-01-22 11:19         ` Viorel Suman
2019-01-17 22:22 ` Nicolin Chen
2019-01-17 22:22   ` Nicolin Chen
2019-01-17 22:24   ` Nicolin Chen
2019-01-17 22:24     ` Nicolin Chen

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=1548157178.13051.19.camel@nxp.com \
    --to=viorel.suman@nxp.com \
    --cc=Xiubo.Lee@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cosmin.samoila@nxp.com \
    --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@kernel.org \
    --cc=shengjiu.wang@nxp.com \
    --cc=timur@kernel.org \
    --cc=tiwai@suse.com \
    --cc=viorel.suman@gmail.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.