From: Mark Brown <broonie@kernel.org> To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Andrew Lunn <andrew@lunn.ch>, alsa-devel@alsa-project.org, Russell King - ARM Linux <linux@arm.linux.org.uk>, Jason Cooper <jason@lakedaemon.net>, Takashi Iwai <tiwai@suse.de>, Liam Girdwood <lgirdwood@gmail.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Date: Mon, 5 Aug 2013 19:59:22 +0100 [thread overview] Message-ID: <20130805185922.GC9858@sirena.org.uk> (raw) In-Reply-To: <51FFEB97.30004@gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3005 bytes --] On Mon, Aug 05, 2013 at 08:14:47PM +0200, Sebastian Hesselbarth wrote: > On 08/05/2013 06:59 PM, Mark Brown wrote: > >The clocking arrangements are an example of why the boards can get > >interesting enough to describe for themselves. > I understand there are complex arrangements, I still don't think that > you need a global super-node to describe them. Anyway, I am not voting > against a super-node. Please look back through the list archives, we've been round this loop repeatedly. > >>Also, all those "nvidia," properties would have fit very well into the > >>i2s controller node > >No, almost none of them have any place there. For example, the audio > >routing contains only connections to the CODEC so the I2S controller > >isn't in play, the headphone detection is connected to the AP but isn't > >connected to the I2S port. > From a quick look in tegra30_hub.h, I can see configuration registers > i2s formatting. I assume that i2s controller on Tegra can therefore > directly connected to a I2S codec, can't it? Then, with an existing i2s > node and an existing codec node - why is there no place to link both? At a minimum we'd need to figure out which end of the link to put it on and what to do about multi-drop links or links which share some or all of the clocks but have split data lines. > I can think of use cases that are hard to describe in a link-to-link > way, but none of them really requires a super-node nor special > board-specific compatible strings. With that we can just have the root > DT node be compatible with Beaver above and register all the old > platform_device way. It's just plain good practice to have some way to figure out which board we're running on. > [...] > >>I learned to never match "device nodes" with "drivers" as there > >>is simply no relation between them. > >That's clearly a thinko for device node. > I assume with "thinko" you mean "thought wrong" - IMHO the above > statement is very true. If it wouldn't, why not just have a node for > kirkwood-dma and kirkwood-i2s instead of merging the drivers? > You think that will also be accepted by DT maintainers? We don't have a node for the DMA driver because it's just a software wrapper for the DMA controller. We do have a node for the board because it's an actual physical thing that we can point at, the board driver is representing the audio subsystem schematic. > > From my point of view I'd rather not be shoving vendor prefixes on all > >the properties, this is coming from DT convention requiring vendor > >prefixes on bindings. > I understand that those vendor prefixes are part of the helper > functions of ASoC. But no other subsystem has a similar approach but No? I can't parse what you're saying here at all. > though of properties generic enough to help drivers find what they > need to know. Either ASoC is mis-interpreting the vendor-prefix > requirement - or all other subsystems are. This isn't me, this is people like Stephen (who's one of the DT guys...). [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Date: Mon, 5 Aug 2013 19:59:22 +0100 [thread overview] Message-ID: <20130805185922.GC9858@sirena.org.uk> (raw) In-Reply-To: <51FFEB97.30004@gmail.com> On Mon, Aug 05, 2013 at 08:14:47PM +0200, Sebastian Hesselbarth wrote: > On 08/05/2013 06:59 PM, Mark Brown wrote: > >The clocking arrangements are an example of why the boards can get > >interesting enough to describe for themselves. > I understand there are complex arrangements, I still don't think that > you need a global super-node to describe them. Anyway, I am not voting > against a super-node. Please look back through the list archives, we've been round this loop repeatedly. > >>Also, all those "nvidia," properties would have fit very well into the > >>i2s controller node > >No, almost none of them have any place there. For example, the audio > >routing contains only connections to the CODEC so the I2S controller > >isn't in play, the headphone detection is connected to the AP but isn't > >connected to the I2S port. > From a quick look in tegra30_hub.h, I can see configuration registers > i2s formatting. I assume that i2s controller on Tegra can therefore > directly connected to a I2S codec, can't it? Then, with an existing i2s > node and an existing codec node - why is there no place to link both? At a minimum we'd need to figure out which end of the link to put it on and what to do about multi-drop links or links which share some or all of the clocks but have split data lines. > I can think of use cases that are hard to describe in a link-to-link > way, but none of them really requires a super-node nor special > board-specific compatible strings. With that we can just have the root > DT node be compatible with Beaver above and register all the old > platform_device way. It's just plain good practice to have some way to figure out which board we're running on. > [...] > >>I learned to never match "device nodes" with "drivers" as there > >>is simply no relation between them. > >That's clearly a thinko for device node. > I assume with "thinko" you mean "thought wrong" - IMHO the above > statement is very true. If it wouldn't, why not just have a node for > kirkwood-dma and kirkwood-i2s instead of merging the drivers? > You think that will also be accepted by DT maintainers? We don't have a node for the DMA driver because it's just a software wrapper for the DMA controller. We do have a node for the board because it's an actual physical thing that we can point at, the board driver is representing the audio subsystem schematic. > > From my point of view I'd rather not be shoving vendor prefixes on all > >the properties, this is coming from DT convention requiring vendor > >prefixes on bindings. > I understand that those vendor prefixes are part of the helper > functions of ASoC. But no other subsystem has a similar approach but No? I can't parse what you're saying here at all. > though of properties generic enough to help drivers find what they > need to know. Either ASoC is mis-interpreting the vendor-prefix > requirement - or all other subsystems are. This isn't me, this is people like Stephen (who's one of the DT guys...). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130805/f1e2979e/attachment.sig>
next prev parent reply other threads:[~2013-08-05 18:59 UTC|newest] Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-04 19:21 [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Russell King - ARM Linux 2013-08-04 19:21 ` Russell King - ARM Linux 2013-08-04 19:22 ` [PATCH RFC 01/13] ASoC: kirkwood: merge struct kirkwood_dma_priv with struct kirkwood_dma_data Russell King 2013-08-04 19:22 ` Russell King 2013-08-05 14:49 ` Mark Brown 2013-08-05 14:49 ` Mark Brown 2013-08-04 19:23 ` [PATCH RFC 02/13] ASoC: kirkwood: use devm_clk_get() for the external clock Russell King 2013-08-04 19:23 ` Russell King 2013-08-05 16:16 ` Mark Brown 2013-08-05 16:16 ` Mark Brown 2013-08-04 19:24 ` [PATCH RFC 03/13] ASoC: avoid duplicated DAI routes Russell King 2013-08-04 19:24 ` Russell King 2013-08-05 16:18 ` Mark Brown 2013-08-05 16:18 ` Mark Brown 2013-08-04 19:25 ` [PATCH RFC 04/13] ASoC: HACK: avoid creating duplicated widgets Russell King 2013-08-04 19:25 ` Russell King 2013-08-04 19:26 ` [PATCH RFC 05/13] ASoC: kirkwood: provide KIRKWOOD_PLAYCTL_ENABLE_MASK Russell King 2013-08-04 19:26 ` Russell King 2013-08-05 17:03 ` Mark Brown 2013-08-05 17:03 ` Mark Brown 2013-08-04 19:27 ` [PATCH RFC 06/13] ASoC: kirkwood: combine kirkwood-i2s and kirkwood-dma drivers Russell King 2013-08-04 19:27 ` Russell King 2013-08-05 10:13 ` Jean-Francois Moine 2013-08-05 10:13 ` Jean-Francois Moine 2013-08-05 10:20 ` Russell King - ARM Linux 2013-08-05 10:20 ` Russell King - ARM Linux 2013-08-05 17:04 ` Mark Brown 2013-08-05 17:04 ` Mark Brown 2013-08-04 19:28 ` [PATCH RFC 07/13] ASoC: kirkwood: move calculation of max buffer size to kirkwood.h Russell King 2013-08-04 19:28 ` Russell King 2013-08-05 17:07 ` Mark Brown 2013-08-05 17:07 ` Mark Brown 2013-08-04 19:29 ` [PATCH RFC 08/13] ASoC: kirkwood: add DAPM widgets for input and output routing Russell King 2013-08-04 19:29 ` Russell King 2013-08-04 19:30 ` [PATCH RFC 09/13] ASoC: kirkwood-openrd: add DAPM links between codec and cpu DAI Russell King 2013-08-04 19:30 ` Russell King 2013-08-04 19:31 ` [PATCH RFC 10/13] ASoC: kirkwood-t5325: " Russell King 2013-08-04 19:31 ` Russell King 2013-08-05 11:27 ` Mark Brown 2013-08-05 11:27 ` Mark Brown 2013-08-05 11:33 ` Russell King - ARM Linux 2013-08-05 11:33 ` Russell King - ARM Linux 2013-08-05 14:40 ` Mark Brown 2013-08-05 14:40 ` Mark Brown 2013-08-05 14:56 ` Russell King - ARM Linux 2013-08-05 14:56 ` Russell King - ARM Linux 2013-08-05 20:32 ` Russell King - ARM Linux 2013-08-05 20:32 ` Russell King - ARM Linux 2013-08-05 22:06 ` Mark Brown 2013-08-05 22:06 ` Mark Brown 2013-08-05 23:30 ` Russell King - ARM Linux 2013-08-05 23:30 ` Russell King - ARM Linux 2013-08-06 13:32 ` Mark Brown 2013-08-06 13:32 ` Mark Brown 2013-08-10 16:11 ` Russell King - ARM Linux 2013-08-10 16:11 ` Russell King - ARM Linux 2013-08-10 21:13 ` Russell King - ARM Linux 2013-08-10 21:13 ` Russell King - ARM Linux 2013-08-12 7:40 ` Liam Girdwood 2013-08-12 7:40 ` [alsa-devel] " Liam Girdwood 2013-08-12 8:28 ` Russell King - ARM Linux 2013-08-12 8:28 ` [alsa-devel] " Russell King - ARM Linux 2013-08-13 14:59 ` Liam Girdwood 2013-08-13 14:59 ` [alsa-devel] " Liam Girdwood 2013-08-20 10:25 ` Russell King - ARM Linux 2013-08-20 10:25 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 11:44 ` Mark Brown 2013-08-20 11:44 ` [alsa-devel] " Mark Brown 2013-08-20 11:49 ` Russell King - ARM Linux 2013-08-20 11:49 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 13:31 ` Russell King - ARM Linux 2013-08-20 13:31 ` [alsa-devel] " Russell King - ARM Linux 2013-08-20 18:50 ` Mark Brown 2013-08-20 18:50 ` [alsa-devel] " Mark Brown 2013-08-20 20:18 ` Russell King - ARM Linux 2013-08-20 20:18 ` [alsa-devel] " Russell King - ARM Linux 2013-08-22 19:22 ` Liam Girdwood 2013-08-22 19:22 ` [alsa-devel] " Liam Girdwood 2013-08-22 20:16 ` Russell King - ARM Linux 2013-08-22 20:16 ` [alsa-devel] " Russell King - ARM Linux 2013-08-23 12:13 ` Liam Girdwood 2013-08-23 12:13 ` [alsa-devel] " Liam Girdwood 2013-08-23 12:58 ` Russell King - ARM Linux 2013-08-23 12:58 ` [alsa-devel] " Russell King - ARM Linux 2013-08-23 16:58 ` Mark Brown 2013-08-23 16:58 ` [alsa-devel] " Mark Brown 2013-08-23 17:45 ` Russell King - ARM Linux 2013-08-23 17:45 ` [alsa-devel] " Russell King - ARM Linux 2013-08-28 1:22 ` Mark Brown 2013-08-28 1:22 ` [alsa-devel] " Mark Brown 2013-08-29 21:12 ` Liam Girdwood 2013-08-30 11:27 ` Russell King - ARM Linux 2013-08-30 11:27 ` [alsa-devel] " Russell King - ARM Linux 2013-08-30 16:10 ` Russell King - ARM Linux 2013-08-30 16:10 ` [alsa-devel] " Russell King - ARM Linux 2013-08-11 12:36 ` Mark Brown 2013-08-11 12:36 ` Mark Brown 2013-08-04 19:32 ` [PATCH RFC 11/13] ASoC: spdif_transceiver: add output pin widget Russell King 2013-08-04 19:32 ` Russell King 2013-08-05 11:33 ` Mark Brown 2013-08-05 11:33 ` Mark Brown 2013-08-04 19:33 ` [PATCH RFC 12/13] ASoC: kirkwood: add SPDIF output support Russell King 2013-08-04 19:33 ` Russell King 2013-08-04 19:34 ` [PATCH RFC 13/13] ASoC: kirkwood: add IEC958 channel status support Russell King 2013-08-04 19:34 ` Russell King 2013-08-04 21:45 ` [PATCH RFC 00/13] Adding SPDIF support to kirkwood-i2s Sebastian Hesselbarth 2013-08-04 21:45 ` Sebastian Hesselbarth 2013-08-05 8:43 ` Thomas Petazzoni 2013-08-05 8:43 ` Thomas Petazzoni 2013-08-05 8:53 ` Russell King - ARM Linux 2013-08-05 8:53 ` Russell King - ARM Linux 2013-08-05 9:06 ` Thomas Petazzoni 2013-08-05 9:06 ` Thomas Petazzoni 2013-08-05 11:59 ` Mark Brown 2013-08-05 11:59 ` Mark Brown 2013-08-05 13:06 ` Sebastian Hesselbarth 2013-08-05 13:06 ` Sebastian Hesselbarth 2013-08-05 14:07 ` Mark Brown 2013-08-05 14:07 ` Mark Brown 2013-08-05 15:04 ` Sebastian Hesselbarth 2013-08-05 15:04 ` Sebastian Hesselbarth 2013-08-05 16:59 ` Mark Brown 2013-08-05 16:59 ` Mark Brown 2013-08-05 18:14 ` Sebastian Hesselbarth 2013-08-05 18:14 ` Sebastian Hesselbarth 2013-08-05 18:59 ` Mark Brown [this message] 2013-08-05 18:59 ` Mark Brown 2013-08-05 22:47 ` Stephen Warren 2013-08-05 22:47 ` [alsa-devel] " Stephen Warren 2013-08-05 14:10 ` Lars-Peter Clausen 2013-08-05 14:10 ` [alsa-devel] " Lars-Peter Clausen 2013-08-05 15:03 ` Mark Brown 2013-08-05 15:03 ` [alsa-devel] " Mark Brown 2013-08-06 0:02 ` Kuninori Morimoto 2013-08-06 0:02 ` [alsa-devel] " Kuninori Morimoto 2013-08-30 7:20 ` Kuninori Morimoto 2013-08-30 7:20 ` [alsa-devel] " Kuninori Morimoto 2013-08-30 8:26 ` Lars-Peter Clausen 2013-08-30 8:26 ` [alsa-devel] " Lars-Peter Clausen 2013-08-30 9:56 ` Mark Brown 2013-08-30 9:56 ` [alsa-devel] " Mark Brown 2013-08-05 14:59 ` Russell King - ARM Linux 2013-08-05 14:59 ` Russell King - ARM Linux
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=20130805185922.GC9858@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=andrew@lunn.ch \ --cc=jason@lakedaemon.net \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@arm.linux.org.uk \ --cc=sebastian.hesselbarth@gmail.com \ --cc=thomas.petazzoni@free-electrons.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.