[RFC] Describing arbitrary bus mastering relationships in DT

[Stephen Warren]

On 05/02/2014 07:23 AM, Thierry Reding wrote:
> On Fri, May 02, 2014 at 02:32:08PM +0200, Arnd Bergmann wrote:
>> On Friday 02 May 2014 13:05:58 Thierry Reding wrote:
>>>
>>> Let me see if I understood the above proposal by trying to translate it
>>> into a simple example for a specific use-case. On Tegra for example we
>>> have various units that can either access system memory directly or use
>>> the IOMMU to translate accesses for them. One such unit would be the
>>> display controller that scans out a framebuffer from memory.
>>
>> Can you explain how the decision is made whether the IOMMU gets used
>> or not? In all cases I've seen so far, I think we can hardwire this
>> in DT, and only expose one or the other. Are both ways used
>> concurrently?
> 
> It should be possible to hardcode this in DT for Tegra. As I understand
> it, both interfaces can't be used at the same time. Once translation has
> been enabled for one client, all accesses generated by that client will
> be translated.
> 
> Hiroshi, please correct me if I'm wrong.

I believe the HW connectivity is always as follows:

Bus master (e.g. display controller) ---> IOMMU (Tegra SMMU) ---> RAM

In the IOMMU, there is a bit per bus master that indicates whether the
IOMMU translates the bus master's accesses or not. If that bit is
enabled, then page tables in the IOMMU are used to perform the translation.

You could also look at the HW setup as:

Bus master (e.g. display controller)
    v
   ----
  /    \
  ------
   |  \
   |   ------------------
   |                     \
   v                     v
IOMMU (Tegra SMMU) ---> RAM

But IIRC the bit that controls that demux is in the IOMMU, so this
distinction probably isn't relevant.

Now, perhaps there are devices which themselves control whether
transactions are sent to the IOMMU or direct to RAM, but I'm not
familiar with them. Is the GPU in that category, since it has its own
GMMU, albeit chained into the SMMU IIRC?