All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, kumar.gala@freescale.com,
	Grant Likely <grant.likely@secretlab.ca>,
	linuxppc-dev@ozlabs.org, Timur Tabi <timur@freescale.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Date: Thu, 29 Apr 2010 10:42:56 +1000	[thread overview]
Message-ID: <1272501776.24542.131.camel@pasglop> (raw)
In-Reply-To: <20100428130037.GF31400@opensource.wolfsonmicro.com>

On Wed, 2010-04-28 at 14:00 +0100, Mark Brown wrote:
> > The whole thing is a matter of common sense and a bit of taste :-)
> 
> The impression that has been created in the past is that there are
> inflexible device tree rules which can't be varied.

I'm a bit sad this is how things have been perceived since that's
clearly not the policy I've applied to the powerpc architecture.

Or rather, there are -some- inflexible rules yes, which are to:

 - Have a device-tree :-)

 - Have a /compatible property at the toplevel to identify your board

 - Have the /cpus nodes for representing the CPUs.

That's pretty much the only absolute requirements from a code
perspective.

Now I -do- require people to also have nodes for things like PCI host
bridge, since that allows using a ton of existing code for handling most
aspects of PCI, and I -do- complain if people just hard wire platform
devices everywhere or interrupt numbers without even trying to consider
using the device-tree appropriately.

However, I've always been against the one-bsp-fits-all approach, and
it's always been my clear policy that there should be a per-machine .c
file. I did bend when folks pushed the "simple" platform but with the
understanding that it must contain an -explicit- list of boards it
supports.

You'll also notice that all of my virtual interrupt handling stuff is
such that you -can- use it without device-tree nodes, the DT just makes
it easier. Same goes with PCI devices (only the PHB requires a DT node
at this stage) etc... 

Cheers,
Ben.

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, kumar.gala@freescale.com,
	linuxppc-dev@ozlabs.org, Timur Tabi <timur@freescale.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Date: Thu, 29 Apr 2010 10:42:56 +1000	[thread overview]
Message-ID: <1272501776.24542.131.camel@pasglop> (raw)
In-Reply-To: <20100428130037.GF31400@opensource.wolfsonmicro.com>

On Wed, 2010-04-28 at 14:00 +0100, Mark Brown wrote:
> > The whole thing is a matter of common sense and a bit of taste :-)
> 
> The impression that has been created in the past is that there are
> inflexible device tree rules which can't be varied.

I'm a bit sad this is how things have been perceived since that's
clearly not the policy I've applied to the powerpc architecture.

Or rather, there are -some- inflexible rules yes, which are to:

 - Have a device-tree :-)

 - Have a /compatible property at the toplevel to identify your board

 - Have the /cpus nodes for representing the CPUs.

That's pretty much the only absolute requirements from a code
perspective.

Now I -do- require people to also have nodes for things like PCI host
bridge, since that allows using a ton of existing code for handling most
aspects of PCI, and I -do- complain if people just hard wire platform
devices everywhere or interrupt numbers without even trying to consider
using the device-tree appropriately.

However, I've always been against the one-bsp-fits-all approach, and
it's always been my clear policy that there should be a per-machine .c
file. I did bend when folks pushed the "simple" platform but with the
understanding that it must contain an -explicit- list of boards it
supports.

You'll also notice that all of my virtual interrupt handling stuff is
such that you -can- use it without device-tree nodes, the DT just makes
it easier. Same goes with PCI devices (only the PHB requires a DT node
at this stage) etc... 

Cheers,
Ben.

  reply	other threads:[~2010-04-29  0:43 UTC|newest]

