All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Describing arbitrary bus mastering relationships in DT
Date: Fri, 02 May 2014 12:50:17 -0600	[thread overview]
Message-ID: <5363E8E9.6000908@wwwdotorg.org> (raw)
In-Reply-To: <20140502132327.GA14612@ulmo>

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?

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Shaik Ameer Basha
	<shaik.ameer-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
	Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [RFC] Describing arbitrary bus mastering relationships in DT
Date: Fri, 02 May 2014 12:50:17 -0600	[thread overview]
Message-ID: <5363E8E9.6000908@wwwdotorg.org> (raw)
In-Reply-To: <20140502132327.GA14612@ulmo>

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?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-05-02 18:50 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 17:32 [RFC] Describing arbitrary bus mastering relationships in DT Dave Martin
2014-05-01 17:32 ` Dave Martin
2014-05-02 11:05 ` Thierry Reding
2014-05-02 11:05   ` Thierry Reding
2014-05-02 12:32   ` Arnd Bergmann
2014-05-02 12:32     ` Arnd Bergmann
2014-05-02 13:23     ` Thierry Reding
2014-05-02 13:23       ` Thierry Reding
2014-05-02 15:19       ` Arnd Bergmann
2014-05-02 15:19         ` Arnd Bergmann
2014-05-02 17:43         ` Dave Martin
2014-05-02 17:43           ` Dave Martin
2014-05-05 15:14           ` Arnd Bergmann
2014-05-05 15:14             ` Arnd Bergmann
2014-05-09 10:33             ` Dave Martin
2014-05-09 10:33               ` Dave Martin
2014-05-09 11:15               ` Arnd Bergmann
2014-05-09 11:15                 ` Arnd Bergmann
2014-05-09 14:59               ` Grant Grundler
2014-05-09 14:59                 ` Grant Grundler
2014-05-02 18:55         ` Stephen Warren
2014-05-02 18:55           ` Stephen Warren
2014-05-02 19:02           ` Arnd Bergmann
2014-05-02 19:02             ` Arnd Bergmann
2014-05-09 10:45             ` Dave Martin
2014-05-09 10:45               ` Dave Martin
2014-05-02 18:50       ` Stephen Warren [this message]
2014-05-02 18:50         ` Stephen Warren
2014-05-02 19:06         ` Arnd Bergmann
2014-05-02 19:06           ` Arnd Bergmann
2014-05-09 10:56           ` Dave Martin
2014-05-09 10:56             ` Dave Martin
2014-05-12 16:19             ` Stephen Warren
2014-05-12 16:19               ` Stephen Warren
2014-05-12 18:10               ` Arnd Bergmann
2014-05-12 18:10                 ` Arnd Bergmann
2014-05-12 18:29                 ` Stephen Warren
2014-05-12 18:29                   ` Stephen Warren
2014-05-12 19:53                   ` Arnd Bergmann
2014-05-12 19:53                     ` Arnd Bergmann
2014-05-12 20:02                   ` Grant Grundler
2014-05-12 20:02                     ` Grant Grundler
2014-05-02 16:19   ` Dave Martin
2014-05-02 16:19     ` Dave Martin
2014-05-02 16:14 ` Arnd Bergmann
2014-05-02 16:14   ` Arnd Bergmann
2014-05-02 17:31   ` Dave Martin
2014-05-02 17:31     ` Dave Martin
2014-05-02 18:17     ` Jason Gunthorpe
2014-05-02 18:17       ` Jason Gunthorpe
2014-05-09 14:16       ` Dave Martin
2014-05-09 14:16         ` Dave Martin
2014-05-09 17:10         ` Jason Gunthorpe
2014-05-09 17:10           ` Jason Gunthorpe
2014-05-02 20:36     ` Arnd Bergmann
2014-05-02 20:36       ` Arnd Bergmann
2014-05-09 13:26       ` Dave Martin
2014-05-09 13:26         ` Dave Martin

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=5363E8E9.6000908@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --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.