From: Mark Brown <broonie@kernel.org> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Jean-Francois Moine <moinejf@free.fr>, Liam Girdwood <lgirdwood@gmail.com>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>, Rob Herring <rob.herring@calxeda.com>, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 3/4] ASoc: kirkwood: merge kirkwood-i2c and kirkwood-dma Date: Fri, 26 Jul 2013 11:58:31 +0100 [thread overview] Message-ID: <20130726105831.GA9858@sirena.org.uk> (raw) In-Reply-To: <20130725225816.GG24642@n2100.arm.linux.org.uk> [-- Attachment #1: Type: text/plain, Size: 1648 bytes --] On Thu, Jul 25, 2013 at 11:58:16PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 25, 2013 at 08:16:04PM +0100, Mark Brown wrote: > > This seems mostly fine, though it may be best to keep kirkwood-dma as a > > separate module for the benefit of the S/PDIF support when it gets added > > - I had a look at the implementation Russell has and it looks like it > > can be added as a separate interface. > You wouldn't want I2S and SPDIF to be separate modules though - they're > the same hardware but different output stream formatters attached to the > DMA FIFO output. Don't forget the requirements concerning the simultaneous > use of I2S and SPDIF - these "output formatters" must both be enabled and > disabled in unison when concurrent use is required - both bits must be > set or cleared together with a single register write. OK, I knew they both needed to know about each other and to share some stuff but I figured it was reasonable to compile out the S/PDIF support if only using I2S or similar - so long as they're coupled at runtime it should be fine. > > Should the name be done as dev_name() for the interface (I don't know if > > there is ever more than one)? > Getting away from "kirkwood-i2s" would be sensible, because it may not be > just "i2s" in this hardware block. The documentation calls this an "audio > controller" but I guess "kirkwood-pcm" would be a reasonable compromise, > even though it has a separate AC'97 block which could also be construed > as being "pcm". I was thinking just pick a name at runtime based on what was doing the instantiation which would avoid hard coding anything in the DMA driver. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Jean-Francois Moine <moinejf@free.fr>, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, Takashi Iwai <tiwai@suse.de>, linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>, Rob Herring <rob.herring@calxeda.com> Subject: Re: [PATCH 3/4] ASoc: kirkwood: merge kirkwood-i2c and kirkwood-dma Date: Fri, 26 Jul 2013 11:58:31 +0100 [thread overview] Message-ID: <20130726105831.GA9858@sirena.org.uk> (raw) In-Reply-To: <20130725225816.GG24642@n2100.arm.linux.org.uk> [-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --] On Thu, Jul 25, 2013 at 11:58:16PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 25, 2013 at 08:16:04PM +0100, Mark Brown wrote: > > This seems mostly fine, though it may be best to keep kirkwood-dma as a > > separate module for the benefit of the S/PDIF support when it gets added > > - I had a look at the implementation Russell has and it looks like it > > can be added as a separate interface. > You wouldn't want I2S and SPDIF to be separate modules though - they're > the same hardware but different output stream formatters attached to the > DMA FIFO output. Don't forget the requirements concerning the simultaneous > use of I2S and SPDIF - these "output formatters" must both be enabled and > disabled in unison when concurrent use is required - both bits must be > set or cleared together with a single register write. OK, I knew they both needed to know about each other and to share some stuff but I figured it was reasonable to compile out the S/PDIF support if only using I2S or similar - so long as they're coupled at runtime it should be fine. > > Should the name be done as dev_name() for the interface (I don't know if > > there is ever more than one)? > Getting away from "kirkwood-i2s" would be sensible, because it may not be > just "i2s" in this hardware block. The documentation calls this an "audio > controller" but I guess "kirkwood-pcm" would be a reasonable compromise, > even though it has a separate AC'97 block which could also be construed > as being "pcm". I was thinking just pick a name at runtime based on what was doing the instantiation which would avoid hard coding anything in the DMA driver. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2013-07-26 10:59 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-25 9:14 [PATCH 3/4] ASoc: kirkwood: merge kirkwood-i2c and kirkwood-dma Jean-Francois Moine 2013-07-25 19:16 ` Mark Brown 2013-07-25 19:16 ` Mark Brown 2013-07-25 22:58 ` Russell King - ARM Linux 2013-07-25 22:58 ` Russell King - ARM Linux 2013-07-26 7:38 ` Jean-Francois Moine 2013-07-26 10:58 ` Mark Brown [this message] 2013-07-26 10:58 ` Mark Brown
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=20130726105831.GA9858@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=devicetree@vger.kernel.org \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=moinejf@free.fr \ --cc=perex@perex.cz \ --cc=rob.herring@calxeda.com \ --cc=tiwai@suse.de \ /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: linkBe 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.