> The current exynos-iommu(System MMU) driver does not work autonomouslydisabled
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> before MFC block is power-down not to invalidate IOTLB in the System MMUin the
> when I/O memory mapping is changed. Because A System MMU is resides
> same H/W block, access to control registers of System MMU while the H/WMMUs
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
I intend to make Exynos4412 FIMC-LITEn (Exynos5 CAMIFn) devices child
devices of the FIMC-IS (camera ISP) platform device. This patch reflects
that: http://patchwork.linuxtv.org/patch/16046
This is required since AFAIK FIMC-LITE depends on clocks from FIMC-IS.
By setting fimc-is device as the parent fimc-lite's dependency on it is
resolved without any hacks between these drivers.
Then how this tree will look like after your sysmmu related re-parenting:
fimc-is
/ \
fimc-lite0 fimc-lite1
?
First of all, I think that clock dependency shuold be resolved with
setting the parent of clock descriptor of fimc-lite to the clock
descriptor of fimc-is.
If you are concerning about power management, it is simply resolved with
putting fimc-lite to the power domain of fimc-is.
The above tree will be changed like below after probing System MMU:
sysmmu-fimc-is
I
fimc-is
sysmmu-fimc-lite0
I
fimc-lite0
sysmmu-fimc-lite1
I
fimc-lite1
> Another big change to the driver is the support for devicetree.<mailto:pullip.cho@xxxxxxxxxxx>>
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
Yes, and there is no patch adding this file in this series. Let me paste
it here:
From 88987ff5b77acc7211b9f537a6ef6ea38e3efdd0 Mon Sep 17 00:00:00 2001
From: KyongHo Cho <pullip.cho@xxxxxxxxxxx <mailto:pullip.cho@xxxxxxxxxxx>>
Date: Tue, 11 Dec 2012 14:06:25 +0900
Subject: [PATCH] ARM: EXYNOS: add System MMU definition to DT
This commit adds System MMU nodes to DT of Exynos SoCs.
Signed-off-by: KyongHo Cho <pullip.cho@xxxxxxxxxxxSigned-off-by: Kukjin Kim <kgene.kim@xxxxxxxxxxx<mailto:kgene.kim@xxxxxxxxxxx>>---+++++++++++++++++
.../devicetree/bindings/arm/exynos/system-mmu.txt | 86 ++++++++++++
arch/arm/boot/dts/exynos4210.dtsi | 96 +++++++++++++
arch/arm/boot/dts/exynos4x12.dtsi | 124
arch/arm/boot/dts/exynos5250.dtsi | 147+++++++++++++++++++-4 files changed, 451 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
create mode 100644
a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
diff --git
b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
new file mode 100644peripheral
index 0000000..b33d682
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
@@ -0,0 +1,86 @@
+* Samsung Exynos System MMU
+
+Samsung's Exynos architecture includes System MMU that enables scattered
+physical chunks to be visible as a contiguous region to DMA-capabile
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.format to
+
+System MMU is a sort of IOMMU and support identical translation table
+ARMv7 translation tables with minimum set of page propertiesincluding access+permissions, shareability and security protection. In addition SystemMMU has+another capabilities like L2 TLB or block-fetch buffers to minimizetranslation+latencyThus, it is
+
+Each System MMU is included in the H/W block of a peripheral device.
+important to specify that a System MMU is dedicated to whichperipheral device+before using System MMU. System initialization must specify therelationships+between a System MMU and a peripheral device that owns the System MMU.single device
+
+Some device drivers may control several peripheral devices with a
+descriptor like MFC. Since handling a System MMU with IOMMU APIrequires a+device descriptor that needs the System MMU, it is best to combinethe System+MMUs of the peripheral devices and control them with a single SystemMMU device+descriptor. If it is unable to combine them into a single devicedescriptor,+they can be linked with each other by the means of device.parentrelationship.+number of
+Required properties:
+- compatible: Should be "samsung,exynos-sysmmu".
+- reg: Tuples of base address and size of System MMU registers. The
+ tuples can be more than one if two or more System MMUs arecontrolled+ by a single device descriptor.The number
+- interrupt-parent: The phandle of the interrupt controller of System MMU
+- interrupts: Tuples of numbers that indicates the interrupt source. The
+ number of elements in the tuple is dependent upon
+ 'interrupt-parent' property. The number of tuples in this property
+ must be the same with 'reg' property.
+
+Optional properties:
+- mmuname: Strings of the name of System MMU for debugging purpose.
+ of strings must be the same with the number of tuples in 'reg'
+ property.
As commented on previous patch, this isn't something that belongs here.
But for debugging you could probably retrieve this from the node name ?
Thank you for good idea. However mmuname is an array of strings,
actually. Anyway I agree with your opinion that 'mmuname' is not proper
property of a device node. I will remove it and substitute it with base
register address of a System MMU.
+- mmu-master: phandle to the device node that owns System MMU. Onlythe device+ that is specified whith this property can control SystemMMU with+ IOMMU API.seems natural
+
+Examples:
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it
+to define 2 System MMUs for each port of the MFC:
+port and
+ sysmmu-mfc-l {
+ mmuname = "mfc_l";
+ reg = <0x11210000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <8 5>;
+ mmu-master = <&mfc>;
+ };
+
+ sysmmu-mfc-r {
+ mmuname = "mfc_r";
+ reg = <0x11200000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <6 2>;
+ mmu-master = <&mfc>;
+ };
+
+Actually, MFC device driver requires sub-devices that represents each
+above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r havethe phandles+to those sub-devices.should talk
I find this sentence really difficult to parse. This documentationabout how the device is designed and represented, rather than aboutits driver.OK. I will trying to find another expression easy to understand. Do you
have any suggestion?
+However, it is also a good idea that treats the above System MMUs as
one System+MMU because those System MMUs are actually required by the MFC device:
+
+ sysmmu-mfc {
+ mmuname = "mfc_l", "mfc_r";
+ reg = <0x11210000 0x1000
+ 0x11200000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <8 5
+ 6 2>;
...+ mmu-master = <&mfc>;elements and the
+ };
+
+If System MMU of MFC is defined like the above, the number of
+order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
...diff --git a/arch/arm/boot/dts/exynos5250.dtsib/arch/arm/boot/dts/exynos5250.dtsiindex 2e3b6ef..2ff6d78 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -75,7 +75,7 @@
interrupts = <0 42 0>;
};
+ sysmmu-is0 {I found the syntax of array of resources in the specifications of device
+ mmuname = "isp", "drc", "scalerc", "scalerp", "fd", "mcu";
+ reg = < 0x13260000 0x1000
+ 0x13270000 0x1000
+ 0x13280000 0x1000
+ 0x13290000 0x1000
+ 0x132A0000 0x1000
+ 0x132B0000 0x1000 >;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = < 10 6
+ 11 6
+ 5 2
+ 3 6
+ 5 0
+ 5 4 >;
I believe this should be
interrupts = <10 6>, <11 6>, <5 2>,
<3 6>, <5 0>, <5 4>;
tree. I found that it works correctly.