linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: James.Bottomley@HansenPartnership.com (James Bottomley)
To: linux-arm-kernel@lists.infradead.org
Subject: [Ksummit-2013-discuss] [ARM ATTEND] Describing complex, non-probable system topologies
Date: Thu, 01 Aug 2013 14:41:49 -0700	[thread overview]
Message-ID: <1375393309.2070.12.camel@dabdike> (raw)
In-Reply-To: <20130801183531.GB29831@mudshark.cambridge.arm.com>

On Thu, 2013-08-01 at 19:35 +0100, Will Deacon wrote:
> Hello,
> 
> Whilst Linux implements a bunch of different bus types (many of which
> are in fact virtual), devices sitting on non-probable, memory mapped
> buses inside SoCs typically live on either the platform_bus or the
> amba_bus. So far, this has worked out alright; the buses haven't needed
> to be visible to software and no additional software control is really
> required from the OS. However, as I/O coherency and hardware
> virtualisation capabilities start to creep into ARM-based SoCs, Linux
> needs to know the topology of the system on which it is running.
> 
> Naturally, this would need to be described as a device-tree binding and
> communicate:
> 
>   - Buses which can be configured as coherent, including which devices
>     on those buses can be made coherent.

I don't think coherency is a good bus property:  we have PCI systems
which are incoherent by virtue of the CPU they're attached to rather
than because of any fundamental bus property.

>   - How IOMMUs sit on the bus and interact with masters on that bus (the
>     current one-IOMMU-driver-per-bus may not work well for the
>     platform_bus).

That's really not a good model.  On most parisc system, we have a split
IOMMU model (we mostly have two iommus and the topology determines which
one you have to use), but our two upper iommus are exposed as parisc
devices sitting at the root of the device tree.  When we program the
device for DMA we walk up the bus until we find the correct iommu to
program.

>   - QoS and PM constraints. This isn't really in my area, but we do have
>     buses that have these features and expect software to control them.
> 
>   - The system topology and linkages between buses and devices.

Actually, topology isn't really about linkages between busses and
devices.  Topology is about linkages between devices and devices.  A bus
type is a grouping of a set of devices which share common properties so
if you look at parisc for example, which is closest to ARM, our bus
topology at the top is usually two iommus connected to a set of end
points connected to several parisc specific things, all of which are bus
type parisc.  PCI is the same since PCI bridges are also PCI devices,
you can get device topologies nesting quite deep.

James

  parent reply	other threads:[~2013-08-01 21:41 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
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 [this message]
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=1375393309.2070.12.camel@dabdike \
    --to=james.bottomley@hansenpartnership.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 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).