From mboxrd@z Thu Jan  1 00:00:00 1970
From: will.deacon@arm.com (Will Deacon)
Date: Thu, 1 Aug 2013 19:35:31 +0100
Subject: [ARM ATTEND] Describing complex, non-probable system topologies
Message-ID: <20130801183531.GB29831@mudshark.cambridge.arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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.

  - 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).

  - 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.

The last point is increasingly important as various blocks of ARM system
IP start to require knowledge of masters and how things like memory
traffic, DVM messages, interrupts (think MSI) etc are routed between
them in order to configure the system correctly. For example, interfacing
a PCIe device with an SMMU requires knowledge of both the requester id
associated with the device and how that maps to incoming stream ids
(based off the AXI bus id) on the SMMU. Even worse, this mapping is
likely generated dynamically by the host controller, which would need to
know about downstream buses and their SMMUs.

Other than that, I'd be interested in attending since I'm fairly active
on the architectural side of things and keen to follow any discussions
that may impact core architectural code. Previous ARM mini-summits have been
a great success, so I'm really looking forward to this one.

Cheers,

Will