All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [Ksummit-2013-discuss] [ARM ATTEND] Describing complex, non-probable system topologies
Date: Fri, 2 Aug 2013 04:15:39 +0800	[thread overview]
Message-ID: <20130801201539.GA12291@kroah.com> (raw)
In-Reply-To: <20130801193936.GD23006@n2100.arm.linux.org.uk>

On Thu, Aug 01, 2013 at 08:39:36PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 02, 2013 at 03:27:30AM +0800, Greg KH wrote:
> > Hm, sounds like an ACPI tree is what you need to be using :)
> > 
> > Seriously, why not use ACPI for stuff like this?  You already are
> > starting to do that for ARM-based systems, why not just make it the
> > standard?
> 
> Is this in the same spirit as "you should be using DT, DT can describe
> everything you need to do.  It's made to describe bindings between
> devices!" and here we are, two years down the line, and we apparantly
> don't even have stable DT bindings for the ARM architecture because a
> lot of the subsystems which SoCs need have taken that long to get
> sorted.

No, it's in the same spirit of, "others have already done this before,
why are you thinking you need to reinvent the wheel?"

> The amount of work this has taken so far has been tremendous, and we're
> still working out lots of the details.  For instance, in the last six
> months, there's been an effort to try and work out how to sanely
> describe how a DMA controller is connected to a peripheral in DT.

But if people think that DT should only be used for the "platform_bus",
then they need to change their minds.  That's what I am referring to
here.

The platform bus was created for all of those little "we know where this
device is" devices.  Now that DT is being used to dynamically create
devices and their interconnections, it should not be used, as it starts
to fall apart as Will points out.

I'm not saying move away from DT at all, if it can be used to describe
stuff like this, wonderful.  Just please don't use platform_bus anymore
than you have to.

thanks,

greg k-h

  reply	other threads:[~2013-08-01 20:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 18:35 [ARM ATTEND] Describing complex, non-probable system topologies Will Deacon
2013-08-01 18:42 ` Dave Martin
2013-08-01 22:41   ` [Ksummit-2013-discuss] " David Brown
2013-08-01 19:27 ` Greg KH
2013-08-01 19:39   ` Russell King - ARM Linux
2013-08-01 20:15     ` Greg KH [this message]
2013-08-01 20:18       ` Russell King - ARM Linux
2013-08-01 20:36         ` Greg KH
2013-08-01 20:45           ` Russell King - ARM Linux
2013-08-01 21:04             ` Greg KH
2013-08-01 21:48           ` James Bottomley
2013-08-01 23:16             ` Mark Brown
2013-08-02  9:03   ` Tony Lindgren
2013-08-02  9:32     ` Greg KH
2013-08-02 12:34       ` Tony Lindgren
2013-08-02 14:14         ` Greg KH
2013-08-02 15:26           ` Dave Martin
2013-08-02 16:45             ` Will Deacon
2013-08-05  6:55           ` Tony Lindgren
2013-08-05  7:11             ` Greg KH
2013-08-05  7:37               ` Tony Lindgren
2013-08-05  8:02                 ` Greg KH
2013-08-05  8:21                   ` Tony Lindgren
2013-08-05  8:51                     ` Greg KH
2013-08-05  9:14                       ` Tony Lindgren
2013-08-08 16:50                       ` Kevin Hilman
2013-08-02 11:53   ` Will Deacon
2013-08-02 12:37     ` Tony Lindgren
2013-08-02 14:16       ` Greg KH
2013-08-02 14:20     ` Greg KH
2013-08-02 16:09       ` Will Deacon
2013-08-02 22:32         ` Greg KH
2013-08-03  5:16           ` Olof Johansson
2013-08-05  6:47             ` Tony Lindgren
2013-08-07  1:52             ` Will Deacon
2013-08-20  6:59             ` Hiroshi Doyu
2013-08-07  1:49           ` Will Deacon
2013-08-01 21:41 ` James Bottomley
2013-08-02 17:08   ` Will Deacon
2013-08-01 22:26 ` Bjorn Helgaas
2013-08-02 12:01   ` Will Deacon

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=20130801201539.GA12291@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.