Thread overview: 108+ 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  6:36   ` Benjamin Herrenschmidt
2010-04-27  8:07   ` Liam Girdwood
2010-04-27  8:07     ` [alsa-devel] " Liam Girdwood
2010-04-27 14:52     ` Timur Tabi
2010-04-27 14:52       ` [alsa-devel] " Timur Tabi
2010-04-27 15:20       ` Liam Girdwood
2010-04-27 15:20         ` [alsa-devel] " Liam Girdwood
2010-04-27 15:28         ` Timur Tabi
2010-04-27 15:28           ` [alsa-devel] " Timur Tabi
2010-04-27 15:56           ` Timur Tabi
2010-04-27 15:56             ` [alsa-devel] " Timur Tabi
2010-04-27 16:41           ` Liam Girdwood
2010-04-27 16:41             ` [alsa-devel] " Liam Girdwood
2010-04-27 18:32             ` Timur Tabi
2010-04-27 18:32               ` [alsa-devel] " Timur Tabi
2010-04-27 19:15               ` Grant Likely
2010-04-27 19:15                 ` [alsa-devel] " Grant Likely
2010-04-27 20:04                 ` Timur Tabi
2010-04-27 20:04                   ` [alsa-devel] " Timur Tabi
2010-04-27 20:38                   ` Mark Brown
2010-04-27 20:38                     ` [alsa-devel] " Mark Brown
2010-04-28  4:19                   ` Benjamin Herrenschmidt
2010-04-28  4:19                     ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-28  4:18                 ` Benjamin Herrenschmidt
2010-04-28  4:18                   ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-30 21:46         ` Timur Tabi
2010-04-30 21:46           ` [alsa-devel] " Timur Tabi
2010-04-30 22:04           ` Timur Tabi
2010-04-30 22:04             ` [alsa-devel] " Timur Tabi
2010-04-27 20:24     ` Grant Likely
2010-04-27 20:24       ` [alsa-devel] " Grant Likely
2010-04-27 20:46       ` Timur Tabi
2010-04-27 20:46         ` [alsa-devel] " Timur Tabi
2010-04-27 20:59         ` Mark Brown
2010-04-27 20:59           ` [alsa-devel] " Mark Brown
2010-04-27 21:03           ` Timur Tabi
2010-04-27 21:03             ` [alsa-devel] " Timur Tabi
2010-04-27 21:11             ` Mark Brown
2010-04-27 21:11               ` [alsa-devel] " Mark Brown
2010-04-28  4:25           ` Benjamin Herrenschmidt
2010-04-28  4:25             ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-28 13:00             ` Mark Brown
2010-04-28 13:00               ` [alsa-devel] " Mark Brown
2010-04-29  0:42               ` Benjamin Herrenschmidt [this message]
2010-04-29  0:42                 ` Benjamin Herrenschmidt
2010-04-28  5:37         ` Grant Likely
2010-04-28  5:37           ` [alsa-devel] " Grant Likely
2010-04-28 13:35           ` Timur Tabi
2010-04-28 13:35             ` [alsa-devel] " Timur Tabi
2010-04-28 13:57             ` Grant Likely
2010-04-28 13:57               ` [alsa-devel] " Grant Likely
2010-04-28 16:20               ` Timur Tabi
2010-04-28 16:20                 ` [alsa-devel] " Timur Tabi
2010-04-28 16:47                 ` Grant Likely
2010-04-28 16:47                   ` [alsa-devel] " Grant Likely
2010-04-28 17:27                   ` Timur Tabi
2010-04-28 17:27                     ` [alsa-devel] " Timur Tabi
2010-04-27 22:29       ` Mark Brown
2010-04-27 22:29         ` [alsa-devel] " Mark Brown
2010-04-28  2:31         ` Grant Likely
2010-04-28  2:31           ` [alsa-devel] " Grant Likely
2010-04-28  9:16           ` Mark Brown
2010-04-28  9:16             ` [alsa-devel] " Mark Brown
2010-04-28  4:10         ` Benjamin Herrenschmidt
2010-04-28  4:10           ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-28 12:07           ` Mark Brown
2010-04-28 12:07             ` [alsa-devel] " Mark Brown
2010-04-29  0:36             ` Benjamin Herrenschmidt
2010-04-29  0:36               ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-29  3:43               ` Grant Likely
2010-04-29  3:43                 ` [alsa-devel] " Grant Likely
2010-04-28 13:19         ` Timur Tabi
2010-04-28 13:19           ` [alsa-devel] " Timur Tabi
2010-04-28 13:39           ` Mark Brown
2010-04-28 13:39             ` [alsa-devel] " Mark Brown
2010-04-27  9:54   ` Mark Brown
2010-04-27  9:54     ` Mark Brown
2010-04-27 10:09     ` Benjamin Herrenschmidt
2010-04-27 10:09       ` Benjamin Herrenschmidt
2010-04-27 10:41       ` Mark Brown
2010-04-27 10:41         ` Mark Brown
2010-04-27 20:27       ` Grant Likely
2010-04-27 20:27         ` Grant Likely
2010-04-27 20:50         ` Mark Brown
2010-04-27 20:50           ` Mark Brown
2010-04-27 20:53           ` Timur Tabi
2010-04-27 20:53             ` Timur Tabi
2010-04-28 12:49         ` Liam Girdwood
2010-04-28 12:49           ` [alsa-devel] " Liam Girdwood
2010-04-28 20:35       ` Timur Tabi
2010-04-28 20:35         ` [alsa-devel] " Timur Tabi
2010-04-28 21:58         ` Grant Likely
2010-04-28 21:58           ` [alsa-devel] " Grant Likely
2010-04-28 22:13           ` Timur Tabi
2010-04-28 22:13             ` [alsa-devel] " Timur Tabi
     [not found]             ` <r2oed82fe3e1004281513k23b54b56v7904a4a34750c90b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-04-28 22:23               ` Grant Likely
2010-04-28 22:23                 ` Grant Likely
2010-04-29  0:52               ` Benjamin Herrenschmidt
2010-04-29  0:52                 ` Benjamin Herrenschmidt
2010-04-29  3:44                 ` Grant Likely
2010-04-29  3:44                   ` [alsa-devel] " Grant Likely
2010-04-29  0:50         ` Benjamin Herrenschmidt
2010-04-29  0:50           ` [alsa-devel] " Benjamin Herrenschmidt
2010-04-27 19:21 ` Grant Likely
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=1272501776.24542.131.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=grant.likely@secretlab.ca \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=timur@freescale.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.