linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: pullip.cho@samsung.com (Cho KyongHo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
Date: Thu, 08 Aug 2013 11:19:24 +0900	[thread overview]
Message-ID: <001501ce93dd$b38d23f0$1aa76bd0$@samsung.com> (raw)
In-Reply-To: <CANEJEGtDm6FYvx8DdiGofk5ViU8kWK-3QvTvtU66Mvhfn+sDCQ@mail.gmail.com>

> -----Original Message-----
> From: grundler at google.com [mailto:grundler at google.com] On Behalf Of Grant Grundler
> Sent: Thursday, August 08, 2013 1:21 AM
> 
> On Wed, Aug 7, 2013 at 5:07 AM, Cho KyongHo <pullip.cho@samsung.com> wrote:
> ...
> >> I don't understand how this is possible. Can someone explain this
> >> better in the IOMMU documentation please?
> >
> > System MMU is dedicated to a master H/W such as FIMD and FIMC.
> 
> Sory - Exynos 5250 documentation I have (confidential version) uses
> FIMD and FIMC but never explains what they are nor identifies them in
> a diagram. Based on the references, they are related to the video
> mixer but I don't know exactly what function FIMD/FIMC serve.

Ok.
FIMD is a display controller that reads RGB data and conveys the data
to the screen.
FIMC performs various functions including storing camera censor data to
the memory, image post processing like scaling, color space conversion
and rotation and conveying the processed data to FIMD.

> 
> 
> > Thus, attaching a master H/W to an iommu domain can be thought as
> > attaching a System MMU to an iommu domain even though such thinking
> > is not correct view of the relationship between iommu domain and
> > System MMU.
> 
> This almost makes sense. I understand the above to mean the System MMU
> is a proxy for the FIMD and FIMC.
> 
> >> I can understand we might have multiple MMUs in a system...e.g. every
> >> range of memory might have it's own MMU. But they share the same
> >> physical address space and generally live under one page table.
> >> Because of "one page table" I would consider them one entity from the
> >> the IOMMUs perspective.
> >
> > Sorry, I don't understand.
> > Do you mean you are thinking that it is better to share one page table
> > by all IOMMUs in a system?
> 
> No. This is how the previous IOMMUs I worked on functioned. It doesn't
> mean this is how current ones should.
> 
> My example above was referring to CPU MMUs in the case of NUMA
> architectures. Each NUMA CPU socket can have it's own MMU (and TLB)
> and corresponding memory controller. All CPUs in an SMP system map
> process and kernel virtual addresses to one common "physical" address
> space. This means allocation and use of "physical address space" has
> to be managed as one entity (even if several page tables exist in the
> implementation - e.g. NUMA).
> 
> 
> Back to the original comment that started my question (pulled out of
> context now...sorry):
>    "Just make sure that it will be possible to attach more than one
> sysmmu controller to one iommu domain."
> 
> Does that mean the IOMMU now has to map to multiple "physical address
> spaces" or am I completely missing what a SysMMU does?

I think I have explained what the quotation actually intended.
Exynos System MMUs in a SoC have the same view of physical address space.
But they provide different views of memory to their master H/Ws.
I think this is what Marek wanted to say.
> 
> The "SysMMU" is the System Memory Management Unit, right?

Yes it is IOMMU in Exynos SoCs.
It is referred as "SysMMU", "sysmmu", "smmu" or "System MMU".
All are the same in the context of Exynos SoCs.

It is not an implementation of ARM System MMU specifications.

> 
> I still thinking one IOMMU domain maps one (IO) virtual address space
> to one (common with CPU and other IOMMU) physical address space.

Definitely I agree with you.
However, this discussion is not started from Marek's comment that
several System MMUs can be attached to the same page table
It actually means:
 -> providing the same virtual address space to their master H/W
 -> ** The master H/Ws are attached to the same iommu domain. **

Regards,

KyongHo.
> 
> cheers,
> grant
> 
> >
> > Thank you,
> > KyongHo
> >>
> >> thanks,
> >> grant
> >

  reply	other threads:[~2013-08-08  2:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26 11:28 [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs Cho KyongHo
2013-07-26 17:58 ` Grant Grundler
2013-07-27  9:29   ` Cho KyongHo
2013-07-27 13:54 ` Rob Herring
2013-08-01 13:05   ` Cho KyongHo
2013-08-08 13:09     ` Rob Herring
2013-08-08 21:38       ` Tomasz Figa
2013-08-08 21:43         ` Will Deacon
2013-08-09  2:24           ` Cho KyongHo
2013-07-29  6:37 ` Sachin Kamat
2013-07-29  7:20   ` Cho KyongHo
2013-07-29  7:57   ` Cho KyongHo
2013-07-29  8:05     ` Sachin Kamat
2013-08-01 13:12       ` Cho KyongHo
2013-08-02 17:14 ` Bartlomiej Zolnierkiewicz
2013-08-05 11:16   ` Cho KyongHo
2013-08-05 13:09     ` Bartlomiej Zolnierkiewicz
2013-08-05 13:34       ` Marek Szyprowski
2013-08-06  9:54       ` Cho KyongHo
2013-08-06 13:17         ` Marek Szyprowski
2013-08-06 16:07           ` Grant Grundler
2013-08-07 12:07             ` Cho KyongHo
2013-08-07 16:21               ` Grant Grundler
2013-08-08  2:19                 ` Cho KyongHo [this message]
2013-10-07 13:44 ` Rob Herring
2013-10-08  4:38   ` Cho KyongHo

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='001501ce93dd$b38d23f0$1aa76bd0$@samsung.com' \
    --to=pullip.cho@samsung.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).