alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Timur Tabi <timur.tabi@gmail.com>
Cc: alsa-devel@alsa-project.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	kumar.gala@freescale.com,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	linuxppc-dev@ozlabs.org,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	lrg@slimlogic.co.uk
Subject: Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Date: Wed, 28 Apr 2010 15:58:34 -0600	[thread overview]
Message-ID: <z2xfa686aa41004281458u3a3048feh9d762e07f8052348@mail.gmail.com> (raw)
In-Reply-To: <j2qed82fe3e1004281335h4076b050jc2894d4c4d6eac65@mail.gmail.com>

On Wed, Apr 28, 2010 at 2:35 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>
>> Keep in mind that it's perfectly kosher to create nodes for "virtual"
>> devices. IE. We could imagine a node for the "sound subsystem" that
>> doesn't actually correspond to any physical device but contain the
>> necessary properties that binds everything together. You could even have
>> multiple of these if you have separate set of sound HW that aren't
>> directly dependant.
>
> First, I want to officially retract this patch.  I've talked with
> Grant, and we've come up with a different approach to this problem.
>
> Second, how about this binding for the virtual sound node?  It would
> be a root-level node.
>
>        sound-devices {
>                sound0 {
>                        ssi = &ssi0;
>                        playback-dma = &dma00;
>                        capture-dma = &dma01;
>                        codec = &cs4270;
>                }
>        };

The sound0 node needs a compatible value, the sound-device node should
probably have one too.

The sound0 node should have something board specific like
"fsl,mpc8610hpcd-sound" to make it clear that the binding really only
applies to this particular board.  It would also be a good idea to
prefix all of the property names with 'fsl,' to avoid conflicting with
any future common bindings or conventions.  Other boards can use the
same binding, but they would get a different compatible value (the
driver could bind on both).

I'm not a huge fan of the name "sound-devices" for the parent node.
There are other sorts of things that we need 'virtual' device nodes to
describe.  It would be nice to have a single place for collecting
nodes for stuff like this.  Perhaps this:

system {
        compatible = "system-devices";
        sound0 {
                compatible = "fsl,mpc8610hpcd-sound";
                fsl,ssi = &ssi0;
                fsl,playback-dma = &dma00;
                fsl,capture-dma = &dma01;
                fsl,codec = &cs4270;
        };
};

But I really don't have any knowledge of what has been done previously
in this regard or if any conventions have been established.  Ben, any
thoughts?

g.

  reply	other threads:[~2010-04-28 21:58 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-26 20:49 [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers Timur Tabi
2010-04-27  6:36 ` Benjamin Herrenschmidt
2010-04-27  8:07   ` Liam Girdwood
2010-04-27 14:52     ` Timur Tabi
2010-04-27 15:20       ` Liam Girdwood
2010-04-27 15:28         ` Timur Tabi
2010-04-27 15:56           ` Timur Tabi
2010-04-27 16:41           ` Liam Girdwood
2010-04-27 18:32             ` Timur Tabi
2010-04-27 19:15               ` Grant Likely
2010-04-27 20:04                 ` Timur Tabi
2010-04-27 20:38                   ` Mark Brown
2010-04-28  4:19                   ` Benjamin Herrenschmidt
2010-04-28  4:18                 ` Benjamin Herrenschmidt
2010-04-30 21:46         ` Timur Tabi
2010-04-30 22:04           ` Timur Tabi
2010-04-27 20:24     ` Grant Likely
2010-04-27 20:46       ` Timur Tabi
2010-04-27 20:59         ` Mark Brown
2010-04-27 21:03           ` Timur Tabi
2010-04-27 21:11             ` Mark Brown
2010-04-28  4:25           ` Benjamin Herrenschmidt
2010-04-28 13:00             ` Mark Brown
2010-04-29  0:42               ` Benjamin Herrenschmidt
2010-04-28  5:37         ` Grant Likely
2010-04-28 13:35           ` Timur Tabi
2010-04-28 13:57             ` Grant Likely
2010-04-28 16:20               ` Timur Tabi
2010-04-28 16:47                 ` Grant Likely
2010-04-28 17:27                   ` Timur Tabi
2010-04-27 22:29       ` Mark Brown
2010-04-28  2:31         ` Grant Likely
2010-04-28  9:16           ` Mark Brown
2010-04-28  4:10         ` Benjamin Herrenschmidt
2010-04-28 12:07           ` Mark Brown
2010-04-29  0:36             ` Benjamin Herrenschmidt
2010-04-29  3:43               ` Grant Likely
2010-04-28 13:19         ` Timur Tabi
2010-04-28 13:39           ` Mark Brown
2010-04-27  9:54   ` Mark Brown
2010-04-27 10:09     ` Benjamin Herrenschmidt
2010-04-27 10:41       ` Mark Brown
2010-04-27 20:27       ` Grant Likely
2010-04-27 20:50         ` Mark Brown
2010-04-27 20:53           ` Timur Tabi
2010-04-28 12:49         ` Liam Girdwood
2010-04-28 20:35       ` Timur Tabi
2010-04-28 21:58         ` Grant Likely [this message]
2010-04-28 22:13           ` Timur Tabi
     [not found]             ` <r2oed82fe3e1004281513k23b54b56v7904a4a34750c90b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-04-28 22:23               ` [alsa-devel] " Grant Likely
2010-04-29  0:52               ` Benjamin Herrenschmidt
2010-04-29  3:44                 ` Grant Likely
2010-04-29  0:50         ` Benjamin Herrenschmidt
2010-04-27 19:21 ` Grant Likely
2010-04-27 20:05   ` Timur Tabi

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=z2xfa686aa41004281458u3a3048feh9d762e07f8052348@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=alsa-devel@alsa-project.org \
    --cc=benh@kernel.crashing.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=timur.tabi@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 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).