* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-26 1:53 ` Cho KyongHo
0 siblings, 0 replies; 37+ messages in thread
From: Cho KyongHo @ 2012-12-26 1:53 UTC (permalink / raw)
To: 'Linux ARM Kernel', 'Linux IOMMU',
'Linux Kernel', 'Linux Samsung SOC'
Cc: 'Hyunwoong Kim', 'Joerg Roedel',
'Kukjin Kim', 'Prathyush', 'Rahul Sharma',
'Subash Patel'
notice: v6 patch-set is rebased on next/iommu-exynos branch of
linux-samsung.git. This patch-set does not include 2 patches (05 and 06
patches in v5 patch-se) because they alread exist already in the branch.
The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.
This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.
Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
In addition, this patchset also includes several bug fixes and enhancements
of the current driver.
Change log:
v6:
- Rebased on the branch, next/iommu-exynos of
git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v5:
- new bugfix: patch 01
- Reordered patches
* patch 01 ~ 05: Bugfix and enhancements of the existing driver
* patch 06 ~ 10: Device Tree support and callbacks for power management
* patch 11 : System MMU 3.2 and 3.3 support
* patch 12 ~ 14: Debugging features
- Additional code compaction
v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
device if the client device has multiple System MMUs.
Thanks to Rahul Sharma.
v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
Thanks to Prathyush.
v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction
Patch summary:
[PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
[PATCH v6 02/12] iommu/exynos: always use iommu fault handler
[PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
[PATCH v6 05/12] iommu/exynos: support for device tree
[PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client device
[PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
[PATCH v6 08/12] iommu/exynos: add support for runtime pm and suspend/resume
[PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
[PATCH v6 10/12] iommu/exynos: pass version information from DT
[PATCH v6 11/12] iommu/exynos: add literal name of System MMU for debugging
[PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
Diffstats:
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 27 +-
arch/arm/mach-exynos/Kconfig | 5 -
arch/arm/mach-exynos/Makefile | 1 -
arch/arm/mach-exynos/clock-exynos4.c | 41 +-
arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
arch/arm/mach-exynos/clock-exynos5.c | 87 +-
arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
drivers/iommu/Kconfig | 2 +-
drivers/iommu/Makefile | 2 +-
drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++-------
15 files changed, 1284 insertions(+), 796 deletions(-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-26 1:53 ` Cho KyongHo
0 siblings, 0 replies; 37+ messages in thread
From: Cho KyongHo @ 2012-12-26 1:53 UTC (permalink / raw)
To: 'Linux ARM Kernel', 'Linux IOMMU',
'Linux Kernel', 'Linux Samsung SOC'
Cc: 'Kukjin Kim', 'Hyunwoong Kim',
'Prathyush', 'Subash Patel',
'Rahul Sharma'
notice: v6 patch-set is rebased on next/iommu-exynos branch of
linux-samsung.git. This patch-set does not include 2 patches (05 and 06
patches in v5 patch-se) because they alread exist already in the branch.
The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.
This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.
Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
In addition, this patchset also includes several bug fixes and enhancements
of the current driver.
Change log:
v6:
- Rebased on the branch, next/iommu-exynos of
git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v5:
- new bugfix: patch 01
- Reordered patches
* patch 01 ~ 05: Bugfix and enhancements of the existing driver
* patch 06 ~ 10: Device Tree support and callbacks for power management
* patch 11 : System MMU 3.2 and 3.3 support
* patch 12 ~ 14: Debugging features
- Additional code compaction
v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
device if the client device has multiple System MMUs.
Thanks to Rahul Sharma.
v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
Thanks to Prathyush.
v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction
Patch summary:
[PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
[PATCH v6 02/12] iommu/exynos: always use iommu fault handler
[PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
[PATCH v6 05/12] iommu/exynos: support for device tree
[PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client device
[PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
[PATCH v6 08/12] iommu/exynos: add support for runtime pm and suspend/resume
[PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
[PATCH v6 10/12] iommu/exynos: pass version information from DT
[PATCH v6 11/12] iommu/exynos: add literal name of System MMU for debugging
[PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
Diffstats:
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 27 +-
arch/arm/mach-exynos/Kconfig | 5 -
arch/arm/mach-exynos/Makefile | 1 -
arch/arm/mach-exynos/clock-exynos4.c | 41 +-
arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
arch/arm/mach-exynos/clock-exynos5.c | 87 +-
arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
drivers/iommu/Kconfig | 2 +-
drivers/iommu/Makefile | 2 +-
drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++-------
15 files changed, 1284 insertions(+), 796 deletions(-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-26 1:53 ` Cho KyongHo
0 siblings, 0 replies; 37+ messages in thread
From: Cho KyongHo @ 2012-12-26 1:53 UTC (permalink / raw)
To: linux-arm-kernel
notice: v6 patch-set is rebased on next/iommu-exynos branch of
linux-samsung.git. This patch-set does not include 2 patches (05 and 06
patches in v5 patch-se) because they alread exist already in the branch.
The current exynos-iommu(System MMU) driver does not work autonomously
since it is lack of support for power management of peripheral blocks.
For example, MFC device driver must ensure that its System MMU is disabled
before MFC block is power-down not to invalidate IOTLB in the System MMU
when I/O memory mapping is changed. Because A System MMU is resides in the
same H/W block, access to control registers of System MMU while the H/W
block is turned off must be prohibited.
This set of changes solves the above problem with setting each System MMUs
as the parent of the device which owns the System MMU to recieve the
information when the device is turned off or turned on.
Another big change to the driver is the support for devicetree.
The bindings for System MMU is described in
Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
In addition, this patchset also includes several bug fixes and enhancements
of the current driver.
Change log:
v6:
- Rebased on the branch, next/iommu-exynos of
git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v5:
- new bugfix: patch 01
- Reordered patches
* patch 01 ~ 05: Bugfix and enhancements of the existing driver
* patch 06 ~ 10: Device Tree support and callbacks for power management
* patch 11 : System MMU 3.2 and 3.3 support
* patch 12 ~ 14: Debugging features
- Additional code compaction
v4:
- Remove Change-Id from v3 patches
- Change the order of the third and the first patch
Thanks to Kukjin Kim.
- Fix memory leak when allocating and assigning exynos_iommu_owner to client
device if the client device has multiple System MMUs.
Thanks to Rahul Sharma.
v3:
- Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
- Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
Thanks to Prathyush.
v2:
- Split the patch to iommu/exynos into 9 patches
- Support for System MMU 3.3
- Some code compaction
Patch summary:
[PATCH v6 01/12] iommu/exynos: add missing cache flush for removed pagetable entries
[PATCH v6 02/12] iommu/exynos: always use iommu fault handler
[PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
[PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
[PATCH v6 05/12] iommu/exynos: support for device tree
[PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client device
[PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
[PATCH v6 08/12] iommu/exynos: add support for runtime pm and suspend/resume
[PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
[PATCH v6 10/12] iommu/exynos: pass version information from DT
[PATCH v6 11/12] iommu/exynos: add literal name of System MMU for debugging
[PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
Diffstats:
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
arch/arm/boot/dts/exynos5250.dtsi | 27 +-
arch/arm/mach-exynos/Kconfig | 5 -
arch/arm/mach-exynos/Makefile | 1 -
arch/arm/mach-exynos/clock-exynos4.c | 41 +-
arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
arch/arm/mach-exynos/clock-exynos5.c | 87 +-
arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
drivers/iommu/Kconfig | 2 +-
drivers/iommu/Makefile | 2 +-
drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++-------
15 files changed, 1284 insertions(+), 796 deletions(-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-31 18:18 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2012-12-31 18:18 UTC (permalink / raw)
To: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC'
Cc: 'Hyunwoong Kim', 'Joerg Roedel',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
Cho KyongHo wrote:
>
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
>
> The current exynos-iommu(System MMU) driver does not work
> autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in
> the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System
> MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> In addition, this patchset also includes several bug fixes and
enhancements
> of the current driver.
>
> Change log:
> v6:
> - Rebased on the branch, next/iommu-exynos of
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> v5:
> - new bugfix: patch 01
> - Reordered patches
> * patch 01 ~ 05: Bugfix and enhancements of the existing driver
> * patch 06 ~ 10: Device Tree support and callbacks for power management
> * patch 11 : System MMU 3.2 and 3.3 support
> * patch 12 ~ 14: Debugging features
> - Additional code compaction
>
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
> Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to
> client
> device if the client device has multiple System MMUs.
> Thanks to Rahul Sharma.
>
> v3:
> - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
> Thanks to Prathyush.
>
> v2:
> - Split the patch to iommu/exynos into 9 patches
> - Support for System MMU 3.3
> - Some code compaction
>
> Patch summary:
> [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed
> pagetable entries
> [PATCH v6 02/12] iommu/exynos: always use iommu fault handler
> [PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
> [PATCH v6 05/12] iommu/exynos: support for device tree
> [PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client
> device
> [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from
> exynos tree
> [PATCH v6 08/12] iommu/exynos: add support for runtime pm and
> suspend/resume
> [PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
> [PATCH v6 10/12] iommu/exynos: pass version information from DT
> [PATCH v6 11/12] iommu/exynos: add literal name of System MMU for
> debugging
> [PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
>
> Diffstats:
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> arch/arm/mach-exynos/Kconfig | 5 -
> arch/arm/mach-exynos/Makefile | 1 -
> arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> drivers/iommu/Kconfig | 2 +-
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> -----
> 15 files changed, 1284 insertions(+), 796 deletions(-)
Looks OK to me, and some guys tested this series on board.
Joerg, it's time to merge this. If you don't mind, let me pick up this whole
series into Samsung tree because this touches many Samsung stuff.
Any problems/comments on this, let me know.
Happy new year, thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-31 18:18 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2012-12-31 18:18 UTC (permalink / raw)
To: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC'
Cc: 'Rahul Sharma', 'Subash Patel',
'Hyunwoong Kim', 'Prathyush'
Cho KyongHo wrote:
>
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
>
> The current exynos-iommu(System MMU) driver does not work
> autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in
> the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System
> MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> In addition, this patchset also includes several bug fixes and
enhancements
> of the current driver.
>
> Change log:
> v6:
> - Rebased on the branch, next/iommu-exynos of
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> v5:
> - new bugfix: patch 01
> - Reordered patches
> * patch 01 ~ 05: Bugfix and enhancements of the existing driver
> * patch 06 ~ 10: Device Tree support and callbacks for power management
> * patch 11 : System MMU 3.2 and 3.3 support
> * patch 12 ~ 14: Debugging features
> - Additional code compaction
>
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
> Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to
> client
> device if the client device has multiple System MMUs.
> Thanks to Rahul Sharma.
>
> v3:
> - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
> Thanks to Prathyush.
>
> v2:
> - Split the patch to iommu/exynos into 9 patches
> - Support for System MMU 3.3
> - Some code compaction
>
> Patch summary:
> [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed
> pagetable entries
> [PATCH v6 02/12] iommu/exynos: always use iommu fault handler
> [PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
> [PATCH v6 05/12] iommu/exynos: support for device tree
> [PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client
> device
> [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from
> exynos tree
> [PATCH v6 08/12] iommu/exynos: add support for runtime pm and
> suspend/resume
> [PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
> [PATCH v6 10/12] iommu/exynos: pass version information from DT
> [PATCH v6 11/12] iommu/exynos: add literal name of System MMU for
> debugging
> [PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
>
> Diffstats:
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> arch/arm/mach-exynos/Kconfig | 5 -
> arch/arm/mach-exynos/Makefile | 1 -
> arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> drivers/iommu/Kconfig | 2 +-
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> -----
> 15 files changed, 1284 insertions(+), 796 deletions(-)
Looks OK to me, and some guys tested this series on board.
Joerg, it's time to merge this. If you don't mind, let me pick up this whole
series into Samsung tree because this touches many Samsung stuff.
Any problems/comments on this, let me know.
Happy new year, thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2012-12-31 18:18 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2012-12-31 18:18 UTC (permalink / raw)
To: linux-arm-kernel
Cho KyongHo wrote:
>
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
>
> The current exynos-iommu(System MMU) driver does not work
> autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is
> disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in
> the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System
> MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> In addition, this patchset also includes several bug fixes and
enhancements
> of the current driver.
>
> Change log:
> v6:
> - Rebased on the branch, next/iommu-exynos of
> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> v5:
> - new bugfix: patch 01
> - Reordered patches
> * patch 01 ~ 05: Bugfix and enhancements of the existing driver
> * patch 06 ~ 10: Device Tree support and callbacks for power management
> * patch 11 : System MMU 3.2 and 3.3 support
> * patch 12 ~ 14: Debugging features
> - Additional code compaction
>
> v4:
> - Remove Change-Id from v3 patches
> - Change the order of the third and the first patch
> Thanks to Kukjin Kim.
> - Fix memory leak when allocating and assigning exynos_iommu_owner to
> client
> device if the client device has multiple System MMUs.
> Thanks to Rahul Sharma.
>
> v3:
> - Fix prefetch buffer flag definition for System MMU 3.3 (patch 10/12)
> - Fix incorrect setting for SET_RUNTIME_PM_OPS (patch 09/12)
> Thanks to Prathyush.
>
> v2:
> - Split the patch to iommu/exynos into 9 patches
> - Support for System MMU 3.3
> - Some code compaction
>
> Patch summary:
> [PATCH v6 01/12] iommu/exynos: add missing cache flush for removed
> pagetable entries
> [PATCH v6 02/12] iommu/exynos: always use iommu fault handler
> [PATCH v6 03/12] iommu/exynos: allocate lv2 page table from own slab
> [PATCH v6 04/12] iommu/exynos: change rwlock to spinlock
> [PATCH v6 05/12] iommu/exynos: support for device tree
> [PATCH v6 06/12] iommu/exynos: set System MMU as the parent of client
> device
> [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from
> exynos tree
> [PATCH v6 08/12] iommu/exynos: add support for runtime pm and
> suspend/resume
> [PATCH v6 09/12] iommu/exynos: add support for System MMU 3.2 and 3.3
> [PATCH v6 10/12] iommu/exynos: pass version information from DT
> [PATCH v6 11/12] iommu/exynos: add literal name of System MMU for
> debugging
> [PATCH v6 12/12] iommu/exynos: add debugfs entries for System MMU
>
> Diffstats:
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> arch/arm/mach-exynos/Kconfig | 5 -
> arch/arm/mach-exynos/Makefile | 1 -
> arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> drivers/iommu/Kconfig | 2 +-
> drivers/iommu/Makefile | 2 +-
> drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> -----
> 15 files changed, 1284 insertions(+), 796 deletions(-)
Looks OK to me, and some guys tested this series on board.
Joerg, it's time to merge this. If you don't mind, let me pick up this whole
series into Samsung tree because this touches many Samsung stuff.
Any problems/comments on this, let me know.
Happy new year, thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2012-12-26 1:53 ` Cho KyongHo
@ 2013-01-03 23:18 ` Sylwester Nawrocki
-1 siblings, 0 replies; 37+ messages in thread
From: Sylwester Nawrocki @ 2013-01-03 23:18 UTC (permalink / raw)
To: Cho KyongHo
Cc: 'Linux ARM Kernel', 'Linux IOMMU',
'Linux Kernel', 'Linux Samsung SOC',
'Hyunwoong Kim', 'Joerg Roedel',
'Kukjin Kim', 'Prathyush', 'Rahul Sharma',
'Subash Patel',
Marek Szyprowski, Tomasz Figa, devicetree-discuss
Hi,
Cc: devicetree-discuss <devicetree-discuss@lists.ozlabs.org>
On 12/26/2012 02:53 AM, Cho KyongHo wrote:
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
>
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System MMUs
> 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
?
> Another big change to the driver is the support for devicetree.
> 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@samsung.com>
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@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
.../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(-)
create mode 100644
Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
new file mode 100644
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
peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is a sort of IOMMU and support identical translation table
format to
+ARMv7 translation tables with minimum set of page properties including
access
+permissions, shareability and security protection. In addition System
MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize
translation
+latency
+
+Each System MMU is included in the H/W block of a peripheral device.
Thus, it is
+important to specify that a System MMU is dedicated to which peripheral
device
+before using System MMU. System initialization must specify the
relationships
+between a System MMU and a peripheral device that owns the System MMU.
+
+Some device drivers may control several peripheral devices with a
single device
+descriptor like MFC. Since handling a System MMU with IOMMU API requires a
+device descriptor that needs the System MMU, it is best to combine the
System
+MMUs of the peripheral devices and control them with a single System
MMU device
+descriptor. If it is unable to combine them into a single device
descriptor,
+they can be linked with each other by the means of device.parent
relationship.
+
+Required properties:
+- compatible: Should be "samsung,exynos-sysmmu".
+- reg: Tuples of base address and size of System MMU registers. The
number of
+ tuples can be more than one if two or more System MMUs are
controlled
+ by a single device descriptor.
+- 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. The
number
+ 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 ?
+- mmu-master: phandle to the device node that owns System MMU. Only the
device
+ that is specified whith this property can control System MMU with
+ IOMMU API.
+
+Examples:
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it seems
natural
+to define 2 System MMUs for each port of the MFC:
+
+ 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
port and
+above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have the
phandles
+to those sub-devices.
I find this sentence really difficult to parse. This documentation
should talk
about how the device is designed and represented, rather than about its
driver.
+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>;
+ };
+
+If System MMU of MFC is defined like the above, the number of elements
and the
+order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index e31bfc4..1c134b2 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -76,4 +76,100 @@
reg = <0x100C0000 0x100>;
interrupts = <2 4>;
};
+
+ sysmmu-mfcL {
This capitalization looks weird. How about just making it sysmmu-mfc-l ?
+ mmuname = "mfc_l";
+ reg = <0x13620000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 5>;
+ };
+
+ sysmmu-mfcR {
and sysmmu-mfc-r ?
Hmm, you actually have it defined this way for exynos5250...
+ mmuname = "mfc_r";
+ reg = <0x13630000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 6>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x13E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 4>;
+ };
+
+ sysmmu-fimc0 {
+ mmuname = "fimc0";
+ reg = <0x11A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-fimc1 {
+ mmuname = "fimc1";
+ reg = <0x11A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 3>;
+ };
+
+ sysmmu-fimc2 {
+ mmuname = "fimc2";
+ reg = <0x11A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 4>;
+ };
+
+ sysmmu-fimc3 {
+ mmuname = "fimc3";
+ reg = <0x11A50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 6>;
+ };
+
+ sysmmu-g2d {
+ mmuname = "g2d";
+ reg = <0x12A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 7>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x12A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 0>;
+ };
+
+ sysmmu-fimd0 {
+ mmuname = "fimd0";
+ reg = <0x11E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 2>;
+ };
+
+ sysmmu-fimd1 {
+ mmuname = "fimd1";
+ reg = <0x12220000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 3>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 179a62e..0c6d001 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -66,4 +66,128 @@
reg = <0x106E0000 0x1000>;
interrupts = <0 72 0>;
};
+
+ sysmmu-mfcL {
+ mmuname = "mfc_l";
+ reg = <0x13620000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 5>;
+ };
+
+ sysmmu-mfcR {
+ mmuname = "mfc_r";
+ reg = <0x13630000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 6>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x13E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 4>;
+ };
+
+ sysmmu-fimc0 {
+ mmuname = "fimc0";
+ reg = <0x11A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-fimc1 {
+ mmuname = "fimc1";
+ reg = <0x11A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 3>;
+ };
+
+ sysmmu-fimc2 {
+ mmuname = "fimc2";
+ reg = <0x11A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 4>;
+ };
+
+ sysmmu-fimc3 {
+ mmuname = "fimc3";
+ reg = <0x11A50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 6>;
+ };
+
+ sysmmu-g2d {
+ mmuname = "g2d";
+ reg = <0x10A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 7>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x12A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 0>;
+ };
+
+ sysmmu-fimd0 {
+ mmuname = "fimd0";
+ reg = <0x11E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 2>;
+ };
+
+ sysmmu-is0 {
+ mmuname = "isp", "drc", "fd";
+ reg = < 0x12260000 0x1000
+ 0x12270000 0x1000
+ 0x122A0000 0x1000 >;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = < 16 2
+ 16 3
+ 16 4 >;
+ };
+
+ sysmmu-is1 {
+ mmuname = "ispcpu";
+ reg = <0x122B0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 5>;
+ };
+
+ sysmmu-flite0 {
+ mmuname = "fimc-lite0";
+ reg = <0x123B0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 0>;
+ };
+
+ sysmmu-flite1 {
+ mmuname = "fimc-lite1";
+ reg = <0x123C0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 1>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 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>;
};
- codec@11000000 {
+ mfc: codec@11000000 {
compatible = "samsung,mfc-v6";
reg = <0x11000000 0x10000>;
interrupts = <0 96 0>;
@@ -578,9 +578,152 @@
interrupts = <0 95 0>;
};
- mixer {
+ mixer: mixer {
compatible = "samsung,exynos5-mixer";
reg = <0x14450000 0x10000>;
interrupts = <0 94 0>;
};
+
+ 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>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x14650000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <7 4>;
+ mmu-master = <&mixer>;
+ };
+
+ sysmmu-gsc0 {
+ mmuname = "gsc0";
+ reg = <0x13E80000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 0>;
+ mmu-master = <&gsc_0>;
+ };
+
+ sysmmu-gsc1 {
+ mmuname = "gsc1";
+ reg = <0x13E90000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>;
+ mmu-master = <&gsc_1>;
+ };
+
+ sysmmu-gsc2 {
+ mmuname = "gsc2";
+ reg = <0x13EA0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 4>;
+ mmu-master = <&gsc_2>;
+ };
+
+ sysmmu-gsc3 {
+ mmuname = "gsc3";
+ reg = <0x13EB0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 6>;
+ mmu-master = <&gsc_3>;
+ };
+
+ sysmmu-fimd1 {
+ mmuname = "fimd1";
+ reg = <0x14640000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <3 2>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x11D40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 0>;
+ };
+
+ sysmmu-is0 {
+ 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>;
+ };
+
+ sysmmu-is1 {
+ mmuname = "odc", "dis0", "dis1", "3dnr";
+ reg = < 0x132C0000 0x1000
+ 0x132D0000 0x1000
+ 0x132E0000 0x1000
+ 0x132F0000 0x1000 >;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = < 11 0
+ 10 4
+ 9 4
+ 5 6 >;
Ditto.
+ };
+
+ sysmmu-2d {
+ mmuname = "2d";
+ reg = <0x10A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <24 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11F20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-flite0 {
+ mmuname = "flite0";
+ reg = <0x13C40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <3 4>;
+ };
+
+ sysmmu-flite1 {
+ mmuname = "flite1";
+ reg = <0x13C50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <24 1>;
+ };
};
--
Thanks,
Sylwester
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-03 23:18 ` Sylwester Nawrocki
0 siblings, 0 replies; 37+ messages in thread
From: Sylwester Nawrocki @ 2013-01-03 23:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Cc: devicetree-discuss <devicetree-discuss@lists.ozlabs.org>
On 12/26/2012 02:53 AM, Cho KyongHo wrote:
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
>
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System MMUs
> 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
?
> Another big change to the driver is the support for devicetree.
> 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@samsung.com>
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@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
.../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(-)
create mode 100644
Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
new file mode 100644
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
peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is a sort of IOMMU and support identical translation table
format to
+ARMv7 translation tables with minimum set of page properties including
access
+permissions, shareability and security protection. In addition System
MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize
translation
+latency
+
+Each System MMU is included in the H/W block of a peripheral device.
Thus, it is
+important to specify that a System MMU is dedicated to which peripheral
device
+before using System MMU. System initialization must specify the
relationships
+between a System MMU and a peripheral device that owns the System MMU.
+
+Some device drivers may control several peripheral devices with a
single device
+descriptor like MFC. Since handling a System MMU with IOMMU API requires a
+device descriptor that needs the System MMU, it is best to combine the
System
+MMUs of the peripheral devices and control them with a single System
MMU device
+descriptor. If it is unable to combine them into a single device
descriptor,
+they can be linked with each other by the means of device.parent
relationship.
+
+Required properties:
+- compatible: Should be "samsung,exynos-sysmmu".
+- reg: Tuples of base address and size of System MMU registers. The
number of
+ tuples can be more than one if two or more System MMUs are
controlled
+ by a single device descriptor.
+- 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. The
number
+ 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 ?
+- mmu-master: phandle to the device node that owns System MMU. Only the
device
+ that is specified whith this property can control System MMU with
+ IOMMU API.
+
+Examples:
+
+MFC has 2 System MMUs for each port that MFC is attached. Thus it seems
natural
+to define 2 System MMUs for each port of the MFC:
+
+ 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
port and
+above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have the
phandles
+to those sub-devices.
I find this sentence really difficult to parse. This documentation
should talk
about how the device is designed and represented, rather than about its
driver.
+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>;
+ };
+
+If System MMU of MFC is defined like the above, the number of elements
and the
+order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index e31bfc4..1c134b2 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -76,4 +76,100 @@
reg = <0x100C0000 0x100>;
interrupts = <2 4>;
};
+
+ sysmmu-mfcL {
This capitalization looks weird. How about just making it sysmmu-mfc-l ?
+ mmuname = "mfc_l";
+ reg = <0x13620000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 5>;
+ };
+
+ sysmmu-mfcR {
and sysmmu-mfc-r ?
Hmm, you actually have it defined this way for exynos5250...
+ mmuname = "mfc_r";
+ reg = <0x13630000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 6>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x13E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 4>;
+ };
+
+ sysmmu-fimc0 {
+ mmuname = "fimc0";
+ reg = <0x11A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-fimc1 {
+ mmuname = "fimc1";
+ reg = <0x11A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 3>;
+ };
+
+ sysmmu-fimc2 {
+ mmuname = "fimc2";
+ reg = <0x11A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 4>;
+ };
+
+ sysmmu-fimc3 {
+ mmuname = "fimc3";
+ reg = <0x11A50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 6>;
+ };
+
+ sysmmu-g2d {
+ mmuname = "g2d";
+ reg = <0x12A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 7>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x12A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 0>;
+ };
+
+ sysmmu-fimd0 {
+ mmuname = "fimd0";
+ reg = <0x11E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 2>;
+ };
+
+ sysmmu-fimd1 {
+ mmuname = "fimd1";
+ reg = <0x12220000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 3>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 179a62e..0c6d001 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -66,4 +66,128 @@
reg = <0x106E0000 0x1000>;
interrupts = <0 72 0>;
};
+
+ sysmmu-mfcL {
+ mmuname = "mfc_l";
+ reg = <0x13620000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 5>;
+ };
+
+ sysmmu-mfcR {
+ mmuname = "mfc_r";
+ reg = <0x13630000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 6>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x13E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 4>;
+ };
+
+ sysmmu-fimc0 {
+ mmuname = "fimc0";
+ reg = <0x11A20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-fimc1 {
+ mmuname = "fimc1";
+ reg = <0x11A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 3>;
+ };
+
+ sysmmu-fimc2 {
+ mmuname = "fimc2";
+ reg = <0x11A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 4>;
+ };
+
+ sysmmu-fimc3 {
+ mmuname = "fimc3";
+ reg = <0x11A50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 6>;
+ };
+
+ sysmmu-g2d {
+ mmuname = "g2d";
+ reg = <0x10A40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 7>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x12A30000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 0>;
+ };
+
+ sysmmu-fimd0 {
+ mmuname = "fimd0";
+ reg = <0x11E20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <5 2>;
+ };
+
+ sysmmu-is0 {
+ mmuname = "isp", "drc", "fd";
+ reg = < 0x12260000 0x1000
+ 0x12270000 0x1000
+ 0x122A0000 0x1000 >;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = < 16 2
+ 16 3
+ 16 4 >;
+ };
+
+ sysmmu-is1 {
+ mmuname = "ispcpu";
+ reg = <0x122B0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 5>;
+ };
+
+ sysmmu-flite0 {
+ mmuname = "fimc-lite0";
+ reg = <0x123B0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 0>;
+ };
+
+ sysmmu-flite1 {
+ mmuname = "fimc-lite1";
+ reg = <0x123C0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <16 1>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 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>;
};
- codec at 11000000 {
+ mfc: codec at 11000000 {
compatible = "samsung,mfc-v6";
reg = <0x11000000 0x10000>;
interrupts = <0 96 0>;
@@ -578,9 +578,152 @@
interrupts = <0 95 0>;
};
- mixer {
+ mixer: mixer {
compatible = "samsung,exynos5-mixer";
reg = <0x14450000 0x10000>;
interrupts = <0 94 0>;
};
+
+ 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>;
+ };
+
+ sysmmu-tv {
+ mmuname = "tv";
+ reg = <0x14650000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <7 4>;
+ mmu-master = <&mixer>;
+ };
+
+ sysmmu-gsc0 {
+ mmuname = "gsc0";
+ reg = <0x13E80000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 0>;
+ mmu-master = <&gsc_0>;
+ };
+
+ sysmmu-gsc1 {
+ mmuname = "gsc1";
+ reg = <0x13E90000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>;
+ mmu-master = <&gsc_1>;
+ };
+
+ sysmmu-gsc2 {
+ mmuname = "gsc2";
+ reg = <0x13EA0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 4>;
+ mmu-master = <&gsc_2>;
+ };
+
+ sysmmu-gsc3 {
+ mmuname = "gsc3";
+ reg = <0x13EB0000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 6>;
+ mmu-master = <&gsc_3>;
+ };
+
+ sysmmu-fimd1 {
+ mmuname = "fimd1";
+ reg = <0x14640000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <3 2>;
+ };
+
+ sysmmu-rotator {
+ mmuname = "rotator";
+ reg = <0x11D40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 0>;
+ };
+
+ sysmmu-is0 {
+ 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>;
+ };
+
+ sysmmu-is1 {
+ mmuname = "odc", "dis0", "dis1", "3dnr";
+ reg = < 0x132C0000 0x1000
+ 0x132D0000 0x1000
+ 0x132E0000 0x1000
+ 0x132F0000 0x1000 >;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = < 11 0
+ 10 4
+ 9 4
+ 5 6 >;
Ditto.
+ };
+
+ sysmmu-2d {
+ mmuname = "2d";
+ reg = <0x10A60000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <24 5>;
+ };
+
+ sysmmu-jpeg {
+ mmuname = "jpeg";
+ reg = <0x11F20000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <4 2>;
+ };
+
+ sysmmu-flite0 {
+ mmuname = "flite0";
+ reg = <0x13C40000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <3 4>;
+ };
+
+ sysmmu-flite1 {
+ mmuname = "flite1";
+ reg = <0x13C50000 0x1000>;
+ compatible = "samsung,exynos-sysmmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <24 1>;
+ };
};
--
Thanks,
Sylwester
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-03 23:18 ` Sylwester Nawrocki
@ 2013-01-07 10:45 ` KyongHo Cho
-1 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-07 10:45 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Kukjin Kim, Hyunwoong Kim, Prathyush, devicetree-discuss,
Linux Kernel, Subash Patel, Linux IOMMU, Linux Samsung SOC,
Tomasz Figa, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rahul Sharma
[-- Attachment #1.1: Type: text/plain, Size: 23560 bytes --]
2013. 1. 4. 오전 8:32에 "Sylwester Nawrocki" <sylvester.nawrocki@gmail.com>님이
작성:
>
> Hi,
>
> Cc: devicetree-discuss <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>
>
>
> On 12/26/2012 02:53 AM, Cho KyongHo wrote:
>>
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>>
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is
disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in
the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System
MMUs
>> 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.
>> 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> 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-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> .../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(-)
> create mode 100644
Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
> new file mode 100644
> 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
peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table
format to
> +ARMv7 translation tables with minimum set of page properties including
access
> +permissions, shareability and security protection. In addition System
MMU has
> +another capabilities like L2 TLB or block-fetch buffers to minimize
translation
> +latency
> +
> +Each System MMU is included in the H/W block of a peripheral device.
Thus, it is
> +important to specify that a System MMU is dedicated to which peripheral
device
> +before using System MMU. System initialization must specify the
relationships
> +between a System MMU and a peripheral device that owns the System MMU.
> +
> +Some device drivers may control several peripheral devices with a single
device
> +descriptor like MFC. Since handling a System MMU with IOMMU API requires
a
> +device descriptor that needs the System MMU, it is best to combine the
System
> +MMUs of the peripheral devices and control them with a single System MMU
device
> +descriptor. If it is unable to combine them into a single device
descriptor,
> +they can be linked with each other by the means of device.parent
relationship.
> +
> +Required properties:
> +- compatible: Should be "samsung,exynos-sysmmu".
> +- reg: Tuples of base address and size of System MMU registers. The
number of
> + tuples can be more than one if two or more System MMUs are
controlled
> + by a single device descriptor.
> +- 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. The
number
> + 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. Only the
device
> + that is specified whith this property can control System MMU
with
> + IOMMU API.
> +
> +Examples:
> +
> +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems
natural
> +to define 2 System MMUs for each port of the MFC:
> +
> + 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
port and
> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have the
phandles
> +to those sub-devices.
>
> I find this sentence really difficult to parse. This documentation should
talk
> about how the device is designed and represented, rather than about its
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>;
> + };
> +
> +If System MMU of MFC is defined like the above, the number of elements
and the
> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
> index e31bfc4..1c134b2 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -76,4 +76,100 @@
> reg = <0x100C0000 0x100>;
> interrupts = <2 4>;
> };
> +
> + sysmmu-mfcL {
>
> This capitalization looks weird. How about just making it sysmmu-mfc-l ?
OK. That looks better.
>
> + mmuname = "mfc_l";
> + reg = <0x13620000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 5>;
> + };
> +
> + sysmmu-mfcR {
>
> and sysmmu-mfc-r ?
>
> Hmm, you actually have it defined this way for exynos5250...
Oh really I did. I will make it better.
>
> + mmuname = "mfc_r";
> + reg = <0x13630000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 6>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x13E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 4>;
> + };
> +
> + sysmmu-fimc0 {
> + mmuname = "fimc0";
> + reg = <0x11A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-fimc1 {
> + mmuname = "fimc1";
> + reg = <0x11A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 3>;
> + };
> +
> + sysmmu-fimc2 {
> + mmuname = "fimc2";
> + reg = <0x11A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 4>;
> + };
> +
> + sysmmu-fimc3 {
> + mmuname = "fimc3";
> + reg = <0x11A50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 6>;
> + };
> +
> + sysmmu-g2d {
> + mmuname = "g2d";
> + reg = <0x12A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 7>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x12A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 0>;
> + };
> +
> + sysmmu-fimd0 {
> + mmuname = "fimd0";
> + reg = <0x11E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 2>;
> + };
> +
> + sysmmu-fimd1 {
> + mmuname = "fimd1";
> + reg = <0x12220000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
> index 179a62e..0c6d001 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -66,4 +66,128 @@
> reg = <0x106E0000 0x1000>;
> interrupts = <0 72 0>;
> };
> +
> + sysmmu-mfcL {
> + mmuname = "mfc_l";
> + reg = <0x13620000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 5>;
> + };
> +
> + sysmmu-mfcR {
> + mmuname = "mfc_r";
> + reg = <0x13630000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 6>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x13E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 4>;
> + };
> +
> + sysmmu-fimc0 {
> + mmuname = "fimc0";
> + reg = <0x11A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-fimc1 {
> + mmuname = "fimc1";
> + reg = <0x11A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 3>;
> + };
> +
> + sysmmu-fimc2 {
> + mmuname = "fimc2";
> + reg = <0x11A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 4>;
> + };
> +
> + sysmmu-fimc3 {
> + mmuname = "fimc3";
> + reg = <0x11A50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 6>;
> + };
> +
> + sysmmu-g2d {
> + mmuname = "g2d";
> + reg = <0x10A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 7>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x12A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 0>;
> + };
> +
> + sysmmu-fimd0 {
> + mmuname = "fimd0";
> + reg = <0x11E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 2>;
> + };
> +
> + sysmmu-is0 {
> + mmuname = "isp", "drc", "fd";
> + reg = < 0x12260000 0x1000
> + 0x12270000 0x1000
> + 0x122A0000 0x1000 >;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = < 16 2
> + 16 3
> + 16 4 >;
> + };
> +
> + sysmmu-is1 {
> + mmuname = "ispcpu";
> + reg = <0x122B0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 5>;
> + };
> +
> + sysmmu-flite0 {
> + mmuname = "fimc-lite0";
> + reg = <0x123B0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 0>;
> + };
> +
> + sysmmu-flite1 {
> + mmuname = "fimc-lite1";
> + reg = <0x123C0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 1>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
> index 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>;
> };
>
> - codec@11000000 {
> + mfc: codec@11000000 {
> compatible = "samsung,mfc-v6";
> reg = <0x11000000 0x10000>;
> interrupts = <0 96 0>;
> @@ -578,9 +578,152 @@
> interrupts = <0 95 0>;
> };
>
> - mixer {
> + mixer: mixer {
> compatible = "samsung,exynos5-mixer";
> reg = <0x14450000 0x10000>;
> interrupts = <0 94 0>;
> };
> +
> + 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>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x14650000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <7 4>;
> + mmu-master = <&mixer>;
> + };
> +
> + sysmmu-gsc0 {
> + mmuname = "gsc0";
> + reg = <0x13E80000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 0>;
> + mmu-master = <&gsc_0>;
> + };
> +
> + sysmmu-gsc1 {
> + mmuname = "gsc1";
> + reg = <0x13E90000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 2>;
> + mmu-master = <&gsc_1>;
> + };
> +
> + sysmmu-gsc2 {
> + mmuname = "gsc2";
> + reg = <0x13EA0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 4>;
> + mmu-master = <&gsc_2>;
> + };
> +
> + sysmmu-gsc3 {
> + mmuname = "gsc3";
> + reg = <0x13EB0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 6>;
> + mmu-master = <&gsc_3>;
> + };
> +
> + sysmmu-fimd1 {
> + mmuname = "fimd1";
> + reg = <0x14640000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <3 2>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x11D40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 0>;
> + };
> +
> + sysmmu-is0 {
> + 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>;
>
I found the syntax of array of resources in the specifications of device
tree. I found that it works correctly.
> + };
> +
> + sysmmu-is1 {
> + mmuname = "odc", "dis0", "dis1", "3dnr";
> + reg = < 0x132C0000 0x1000
> + 0x132D0000 0x1000
> + 0x132E0000 0x1000
> + 0x132F0000 0x1000 >;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = < 11 0
> + 10 4
> + 9 4
> + 5 6 >;
>
> Ditto.
>
> + };
> +
> + sysmmu-2d {
> + mmuname = "2d";
> + reg = <0x10A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <24 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11F20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-flite0 {
> + mmuname = "flite0";
> + reg = <0x13C40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <3 4>;
> + };
> +
> + sysmmu-flite1 {
> + mmuname = "flite1";
> + reg = <0x13C50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <24 1>;
> + };
> };
>
> --
>
> Thanks,
> Sylwester
>
Thank you for kind review.
KyongHo
[-- Attachment #1.2: Type: text/html, Size: 33092 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-07 10:45 ` KyongHo Cho
0 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-07 10:45 UTC (permalink / raw)
To: linux-arm-kernel
2013. 1. 4. ?? 8:32? "Sylwester Nawrocki" <sylvester.nawrocki@gmail.com>??
??:
>
> Hi,
>
> Cc: devicetree-discuss <devicetree-discuss@lists.ozlabs.org>
>
>
> On 12/26/2012 02:53 AM, Cho KyongHo wrote:
>>
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>>
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is
disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in
the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System
MMUs
>> 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.
>> 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@samsung.com>
> 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@samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> .../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(-)
> create mode 100644
Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
> new file mode 100644
> 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
peripheral
> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
> +
> +System MMU is a sort of IOMMU and support identical translation table
format to
> +ARMv7 translation tables with minimum set of page properties including
access
> +permissions, shareability and security protection. In addition System
MMU has
> +another capabilities like L2 TLB or block-fetch buffers to minimize
translation
> +latency
> +
> +Each System MMU is included in the H/W block of a peripheral device.
Thus, it is
> +important to specify that a System MMU is dedicated to which peripheral
device
> +before using System MMU. System initialization must specify the
relationships
> +between a System MMU and a peripheral device that owns the System MMU.
> +
> +Some device drivers may control several peripheral devices with a single
device
> +descriptor like MFC. Since handling a System MMU with IOMMU API requires
a
> +device descriptor that needs the System MMU, it is best to combine the
System
> +MMUs of the peripheral devices and control them with a single System MMU
device
> +descriptor. If it is unable to combine them into a single device
descriptor,
> +they can be linked with each other by the means of device.parent
relationship.
> +
> +Required properties:
> +- compatible: Should be "samsung,exynos-sysmmu".
> +- reg: Tuples of base address and size of System MMU registers. The
number of
> + tuples can be more than one if two or more System MMUs are
controlled
> + by a single device descriptor.
> +- 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. The
number
> + 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. Only the
device
> + that is specified whith this property can control System MMU
with
> + IOMMU API.
> +
> +Examples:
> +
> +MFC has 2 System MMUs for each port that MFC is attached. Thus it seems
natural
> +to define 2 System MMUs for each port of the MFC:
> +
> + 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
port and
> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have the
phandles
> +to those sub-devices.
>
> I find this sentence really difficult to parse. This documentation should
talk
> about how the device is designed and represented, rather than about its
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>;
> + };
> +
> +If System MMU of MFC is defined like the above, the number of elements
and the
> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
> index e31bfc4..1c134b2 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -76,4 +76,100 @@
> reg = <0x100C0000 0x100>;
> interrupts = <2 4>;
> };
> +
> + sysmmu-mfcL {
>
> This capitalization looks weird. How about just making it sysmmu-mfc-l ?
OK. That looks better.
>
> + mmuname = "mfc_l";
> + reg = <0x13620000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 5>;
> + };
> +
> + sysmmu-mfcR {
>
> and sysmmu-mfc-r ?
>
> Hmm, you actually have it defined this way for exynos5250...
Oh really I did. I will make it better.
>
> + mmuname = "mfc_r";
> + reg = <0x13630000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 6>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x13E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 4>;
> + };
> +
> + sysmmu-fimc0 {
> + mmuname = "fimc0";
> + reg = <0x11A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-fimc1 {
> + mmuname = "fimc1";
> + reg = <0x11A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 3>;
> + };
> +
> + sysmmu-fimc2 {
> + mmuname = "fimc2";
> + reg = <0x11A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 4>;
> + };
> +
> + sysmmu-fimc3 {
> + mmuname = "fimc3";
> + reg = <0x11A50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 6>;
> + };
> +
> + sysmmu-g2d {
> + mmuname = "g2d";
> + reg = <0x12A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 7>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x12A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 0>;
> + };
> +
> + sysmmu-fimd0 {
> + mmuname = "fimd0";
> + reg = <0x11E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 2>;
> + };
> +
> + sysmmu-fimd1 {
> + mmuname = "fimd1";
> + reg = <0x12220000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
> index 179a62e..0c6d001 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -66,4 +66,128 @@
> reg = <0x106E0000 0x1000>;
> interrupts = <0 72 0>;
> };
> +
> + sysmmu-mfcL {
> + mmuname = "mfc_l";
> + reg = <0x13620000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 5>;
> + };
> +
> + sysmmu-mfcR {
> + mmuname = "mfc_r";
> + reg = <0x13630000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 6>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x13E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 4>;
> + };
> +
> + sysmmu-fimc0 {
> + mmuname = "fimc0";
> + reg = <0x11A20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-fimc1 {
> + mmuname = "fimc1";
> + reg = <0x11A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 3>;
> + };
> +
> + sysmmu-fimc2 {
> + mmuname = "fimc2";
> + reg = <0x11A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 4>;
> + };
> +
> + sysmmu-fimc3 {
> + mmuname = "fimc3";
> + reg = <0x11A50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 6>;
> + };
> +
> + sysmmu-g2d {
> + mmuname = "g2d";
> + reg = <0x10A40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 7>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x12A30000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 0>;
> + };
> +
> + sysmmu-fimd0 {
> + mmuname = "fimd0";
> + reg = <0x11E20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <5 2>;
> + };
> +
> + sysmmu-is0 {
> + mmuname = "isp", "drc", "fd";
> + reg = < 0x12260000 0x1000
> + 0x12270000 0x1000
> + 0x122A0000 0x1000 >;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = < 16 2
> + 16 3
> + 16 4 >;
> + };
> +
> + sysmmu-is1 {
> + mmuname = "ispcpu";
> + reg = <0x122B0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 5>;
> + };
> +
> + sysmmu-flite0 {
> + mmuname = "fimc-lite0";
> + reg = <0x123B0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 0>;
> + };
> +
> + sysmmu-flite1 {
> + mmuname = "fimc-lite1";
> + reg = <0x123C0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <16 1>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
> index 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>;
> };
>
> - codec at 11000000 {
> + mfc: codec at 11000000 {
> compatible = "samsung,mfc-v6";
> reg = <0x11000000 0x10000>;
> interrupts = <0 96 0>;
> @@ -578,9 +578,152 @@
> interrupts = <0 95 0>;
> };
>
> - mixer {
> + mixer: mixer {
> compatible = "samsung,exynos5-mixer";
> reg = <0x14450000 0x10000>;
> interrupts = <0 94 0>;
> };
> +
> + 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>;
> + };
> +
> + sysmmu-tv {
> + mmuname = "tv";
> + reg = <0x14650000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <7 4>;
> + mmu-master = <&mixer>;
> + };
> +
> + sysmmu-gsc0 {
> + mmuname = "gsc0";
> + reg = <0x13E80000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 0>;
> + mmu-master = <&gsc_0>;
> + };
> +
> + sysmmu-gsc1 {
> + mmuname = "gsc1";
> + reg = <0x13E90000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 2>;
> + mmu-master = <&gsc_1>;
> + };
> +
> + sysmmu-gsc2 {
> + mmuname = "gsc2";
> + reg = <0x13EA0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 4>;
> + mmu-master = <&gsc_2>;
> + };
> +
> + sysmmu-gsc3 {
> + mmuname = "gsc3";
> + reg = <0x13EB0000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <2 6>;
> + mmu-master = <&gsc_3>;
> + };
> +
> + sysmmu-fimd1 {
> + mmuname = "fimd1";
> + reg = <0x14640000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <3 2>;
> + };
> +
> + sysmmu-rotator {
> + mmuname = "rotator";
> + reg = <0x11D40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 0>;
> + };
> +
> + sysmmu-is0 {
> + 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>;
>
I found the syntax of array of resources in the specifications of device
tree. I found that it works correctly.
> + };
> +
> + sysmmu-is1 {
> + mmuname = "odc", "dis0", "dis1", "3dnr";
> + reg = < 0x132C0000 0x1000
> + 0x132D0000 0x1000
> + 0x132E0000 0x1000
> + 0x132F0000 0x1000 >;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = < 11 0
> + 10 4
> + 9 4
> + 5 6 >;
>
> Ditto.
>
> + };
> +
> + sysmmu-2d {
> + mmuname = "2d";
> + reg = <0x10A60000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <24 5>;
> + };
> +
> + sysmmu-jpeg {
> + mmuname = "jpeg";
> + reg = <0x11F20000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <4 2>;
> + };
> +
> + sysmmu-flite0 {
> + mmuname = "flite0";
> + reg = <0x13C40000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <3 4>;
> + };
> +
> + sysmmu-flite1 {
> + mmuname = "flite1";
> + reg = <0x13C50000 0x1000>;
> + compatible = "samsung,exynos-sysmmu";
> + interrupt-parent = <&combiner>;
> + interrupts = <24 1>;
> + };
> };
>
> --
>
> Thanks,
> Sylwester
>
Thank you for kind review.
KyongHo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130107/144868c8/attachment-0001.html>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-07 10:45 ` KyongHo Cho
@ 2013-01-08 22:23 ` Sylwester Nawrocki
-1 siblings, 0 replies; 37+ messages in thread
From: Sylwester Nawrocki @ 2013-01-08 22:23 UTC (permalink / raw)
To: KyongHo Cho
Cc: Kukjin Kim, linux-arm-kernel, Linux Kernel, devicetree-discuss,
Linux IOMMU, Hyunwoong Kim, Rahul Sharma, Subash Patel,
Linux Samsung SOC, Prathyush, Tomasz Figa
On 01/07/2013 11:45 AM, KyongHo Cho wrote:
>> > The current exynos-iommu(System MMU) driver does not work autonomously
>> > since it is lack of support for power management of peripheral blocks.
>> > For example, MFC device driver must ensure that its System MMU is
> disabled
>> > before MFC block is power-down not to invalidate IOTLB in the System MMU
>> > when I/O memory mapping is changed. Because A System MMU is resides
> in the
>> > same H/W block, access to control registers of System MMU while the H/W
>> > block is turned off must be prohibited.
>> >
>> > This set of changes solves the above problem with setting each System
> MMUs
>> > 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.
I'll need to investigate it more, but AFAIU there is more than one clock
for the FIMC-IS device that needs to be enabled before FIMC-LITE can be
used. IOW FIMC-LITE must be activated after FIMC-IS, and deactivated before
FIMC-IS is (runtime) suspended.
So I'm afraid I can't simply alter the clock tree for the sake of the
subsystem dependencies - it's not a one-to-one relation and it doesn't
sound right.
> If you are concerning about power management, it is simply resolved with
> putting fimc-lite to the power domain of fimc-is.
Yes, these devices are already registered to same power domain (ISP).
> 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
I'm just concerned that this iommu driver would drop previous parent
configurations and introduce its own. There might be other devices for
which this would be harmful. Didn't you consider just moving any existing
device's parent and setting it as iommu's parent, so the tree looks like
sysmmu-fimc-is
|
fimc-is
/ \
sysmmu-fimc-lite0 sysmmu-fimc-lite1
| |
fimc-lite0 fimc-lite1
?
But it's not really much better...
>> > Another big change to the driver is the support for devicetree.
>> > 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@samsung.com <mailto:pullip.cho@samsung.com>>
>> 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@samsung.com
> <mailto:pullip.cho@samsung.com>>
>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com
> <mailto:kgene.kim@samsung.com>>
>> ---
>> .../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(-)
>> create mode 100644
> Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>
>> diff --git
> a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
> b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>> new file mode 100644
>> 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
> peripheral
>> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>> +
>> +System MMU is a sort of IOMMU and support identical translation table
> format to
>> +ARMv7 translation tables with minimum set of page properties
> including access
>> +permissions, shareability and security protection. In addition System
> MMU has
>> +another capabilities like L2 TLB or block-fetch buffers to minimize
> translation
>> +latency
>> +
>> +Each System MMU is included in the H/W block of a peripheral device.
> Thus, it is
>> +important to specify that a System MMU is dedicated to which
> peripheral device
>> +before using System MMU. System initialization must specify the
> relationships
>> +between a System MMU and a peripheral device that owns the System MMU.
>> +
>> +Some device drivers may control several peripheral devices with a
> single device
>> +descriptor like MFC. Since handling a System MMU with IOMMU API
> requires a
>> +device descriptor that needs the System MMU, it is best to combine
> the System
>> +MMUs of the peripheral devices and control them with a single System
> MMU device
>> +descriptor. If it is unable to combine them into a single device
> descriptor,
>> +they can be linked with each other by the means of device.parent
> relationship.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,exynos-sysmmu".
>> +- reg: Tuples of base address and size of System MMU registers. The
> number of
>> + tuples can be more than one if two or more System MMUs are
> controlled
>> + by a single device descriptor.
>> +- 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.
> The number
>> + 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.
Ok.
>> +- mmu-master: phandle to the device node that owns System MMU. Only
> the device
>> + that is specified whith this property can control System
> MMU with
>> + IOMMU API.
>> +
>> +Examples:
>> +
>> +MFC has 2 System MMUs for each port that MFC is attached. Thus it
> seems natural
>> +to define 2 System MMUs for each port of the MFC:
"The video codec (MFC) device has a System MMUs for each port (AXI master).
Thus it seems natural to define a System MMU device node for each port of
the MFC:"
>> +
>> + 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
> port and
>> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have
> the phandles
>> +to those sub-devices.
>>
>> I find this sentence really difficult to parse. This documentation
> should talk
>> about how the device is designed and represented, rather than about
> its driver.
>>
> OK. I will trying to find another expression easy to understand. Do you
> have any suggestion?
I'm not a native English speaker, but maybe something like this makes sense:
"The sysmmu-mfc-l, sysmmy-mfc-r nodes represent parts of the MFC device
which
indicate their 'mmu-master' phandles pointing to the mfc node."
?
>> +However, it is also a good idea that treats the above System MMUs as
treats -> treat
> 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>;
interrupts = <8 5>, <6 2>; ?
>> + mmu-master = <&mfc>;
>> + };
>> +
>> +If System MMU of MFC is defined like the above, the number of
> elements and the
>> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
...
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 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 {
>> + 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>;
>>
> I found the syntax of array of resources in the specifications of device
> tree. I found that it works correctly.
OK, it seems both conventions are valid. I just found it unusual, since
all interrupt specifiers I've seen for Samsung SoCs use the syntax, where
each interrupt is enclosed in triangular brackets. Maybe it's better to
keep it consistent across all files ?
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-08 22:23 ` Sylwester Nawrocki
0 siblings, 0 replies; 37+ messages in thread
From: Sylwester Nawrocki @ 2013-01-08 22:23 UTC (permalink / raw)
To: linux-arm-kernel
On 01/07/2013 11:45 AM, KyongHo Cho wrote:
>> > The current exynos-iommu(System MMU) driver does not work autonomously
>> > since it is lack of support for power management of peripheral blocks.
>> > For example, MFC device driver must ensure that its System MMU is
> disabled
>> > before MFC block is power-down not to invalidate IOTLB in the System MMU
>> > when I/O memory mapping is changed. Because A System MMU is resides
> in the
>> > same H/W block, access to control registers of System MMU while the H/W
>> > block is turned off must be prohibited.
>> >
>> > This set of changes solves the above problem with setting each System
> MMUs
>> > 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.
I'll need to investigate it more, but AFAIU there is more than one clock
for the FIMC-IS device that needs to be enabled before FIMC-LITE can be
used. IOW FIMC-LITE must be activated after FIMC-IS, and deactivated before
FIMC-IS is (runtime) suspended.
So I'm afraid I can't simply alter the clock tree for the sake of the
subsystem dependencies - it's not a one-to-one relation and it doesn't
sound right.
> If you are concerning about power management, it is simply resolved with
> putting fimc-lite to the power domain of fimc-is.
Yes, these devices are already registered to same power domain (ISP).
> 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
I'm just concerned that this iommu driver would drop previous parent
configurations and introduce its own. There might be other devices for
which this would be harmful. Didn't you consider just moving any existing
device's parent and setting it as iommu's parent, so the tree looks like
sysmmu-fimc-is
|
fimc-is
/ \
sysmmu-fimc-lite0 sysmmu-fimc-lite1
| |
fimc-lite0 fimc-lite1
?
But it's not really much better...
>> > Another big change to the driver is the support for devicetree.
>> > 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 at samsung.com <mailto:pullip.cho@samsung.com>>
>> 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@samsung.com
> <mailto:pullip.cho@samsung.com>>
>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com
> <mailto:kgene.kim@samsung.com>>
>> ---
>> .../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(-)
>> create mode 100644
> Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>
>> diff --git
> a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
> b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>> new file mode 100644
>> 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
> peripheral
>> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>> +
>> +System MMU is a sort of IOMMU and support identical translation table
> format to
>> +ARMv7 translation tables with minimum set of page properties
> including access
>> +permissions, shareability and security protection. In addition System
> MMU has
>> +another capabilities like L2 TLB or block-fetch buffers to minimize
> translation
>> +latency
>> +
>> +Each System MMU is included in the H/W block of a peripheral device.
> Thus, it is
>> +important to specify that a System MMU is dedicated to which
> peripheral device
>> +before using System MMU. System initialization must specify the
> relationships
>> +between a System MMU and a peripheral device that owns the System MMU.
>> +
>> +Some device drivers may control several peripheral devices with a
> single device
>> +descriptor like MFC. Since handling a System MMU with IOMMU API
> requires a
>> +device descriptor that needs the System MMU, it is best to combine
> the System
>> +MMUs of the peripheral devices and control them with a single System
> MMU device
>> +descriptor. If it is unable to combine them into a single device
> descriptor,
>> +they can be linked with each other by the means of device.parent
> relationship.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,exynos-sysmmu".
>> +- reg: Tuples of base address and size of System MMU registers. The
> number of
>> + tuples can be more than one if two or more System MMUs are
> controlled
>> + by a single device descriptor.
>> +- 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.
> The number
>> + 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.
Ok.
>> +- mmu-master: phandle to the device node that owns System MMU. Only
> the device
>> + that is specified whith this property can control System
> MMU with
>> + IOMMU API.
>> +
>> +Examples:
>> +
>> +MFC has 2 System MMUs for each port that MFC is attached. Thus it
> seems natural
>> +to define 2 System MMUs for each port of the MFC:
"The video codec (MFC) device has a System MMUs for each port (AXI master).
Thus it seems natural to define a System MMU device node for each port of
the MFC:"
>> +
>> + 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
> port and
>> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have
> the phandles
>> +to those sub-devices.
>>
>> I find this sentence really difficult to parse. This documentation
> should talk
>> about how the device is designed and represented, rather than about
> its driver.
>>
> OK. I will trying to find another expression easy to understand. Do you
> have any suggestion?
I'm not a native English speaker, but maybe something like this makes sense:
"The sysmmu-mfc-l, sysmmy-mfc-r nodes represent parts of the MFC device
which
indicate their 'mmu-master' phandles pointing to the mfc node."
?
>> +However, it is also a good idea that treats the above System MMUs as
treats -> treat
> 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>;
interrupts = <8 5>, <6 2>; ?
>> + mmu-master = <&mfc>;
>> + };
>> +
>> +If System MMU of MFC is defined like the above, the number of
> elements and the
>> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
...
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 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 {
>> + 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>;
>>
> I found the syntax of array of resources in the specifications of device
> tree. I found that it works correctly.
OK, it seems both conventions are valid. I just found it unusual, since
all interrupt specifiers I've seen for Samsung SoCs use the syntax, where
each interrupt is enclosed in triangular brackets. Maybe it's better to
keep it consistent across all files ?
--
Regards,
Sylwester
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2012-12-31 18:18 ` Kukjin Kim
(?)
@ 2013-01-10 17:19 ` 'Joerg Roedel'
-1 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 17:19 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> Cho KyongHo wrote:
> > Diffstats:
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > arch/arm/mach-exynos/Kconfig | 5 -
> > arch/arm/mach-exynos/Makefile | 1 -
> > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > drivers/iommu/Kconfig | 2 +-
> > drivers/iommu/Makefile | 2 +-
> > drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> > -----
> > 15 files changed, 1284 insertions(+), 796 deletions(-)
>
> Joerg, it's time to merge this. If you don't mind, let me pick up this whole
> series into Samsung tree because this touches many Samsung stuff.
Well, looking at the diffstat the IOMMU changes are a lot larger than
the exynos ones. So I think this should go through the IOMMU tree once
the latest review comments are fixed.
> Happy new year, thanks.
Happy new year too,
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 17:19 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 17:19 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Subash Patel',
'Linux Kernel', 'Linux IOMMU',
'Cho KyongHo', 'Linux ARM Kernel',
'Rahul Sharma'
On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> Cho KyongHo wrote:
> > Diffstats:
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > arch/arm/mach-exynos/Kconfig | 5 -
> > arch/arm/mach-exynos/Makefile | 1 -
> > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > drivers/iommu/Kconfig | 2 +-
> > drivers/iommu/Makefile | 2 +-
> > drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> > -----
> > 15 files changed, 1284 insertions(+), 796 deletions(-)
>
> Joerg, it's time to merge this. If you don't mind, let me pick up this whole
> series into Samsung tree because this touches many Samsung stuff.
Well, looking at the diffstat the IOMMU changes are a lot larger than
the exynos ones. So I think this should go through the IOMMU tree once
the latest review comments are fixed.
> Happy new year, thanks.
Happy new year too,
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 17:19 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 17:19 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> Cho KyongHo wrote:
> > Diffstats:
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > arch/arm/mach-exynos/Kconfig | 5 -
> > arch/arm/mach-exynos/Makefile | 1 -
> > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > drivers/iommu/Kconfig | 2 +-
> > drivers/iommu/Makefile | 2 +-
> > drivers/iommu/exynos-iommu.c | 1477 +++++++++++++++++++++--
> > -----
> > 15 files changed, 1284 insertions(+), 796 deletions(-)
>
> Joerg, it's time to merge this. If you don't mind, let me pick up this whole
> series into Samsung tree because this touches many Samsung stuff.
Well, looking at the diffstat the IOMMU changes are a lot larger than
the exynos ones. So I think this should go through the IOMMU tree once
the latest review comments are fixed.
> Happy new year, thanks.
Happy new year too,
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-10 17:19 ` 'Joerg Roedel'
@ 2013-01-10 18:06 ` Kukjin Kim
-1 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 18:06 UTC (permalink / raw)
To: 'Joerg Roedel'
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
'Joerg Roedel' wrote:
>
> On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> > Cho KyongHo wrote:
>
> > > Diffstats:
> > > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > > arch/arm/mach-exynos/Kconfig | 5 -
> > > arch/arm/mach-exynos/Makefile | 1 -
> > > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > > drivers/iommu/Kconfig | 2 +-
> > > drivers/iommu/Makefile | 2 +-
> > > drivers/iommu/exynos-iommu.c | 1477
> +++++++++++++++++++++--
> > > -----
> > > 15 files changed, 1284 insertions(+), 796 deletions(-)
> >
> > Joerg, it's time to merge this. If you don't mind, let me pick up this
whole
> > series into Samsung tree because this touches many Samsung stuff.
>
> Well, looking at the diffstat the IOMMU changes are a lot larger than
> the exynos ones. So I think this should go through the IOMMU tree once
> the latest review comments are fixed.
>
If so, too many ugly merge conflicts will be happened when Linus merges for
v3.9 because the legacy(current) exynos clock stuff is going away in Samsung
tree and as I said, this touches Samsung stuff widely. Of course, Stephen
should complain the conflicts between your tree and mine once you apply this
whole series in your -next before Linus' merge for v3.9. I believe, you
don't want it.
You know, we have several options to avoid it. When you take this series in
your tree, you can provide topic branch for me. Or this series should be
separated for arch/arm/ and drivers/ for both trees, then only drivers/iommu
changes should be picked up in your tree. I'm OK both, let me know which one
you would prefer or other way.
BTW, KyongHo, you need to update the clock changes for exynos-iommu against
on exynos common clock stuff.
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 18:06 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 18:06 UTC (permalink / raw)
To: linux-arm-kernel
'Joerg Roedel' wrote:
>
> On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> > Cho KyongHo wrote:
>
> > > Diffstats:
> > > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > > arch/arm/mach-exynos/Kconfig | 5 -
> > > arch/arm/mach-exynos/Makefile | 1 -
> > > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > > drivers/iommu/Kconfig | 2 +-
> > > drivers/iommu/Makefile | 2 +-
> > > drivers/iommu/exynos-iommu.c | 1477
> +++++++++++++++++++++--
> > > -----
> > > 15 files changed, 1284 insertions(+), 796 deletions(-)
> >
> > Joerg, it's time to merge this. If you don't mind, let me pick up this
whole
> > series into Samsung tree because this touches many Samsung stuff.
>
> Well, looking at the diffstat the IOMMU changes are a lot larger than
> the exynos ones. So I think this should go through the IOMMU tree once
> the latest review comments are fixed.
>
If so, too many ugly merge conflicts will be happened when Linus merges for
v3.9 because the legacy(current) exynos clock stuff is going away in Samsung
tree and as I said, this touches Samsung stuff widely. Of course, Stephen
should complain the conflicts between your tree and mine once you apply this
whole series in your -next before Linus' merge for v3.9. I believe, you
don't want it.
You know, we have several options to avoid it. When you take this series in
your tree, you can provide topic branch for me. Or this series should be
separated for arch/arm/ and drivers/ for both trees, then only drivers/iommu
changes should be picked up in your tree. I'm OK both, let me know which one
you would prefer or other way.
BTW, KyongHo, you need to update the clock changes for exynos-iommu against
on exynos common clock stuff.
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-10 17:19 ` 'Joerg Roedel'
(?)
@ 2013-01-10 18:34 ` Kukjin Kim
-1 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 18:34 UTC (permalink / raw)
To: 'Joerg Roedel'
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
Kukjin Kim wrote:
>
> 'Joerg Roedel' wrote:
> >
> > On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> > > Cho KyongHo wrote:
> >
> > > > Diffstats:
> > > > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > > > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > > > arch/arm/mach-exynos/Kconfig | 5 -
> > > > arch/arm/mach-exynos/Makefile | 1 -
> > > > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > > > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > > > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > > > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > > > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > > > drivers/iommu/Kconfig | 2 +-
> > > > drivers/iommu/Makefile | 2 +-
> > > > drivers/iommu/exynos-iommu.c | 1477
> > +++++++++++++++++++++--
> > > > -----
> > > > 15 files changed, 1284 insertions(+), 796 deletions(-)
> > >
> > > Joerg, it's time to merge this. If you don't mind, let me pick up this
whole
> > > series into Samsung tree because this touches many Samsung stuff.
> >
> > Well, looking at the diffstat the IOMMU changes are a lot larger than
> > the exynos ones. So I think this should go through the IOMMU tree once
> > the latest review comments are fixed.
> >
> If so, too many ugly merge conflicts will be happened when Linus merges
for
> v3.9 because the legacy(current) exynos clock stuff is going away in
Samsung
> tree and as I said, this touches Samsung stuff widely. Of course, Stephen
> should complain the conflicts between your tree and mine once you apply
> this whole series in your -next before Linus' merge for v3.9. I believe,
you
> don't want it.
>
> You know, we have several options to avoid it. When you take this series
in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only
> drivers/iommu changes should be picked up in your tree. I'm OK both, let
me
> know which one you would prefer or other way.
>
Hmm, I think, just one [7/12] patch does matter so if you could create topic
branch and apply [7/12] patch firstly before other drivers/ changes would be
better to me. It's OK on both trees if I just _merge_ the first [7/12]
commit in the topic branch you provided for exynos-iommu. But you know, you
don't have to rebase it once I merge it in Samsung tree.
How about?
> BTW, KyongHo, you need to update the clock changes for exynos-iommu
> against on exynos common clock stuff.
>
KyoungHo, your changes don't matter on exynos common clock stuff and I can
take care in my tree. So no need more work for it in your side. If any
updates, let you know.
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 18:34 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 18:34 UTC (permalink / raw)
To: 'Joerg Roedel'
Cc: 'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Subash Patel',
'Linux Kernel', 'Linux IOMMU',
'Cho KyongHo', 'Linux ARM Kernel',
'Rahul Sharma'
Kukjin Kim wrote:
>
> 'Joerg Roedel' wrote:
> >
> > On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> > > Cho KyongHo wrote:
> >
> > > > Diffstats:
> > > > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > > > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > > > arch/arm/mach-exynos/Kconfig | 5 -
> > > > arch/arm/mach-exynos/Makefile | 1 -
> > > > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > > > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > > > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > > > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > > > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > > > drivers/iommu/Kconfig | 2 +-
> > > > drivers/iommu/Makefile | 2 +-
> > > > drivers/iommu/exynos-iommu.c | 1477
> > +++++++++++++++++++++--
> > > > -----
> > > > 15 files changed, 1284 insertions(+), 796 deletions(-)
> > >
> > > Joerg, it's time to merge this. If you don't mind, let me pick up this
whole
> > > series into Samsung tree because this touches many Samsung stuff.
> >
> > Well, looking at the diffstat the IOMMU changes are a lot larger than
> > the exynos ones. So I think this should go through the IOMMU tree once
> > the latest review comments are fixed.
> >
> If so, too many ugly merge conflicts will be happened when Linus merges
for
> v3.9 because the legacy(current) exynos clock stuff is going away in
Samsung
> tree and as I said, this touches Samsung stuff widely. Of course, Stephen
> should complain the conflicts between your tree and mine once you apply
> this whole series in your -next before Linus' merge for v3.9. I believe,
you
> don't want it.
>
> You know, we have several options to avoid it. When you take this series
in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only
> drivers/iommu changes should be picked up in your tree. I'm OK both, let
me
> know which one you would prefer or other way.
>
Hmm, I think, just one [7/12] patch does matter so if you could create topic
branch and apply [7/12] patch firstly before other drivers/ changes would be
better to me. It's OK on both trees if I just _merge_ the first [7/12]
commit in the topic branch you provided for exynos-iommu. But you know, you
don't have to rebase it once I merge it in Samsung tree.
How about?
> BTW, KyongHo, you need to update the clock changes for exynos-iommu
> against on exynos common clock stuff.
>
KyoungHo, your changes don't matter on exynos common clock stuff and I can
take care in my tree. So no need more work for it in your side. If any
updates, let you know.
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 18:34 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Kukjin Kim wrote:
>
> 'Joerg Roedel' wrote:
> >
> > On Mon, Dec 31, 2012 at 10:18:46AM -0800, Kukjin Kim wrote:
> > > Cho KyongHo wrote:
> >
> > > > Diffstats:
> > > > arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> > > > arch/arm/boot/dts/exynos5250.dtsi | 27 +-
> > > > arch/arm/mach-exynos/Kconfig | 5 -
> > > > arch/arm/mach-exynos/Makefile | 1 -
> > > > arch/arm/mach-exynos/clock-exynos4.c | 41 +-
> > > > arch/arm/mach-exynos/clock-exynos4210.c | 9 +-
> > > > arch/arm/mach-exynos/clock-exynos4212.c | 23 +-
> > > > arch/arm/mach-exynos/clock-exynos5.c | 87 +-
> > > > arch/arm/mach-exynos/dev-sysmmu.c | 274 ------
> > > > arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --
> > > > arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +
> > > > arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +
> > > > drivers/iommu/Kconfig | 2 +-
> > > > drivers/iommu/Makefile | 2 +-
> > > > drivers/iommu/exynos-iommu.c | 1477
> > +++++++++++++++++++++--
> > > > -----
> > > > 15 files changed, 1284 insertions(+), 796 deletions(-)
> > >
> > > Joerg, it's time to merge this. If you don't mind, let me pick up this
whole
> > > series into Samsung tree because this touches many Samsung stuff.
> >
> > Well, looking at the diffstat the IOMMU changes are a lot larger than
> > the exynos ones. So I think this should go through the IOMMU tree once
> > the latest review comments are fixed.
> >
> If so, too many ugly merge conflicts will be happened when Linus merges
for
> v3.9 because the legacy(current) exynos clock stuff is going away in
Samsung
> tree and as I said, this touches Samsung stuff widely. Of course, Stephen
> should complain the conflicts between your tree and mine once you apply
> this whole series in your -next before Linus' merge for v3.9. I believe,
you
> don't want it.
>
> You know, we have several options to avoid it. When you take this series
in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only
> drivers/iommu changes should be picked up in your tree. I'm OK both, let
me
> know which one you would prefer or other way.
>
Hmm, I think, just one [7/12] patch does matter so if you could create topic
branch and apply [7/12] patch firstly before other drivers/ changes would be
better to me. It's OK on both trees if I just _merge_ the first [7/12]
commit in the topic branch you provided for exynos-iommu. But you know, you
don't have to rebase it once I merge it in Samsung tree.
How about?
> BTW, KyongHo, you need to update the clock changes for exynos-iommu
> against on exynos common clock stuff.
>
KyoungHo, your changes don't matter on exynos common clock stuff and I can
take care in my tree. So no need more work for it in your side. If any
updates, let you know.
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-10 18:06 ` Kukjin Kim
(?)
@ 2013-01-10 18:38 ` 'Joerg Roedel'
-1 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 18:38 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
On Thu, Jan 10, 2013 at 10:06:24AM -0800, Kukjin Kim wrote:
> You know, we have several options to avoid it. When you take this series in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only drivers/iommu
> changes should be picked up in your tree. I'm OK both, let me know which one
> you would prefer or other way.
I would like to take the final version of this patch-set (when you
provided your Acked-by) into the arm/exynos branch in my tree. You can
then pull in this branch to the Samsung tree and we can the conflicts
this way.
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 18:38 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 18:38 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Subash Patel',
'Linux Kernel', 'Linux IOMMU',
'Cho KyongHo', 'Linux ARM Kernel',
'Rahul Sharma'
On Thu, Jan 10, 2013 at 10:06:24AM -0800, Kukjin Kim wrote:
> You know, we have several options to avoid it. When you take this series in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only drivers/iommu
> changes should be picked up in your tree. I'm OK both, let me know which one
> you would prefer or other way.
I would like to take the final version of this patch-set (when you
provided your Acked-by) into the arm/exynos branch in my tree. You can
then pull in this branch to the Samsung tree and we can the conflicts
this way.
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 18:38 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 18:38 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 10, 2013 at 10:06:24AM -0800, Kukjin Kim wrote:
> You know, we have several options to avoid it. When you take this series in
> your tree, you can provide topic branch for me. Or this series should be
> separated for arch/arm/ and drivers/ for both trees, then only drivers/iommu
> changes should be picked up in your tree. I'm OK both, let me know which one
> you would prefer or other way.
I would like to take the final version of this patch-set (when you
provided your Acked-by) into the arm/exynos branch in my tree. You can
then pull in this branch to the Samsung tree and we can the conflicts
this way.
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-10 18:34 ` Kukjin Kim
@ 2013-01-10 19:12 ` 'Joerg Roedel'
-1 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 19:12 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
On Thu, Jan 10, 2013 at 10:34:48AM -0800, Kukjin Kim wrote:
> Hmm, I think, just one [7/12] patch does matter so if you could create topic
> branch and apply [7/12] patch firstly before other drivers/ changes would be
> better to me. It's OK on both trees if I just _merge_ the first [7/12]
> commit in the topic branch you provided for exynos-iommu. But you know, you
> don't have to rebase it once I merge it in Samsung tree.
>
> How about?
Sounds good. Should I take the patch directly from this post? I would
add your Acked-by then and make it the base for the arm/exynos branch.
Once the branch is set-up, as usual it will not be rebased.
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 19:12 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-10 19:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 10, 2013 at 10:34:48AM -0800, Kukjin Kim wrote:
> Hmm, I think, just one [7/12] patch does matter so if you could create topic
> branch and apply [7/12] patch firstly before other drivers/ changes would be
> better to me. It's OK on both trees if I just _merge_ the first [7/12]
> commit in the topic branch you provided for exynos-iommu. But you know, you
> don't have to rebase it once I merge it in Samsung tree.
>
> How about?
Sounds good. Should I take the patch directly from this post? I would
add your Acked-by then and make it the base for the arm/exynos branch.
Once the branch is set-up, as usual it will not be rebased.
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 19:33 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 19:33 UTC (permalink / raw)
To: 'Joerg Roedel'
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
'Joerg Roedel' wrote:
>
> On Thu, Jan 10, 2013 at 10:34:48AM -0800, Kukjin Kim wrote:
> > Hmm, I think, just one [7/12] patch does matter so if you could create
topic
> > branch and apply [7/12] patch firstly before other drivers/ changes
would
> be
> > better to me. It's OK on both trees if I just _merge_ the first [7/12]
> > commit in the topic branch you provided for exynos-iommu. But you know,
> you
> > don't have to rebase it once I merge it in Samsung tree.
> >
> > How about?
>
> Sounds good. Should I take the patch directly from this post? I would
> add your Acked-by then and make it the base for the arm/exynos branch.
Sure, keep going on with
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Once the branch is set-up, as usual it will not be rebased.
OK, good. Let me know the name of branch when you set-up it :-)
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 19:33 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 19:33 UTC (permalink / raw)
To: 'Joerg Roedel'
Cc: 'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Subash Patel',
'Linux Kernel', 'Linux IOMMU',
'Cho KyongHo', 'Linux ARM Kernel',
'Rahul Sharma'
'Joerg Roedel' wrote:
>
> On Thu, Jan 10, 2013 at 10:34:48AM -0800, Kukjin Kim wrote:
> > Hmm, I think, just one [7/12] patch does matter so if you could create
topic
> > branch and apply [7/12] patch firstly before other drivers/ changes
would
> be
> > better to me. It's OK on both trees if I just _merge_ the first [7/12]
> > commit in the topic branch you provided for exynos-iommu. But you know,
> you
> > don't have to rebase it once I merge it in Samsung tree.
> >
> > How about?
>
> Sounds good. Should I take the patch directly from this post? I would
> add your Acked-by then and make it the base for the arm/exynos branch.
Sure, keep going on with
Acked-by: Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Once the branch is set-up, as usual it will not be rebased.
OK, good. Let me know the name of branch when you set-up it :-)
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-10 19:33 ` Kukjin Kim
0 siblings, 0 replies; 37+ messages in thread
From: Kukjin Kim @ 2013-01-10 19:33 UTC (permalink / raw)
To: linux-arm-kernel
'Joerg Roedel' wrote:
>
> On Thu, Jan 10, 2013 at 10:34:48AM -0800, Kukjin Kim wrote:
> > Hmm, I think, just one [7/12] patch does matter so if you could create
topic
> > branch and apply [7/12] patch firstly before other drivers/ changes
would
> be
> > better to me. It's OK on both trees if I just _merge_ the first [7/12]
> > commit in the topic branch you provided for exynos-iommu. But you know,
> you
> > don't have to rebase it once I merge it in Samsung tree.
> >
> > How about?
>
> Sounds good. Should I take the patch directly from this post? I would
> add your Acked-by then and make it the base for the arm/exynos branch.
Sure, keep going on with
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Once the branch is set-up, as usual it will not be rebased.
OK, good. Let me know the name of branch when you set-up it :-)
Thanks.
- Kukjin
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-10 19:33 ` Kukjin Kim
@ 2013-01-11 15:52 ` 'Joerg Roedel'
-1 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-11 15:52 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Cho KyongHo', 'Linux ARM Kernel',
'Linux IOMMU', 'Linux Kernel',
'Linux Samsung SOC', 'Hyunwoong Kim',
'Prathyush', 'Rahul Sharma',
'Subash Patel'
Hi Kukjin,
On Thu, Jan 10, 2013 at 11:33:41AM -0800, Kukjin Kim wrote:
> Sure, keep going on with
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Done that. Applied the patch, some manual work was necessary as the
patch didn't apply cleanly to v3.8-rc3. Please double-check if the
result is correct.
> OK, good. Let me know the name of branch when you set-up it :-)
I pushed the branch to
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git arm/exynos
>From there you can pull it into your tree.
Have fun,
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-11 15:52 ` 'Joerg Roedel'
0 siblings, 0 replies; 37+ messages in thread
From: 'Joerg Roedel' @ 2013-01-11 15:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kukjin,
On Thu, Jan 10, 2013 at 11:33:41AM -0800, Kukjin Kim wrote:
> Sure, keep going on with
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Done that. Applied the patch, some manual work was necessary as the
patch didn't apply cleanly to v3.8-rc3. Please double-check if the
result is correct.
> OK, good. Let me know the name of branch when you set-up it :-)
I pushed the branch to
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git arm/exynos
>From there you can pull it into your tree.
Have fun,
Joerg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2012-12-26 1:53 ` Cho KyongHo
@ 2013-01-16 10:53 ` Will Deacon
-1 siblings, 0 replies; 37+ messages in thread
From: Will Deacon @ 2013-01-16 10:53 UTC (permalink / raw)
To: Cho KyongHo
Cc: 'Linux ARM Kernel', 'Linux IOMMU',
'Linux Kernel', 'Linux Samsung SOC',
'Kukjin Kim', 'Hyunwoong Kim',
'Prathyush', 'Joerg Roedel',
'Subash Patel', 'Rahul Sharma'
On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
Given that devicetree-discuss has been notably absent from discussion
surrounding the proposed binding, I think that including that patch in
linux-samsung.git and dropping it from this series is rather premature.
I have comments on the binding, so I'll dig up the version you posted in v5
and add devicetree-discuss to CC.
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
This should probably be Documentation/devicetree/bindings/iommu/ no?
Will
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-16 10:53 ` Will Deacon
0 siblings, 0 replies; 37+ messages in thread
From: Will Deacon @ 2013-01-16 10:53 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
> notice: v6 patch-set is rebased on next/iommu-exynos branch of
> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
> patches in v5 patch-se) because they alread exist already in the branch.
Given that devicetree-discuss has been notably absent from discussion
surrounding the proposed binding, I think that including that patch in
linux-samsung.git and dropping it from this series is rather premature.
I have comments on the binding, so I'll dig up the version you posted in v5
and add devicetree-discuss to CC.
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block is power-down not to invalidate IOTLB in the System MMU
> when I/O memory mapping is changed. Because A System MMU is resides in the
> same H/W block, access to control registers of System MMU while the H/W
> block is turned off must be prohibited.
>
> This set of changes solves the above problem with setting each System MMUs
> as the parent of the device which owns the System MMU to recieve the
> information when the device is turned off or turned on.
>
> Another big change to the driver is the support for devicetree.
> The bindings for System MMU is described in
> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
This should probably be Documentation/devicetree/bindings/iommu/ no?
Will
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
2013-01-08 22:23 ` Sylwester Nawrocki
@ 2013-01-16 16:57 ` KyongHo Cho
-1 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-16 16:57 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: Kukjin Kim, Hyunwoong Kim, Prathyush, devicetree-discuss,
Linux Kernel, Subash Patel, Linux IOMMU, Linux Samsung SOC,
Tomasz Figa, linux-arm-kernel, Rahul Sharma
On Wed, Jan 9, 2013 at 7:23 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> On 01/07/2013 11:45 AM, KyongHo Cho wrote:
>>>
>>> > The current exynos-iommu(System MMU) driver does not work autonomously
>>> > since it is lack of support for power management of peripheral blocks.
>>> > For example, MFC device driver must ensure that its System MMU is
>>
>> disabled
>>>
>>> > before MFC block is power-down not to invalidate IOTLB in the System
>>> > MMU
>>> > when I/O memory mapping is changed. Because A System MMU is resides
>>
>> in the
>>>
>>> > same H/W block, access to control registers of System MMU while the H/W
>>> > block is turned off must be prohibited.
>>> >
>>> > This set of changes solves the above problem with setting each System
>>
>> MMUs
>>>
>>> > 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.
>
>
> I'll need to investigate it more, but AFAIU there is more than one clock
> for the FIMC-IS device that needs to be enabled before FIMC-LITE can be
> used. IOW FIMC-LITE must be activated after FIMC-IS, and deactivated before
> FIMC-IS is (runtime) suspended.
>
> So I'm afraid I can't simply alter the clock tree for the sake of the
> subsystem dependencies - it's not a one-to-one relation and it doesn't
> sound right.
I have just little knowledge about FIMC-IS.
I don't understand why the sequence of power gating or suspend/resume
is important.
Are you concerning about the dependency of clock gating?
If the drivers of FIMC-IS and FIMC-LITE are not dependent upon each other,
I think it is just enough to add them to the same power domain.
I will check the clock description in the devicetree.
>
>> If you are concerning about power management, it is simply resolved with
>> putting fimc-lite to the power domain of fimc-is.
>
>
> Yes, these devices are already registered to same power domain (ISP).
>
>
>> 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
>
>
> I'm just concerned that this iommu driver would drop previous parent
> configurations and introduce its own. There might be other devices for
> which this would be harmful. Didn't you consider just moving any existing
> device's parent and setting it as iommu's parent, so the tree looks like
>
> sysmmu-fimc-is
> |
> fimc-is
> / \
> sysmmu-fimc-lite0 sysmmu-fimc-lite1
> | |
> fimc-lite0 fimc-lite1
>
> ?
>
> But it's not really much better...
Thanks for the proposal. I will consider to insert System MMU in the
existing dpm and rpm tree
without breaking the existing tree.
I did not find a better solution to guarantee that the System MMU is
always resumed
before its master (like fimc-lite0) is resumed and suspended after its
master is suspended.
It must be guaranteed in terms of APM and Runtime PM.
>>> > Another big change to the driver is the support for devicetree.
>>> > 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@samsung.com
>>> <mailto:pullip.cho@samsung.com>>
>>>
>>> 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@samsung.com
>>
>> <mailto:pullip.cho@samsung.com>>
>>>
>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com
>>
>> <mailto:kgene.kim@samsung.com>>
>>
>>> ---
>>> .../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(-)
>>> create mode 100644
>>
>> Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>>
>>> diff --git
>>
>> a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>> b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>> new file mode 100644
>>> 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
>>
>> peripheral
>>>
>>> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>>> +
>>> +System MMU is a sort of IOMMU and support identical translation table
>>
>> format to
>>>
>>> +ARMv7 translation tables with minimum set of page properties
>>
>> including access
>>>
>>> +permissions, shareability and security protection. In addition System
>>
>> MMU has
>>>
>>> +another capabilities like L2 TLB or block-fetch buffers to minimize
>>
>> translation
>>>
>>> +latency
>>> +
>>> +Each System MMU is included in the H/W block of a peripheral device.
>>
>> Thus, it is
>>>
>>> +important to specify that a System MMU is dedicated to which
>>
>> peripheral device
>>>
>>> +before using System MMU. System initialization must specify the
>>
>> relationships
>>>
>>> +between a System MMU and a peripheral device that owns the System MMU.
>>> +
>>> +Some device drivers may control several peripheral devices with a
>>
>> single device
>>>
>>> +descriptor like MFC. Since handling a System MMU with IOMMU API
>>
>> requires a
>>>
>>> +device descriptor that needs the System MMU, it is best to combine
>>
>> the System
>>>
>>> +MMUs of the peripheral devices and control them with a single System
>>
>> MMU device
>>>
>>> +descriptor. If it is unable to combine them into a single device
>>
>> descriptor,
>>>
>>> +they can be linked with each other by the means of device.parent
>>
>> relationship.
>>>
>>> +
>>> +Required properties:
>>> +- compatible: Should be "samsung,exynos-sysmmu".
>>> +- reg: Tuples of base address and size of System MMU registers. The
>>
>> number of
>>>
>>> + tuples can be more than one if two or more System MMUs are
>>
>> controlled
>>>
>>> + by a single device descriptor.
>>> +- 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.
>>
>> The number
>>>
>>> + 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.
>
>
> Ok.
>
>
>>> +- mmu-master: phandle to the device node that owns System MMU. Only
>>
>> the device
>>>
>>> + that is specified whith this property can control System
>>
>> MMU with
>>>
>>> + IOMMU API.
>>> +
>>> +Examples:
>>> +
>>> +MFC has 2 System MMUs for each port that MFC is attached. Thus it
>>
>> seems natural
>>>
>>> +to define 2 System MMUs for each port of the MFC:
>
>
> "The video codec (MFC) device has a System MMUs for each port (AXI master).
> Thus it seems natural to define a System MMU device node for each port of
>
> the MFC:"
Thanks. I think your expression is easier to understand.
I am also not a good English writer :)
>>> +
>>> + 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
>>
>> port and
>>>
>>> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have
>>
>> the phandles
>>>
>>> +to those sub-devices.
>>>
>>> I find this sentence really difficult to parse. This documentation
>>
>> should talk
>>>
>>> about how the device is designed and represented, rather than about
>>
>> its driver.
>>>
>>>
>> OK. I will trying to find another expression easy to understand. Do you
>> have any suggestion?
>
>
> I'm not a native English speaker, but maybe something like this makes sense:
>
> "The sysmmu-mfc-l, sysmmy-mfc-r nodes represent parts of the MFC device
> which
> indicate their 'mmu-master' phandles pointing to the mfc node."
I understand what you have intended.
Thank you for the suggestion. I will consider to make it easy to understand.
>
> ?
>
>>> +However, it is also a good idea that treats the above System MMUs as
>
>
> treats -> treat
>
Thanks.
>
>> 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>;
>
>
> interrupts = <8 5>, <6 2>; ?
>
Please see my reply below.
>
>>> + mmu-master = <&mfc>;
>>> + };
>>> +
>>> +If System MMU of MFC is defined like the above, the number of
>>
>> elements and the
>>>
>>> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
>
> ...
>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>
>> b/arch/arm/boot/dts/exynos5250.dtsi
>>>
>>> index 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 {
>>> + 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>;
>>>
>> I found the syntax of array of resources in the specifications of device
>> tree. I found that it works correctly.
>
>
> OK, it seems both conventions are valid. I just found it unusual, since
> all interrupt specifiers I've seen for Samsung SoCs use the syntax, where
> each interrupt is enclosed in triangular brackets. Maybe it's better to
> keep it consistent across all files ?
Let me check the other dts/dti and change my expression to follow the
convention:)
Sorry for late reply. I have just little time to spend after work in
these days. :(
Thank you for kind review.
KyongHo
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-16 16:57 ` KyongHo Cho
0 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-16 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 9, 2013 at 7:23 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> On 01/07/2013 11:45 AM, KyongHo Cho wrote:
>>>
>>> > The current exynos-iommu(System MMU) driver does not work autonomously
>>> > since it is lack of support for power management of peripheral blocks.
>>> > For example, MFC device driver must ensure that its System MMU is
>>
>> disabled
>>>
>>> > before MFC block is power-down not to invalidate IOTLB in the System
>>> > MMU
>>> > when I/O memory mapping is changed. Because A System MMU is resides
>>
>> in the
>>>
>>> > same H/W block, access to control registers of System MMU while the H/W
>>> > block is turned off must be prohibited.
>>> >
>>> > This set of changes solves the above problem with setting each System
>>
>> MMUs
>>>
>>> > 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.
>
>
> I'll need to investigate it more, but AFAIU there is more than one clock
> for the FIMC-IS device that needs to be enabled before FIMC-LITE can be
> used. IOW FIMC-LITE must be activated after FIMC-IS, and deactivated before
> FIMC-IS is (runtime) suspended.
>
> So I'm afraid I can't simply alter the clock tree for the sake of the
> subsystem dependencies - it's not a one-to-one relation and it doesn't
> sound right.
I have just little knowledge about FIMC-IS.
I don't understand why the sequence of power gating or suspend/resume
is important.
Are you concerning about the dependency of clock gating?
If the drivers of FIMC-IS and FIMC-LITE are not dependent upon each other,
I think it is just enough to add them to the same power domain.
I will check the clock description in the devicetree.
>
>> If you are concerning about power management, it is simply resolved with
>> putting fimc-lite to the power domain of fimc-is.
>
>
> Yes, these devices are already registered to same power domain (ISP).
>
>
>> 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
>
>
> I'm just concerned that this iommu driver would drop previous parent
> configurations and introduce its own. There might be other devices for
> which this would be harmful. Didn't you consider just moving any existing
> device's parent and setting it as iommu's parent, so the tree looks like
>
> sysmmu-fimc-is
> |
> fimc-is
> / \
> sysmmu-fimc-lite0 sysmmu-fimc-lite1
> | |
> fimc-lite0 fimc-lite1
>
> ?
>
> But it's not really much better...
Thanks for the proposal. I will consider to insert System MMU in the
existing dpm and rpm tree
without breaking the existing tree.
I did not find a better solution to guarantee that the System MMU is
always resumed
before its master (like fimc-lite0) is resumed and suspended after its
master is suspended.
It must be guaranteed in terms of APM and Runtime PM.
>>> > Another big change to the driver is the support for devicetree.
>>> > 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@samsung.com
>>> <mailto:pullip.cho@samsung.com>>
>>>
>>> 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@samsung.com
>>
>> <mailto:pullip.cho@samsung.com>>
>>>
>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com
>>
>> <mailto:kgene.kim@samsung.com>>
>>
>>> ---
>>> .../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(-)
>>> create mode 100644
>>
>> Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>>
>>> diff --git
>>
>> a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>> b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>> new file mode 100644
>>> 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
>>
>> peripheral
>>>
>>> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>>> +
>>> +System MMU is a sort of IOMMU and support identical translation table
>>
>> format to
>>>
>>> +ARMv7 translation tables with minimum set of page properties
>>
>> including access
>>>
>>> +permissions, shareability and security protection. In addition System
>>
>> MMU has
>>>
>>> +another capabilities like L2 TLB or block-fetch buffers to minimize
>>
>> translation
>>>
>>> +latency
>>> +
>>> +Each System MMU is included in the H/W block of a peripheral device.
>>
>> Thus, it is
>>>
>>> +important to specify that a System MMU is dedicated to which
>>
>> peripheral device
>>>
>>> +before using System MMU. System initialization must specify the
>>
>> relationships
>>>
>>> +between a System MMU and a peripheral device that owns the System MMU.
>>> +
>>> +Some device drivers may control several peripheral devices with a
>>
>> single device
>>>
>>> +descriptor like MFC. Since handling a System MMU with IOMMU API
>>
>> requires a
>>>
>>> +device descriptor that needs the System MMU, it is best to combine
>>
>> the System
>>>
>>> +MMUs of the peripheral devices and control them with a single System
>>
>> MMU device
>>>
>>> +descriptor. If it is unable to combine them into a single device
>>
>> descriptor,
>>>
>>> +they can be linked with each other by the means of device.parent
>>
>> relationship.
>>>
>>> +
>>> +Required properties:
>>> +- compatible: Should be "samsung,exynos-sysmmu".
>>> +- reg: Tuples of base address and size of System MMU registers. The
>>
>> number of
>>>
>>> + tuples can be more than one if two or more System MMUs are
>>
>> controlled
>>>
>>> + by a single device descriptor.
>>> +- 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.
>>
>> The number
>>>
>>> + 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.
>
>
> Ok.
>
>
>>> +- mmu-master: phandle to the device node that owns System MMU. Only
>>
>> the device
>>>
>>> + that is specified whith this property can control System
>>
>> MMU with
>>>
>>> + IOMMU API.
>>> +
>>> +Examples:
>>> +
>>> +MFC has 2 System MMUs for each port that MFC is attached. Thus it
>>
>> seems natural
>>>
>>> +to define 2 System MMUs for each port of the MFC:
>
>
> "The video codec (MFC) device has a System MMUs for each port (AXI master).
> Thus it seems natural to define a System MMU device node for each port of
>
> the MFC:"
Thanks. I think your expression is easier to understand.
I am also not a good English writer :)
>>> +
>>> + 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
>>
>> port and
>>>
>>> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have
>>
>> the phandles
>>>
>>> +to those sub-devices.
>>>
>>> I find this sentence really difficult to parse. This documentation
>>
>> should talk
>>>
>>> about how the device is designed and represented, rather than about
>>
>> its driver.
>>>
>>>
>> OK. I will trying to find another expression easy to understand. Do you
>> have any suggestion?
>
>
> I'm not a native English speaker, but maybe something like this makes sense:
>
> "The sysmmu-mfc-l, sysmmy-mfc-r nodes represent parts of the MFC device
> which
> indicate their 'mmu-master' phandles pointing to the mfc node."
I understand what you have intended.
Thank you for the suggestion. I will consider to make it easy to understand.
>
> ?
>
>>> +However, it is also a good idea that treats the above System MMUs as
>
>
> treats -> treat
>
Thanks.
>
>> 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>;
>
>
> interrupts = <8 5>, <6 2>; ?
>
Please see my reply below.
>
>>> + mmu-master = <&mfc>;
>>> + };
>>> +
>>> +If System MMU of MFC is defined like the above, the number of
>>
>> elements and the
>>>
>>> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
>
> ...
>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>
>> b/arch/arm/boot/dts/exynos5250.dtsi
>>>
>>> index 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 {
>>> + 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>;
>>>
>> I found the syntax of array of resources in the specifications of device
>> tree. I found that it works correctly.
>
>
> OK, it seems both conventions are valid. I just found it unusual, since
> all interrupt specifiers I've seen for Samsung SoCs use the syntax, where
> each interrupt is enclosed in triangular brackets. Maybe it's better to
> keep it consistent across all files ?
Let me check the other dts/dti and change my expression to follow the
convention:)
Sorry for late reply. I have just little time to spend after work in
these days. :(
Thank you for kind review.
KyongHo
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-16 17:00 ` KyongHo Cho
0 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-16 17:00 UTC (permalink / raw)
To: Will Deacon
Cc: Linux ARM Kernel, Linux IOMMU, Linux Kernel, Linux Samsung SOC,
Kukjin Kim, Hyunwoong Kim, Prathyush, Joerg Roedel, Subash Patel,
Rahul Sharma
On Wed, Jan 16, 2013 at 7:53 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>
> Given that devicetree-discuss has been notably absent from discussion
> surrounding the proposed binding, I think that including that patch in
> linux-samsung.git and dropping it from this series is rather premature.
>
> I have comments on the binding, so I'll dig up the version you posted in v5
> and add devicetree-discuss to CC.
Thank you.
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System MMUs
>> as the parent of the device which owns the System MMU to recieve the
>> information when the device is turned off or turned on.
>>
>> Another big change to the driver is the support for devicetree.
>> The bindings for System MMU is described in
>> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> This should probably be Documentation/devicetree/bindings/iommu/ no?
Please let me check it.
Thank you.
KyongHo.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-16 17:00 ` KyongHo Cho
0 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-16 17:00 UTC (permalink / raw)
To: Will Deacon
Cc: Kukjin Kim, Hyunwoong Kim, Prathyush, Subash Patel, Linux Kernel,
Linux IOMMU, Linux Samsung SOC, Linux ARM Kernel, Rahul Sharma
On Wed, Jan 16, 2013 at 7:53 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>
> Given that devicetree-discuss has been notably absent from discussion
> surrounding the proposed binding, I think that including that patch in
> linux-samsung.git and dropping it from this series is rather premature.
>
> I have comments on the binding, so I'll dig up the version you posted in v5
> and add devicetree-discuss to CC.
Thank you.
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System MMUs
>> as the parent of the device which owns the System MMU to recieve the
>> information when the device is turned off or turned on.
>>
>> Another big change to the driver is the support for devicetree.
>> The bindings for System MMU is described in
>> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> This should probably be Documentation/devicetree/bindings/iommu/ no?
Please let me check it.
Thank you.
KyongHo.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
@ 2013-01-16 17:00 ` KyongHo Cho
0 siblings, 0 replies; 37+ messages in thread
From: KyongHo Cho @ 2013-01-16 17:00 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 16, 2013 at 7:53 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>
> Given that devicetree-discuss has been notably absent from discussion
> surrounding the proposed binding, I think that including that patch in
> linux-samsung.git and dropping it from this series is rather premature.
>
> I have comments on the binding, so I'll dig up the version you posted in v5
> and add devicetree-discuss to CC.
Thank you.
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System MMUs
>> as the parent of the device which owns the System MMU to recieve the
>> information when the device is turned off or turned on.
>>
>> Another big change to the driver is the support for devicetree.
>> The bindings for System MMU is described in
>> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> This should probably be Documentation/devicetree/bindings/iommu/ no?
Please let me check it.
Thank you.
KyongHo.
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2013-01-16 17:00 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-26 1:53 [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT Cho KyongHo
2012-12-26 1:53 ` Cho KyongHo
2012-12-26 1:53 ` Cho KyongHo
2012-12-31 18:18 ` Kukjin Kim
2012-12-31 18:18 ` Kukjin Kim
2012-12-31 18:18 ` Kukjin Kim
2013-01-10 17:19 ` 'Joerg Roedel'
2013-01-10 17:19 ` 'Joerg Roedel'
2013-01-10 17:19 ` 'Joerg Roedel'
2013-01-10 18:06 ` Kukjin Kim
2013-01-10 18:06 ` Kukjin Kim
2013-01-10 18:38 ` 'Joerg Roedel'
2013-01-10 18:38 ` 'Joerg Roedel'
2013-01-10 18:38 ` 'Joerg Roedel'
2013-01-10 18:34 ` Kukjin Kim
2013-01-10 18:34 ` Kukjin Kim
2013-01-10 18:34 ` Kukjin Kim
2013-01-10 19:12 ` 'Joerg Roedel'
2013-01-10 19:12 ` 'Joerg Roedel'
2013-01-10 19:33 ` Kukjin Kim
2013-01-10 19:33 ` Kukjin Kim
2013-01-10 19:33 ` Kukjin Kim
2013-01-11 15:52 ` 'Joerg Roedel'
2013-01-11 15:52 ` 'Joerg Roedel'
2013-01-03 23:18 ` Sylwester Nawrocki
2013-01-03 23:18 ` Sylwester Nawrocki
[not found] ` <50E611D5.5040909-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-01-07 10:45 ` KyongHo Cho
2013-01-07 10:45 ` KyongHo Cho
2013-01-08 22:23 ` Sylwester Nawrocki
2013-01-08 22:23 ` Sylwester Nawrocki
2013-01-16 16:57 ` KyongHo Cho
2013-01-16 16:57 ` KyongHo Cho
2013-01-16 10:53 ` Will Deacon
2013-01-16 10:53 ` Will Deacon
2013-01-16 17:00 ` KyongHo Cho
2013-01-16 17:00 ` KyongHo Cho
2013-01-16 17:00 ` KyongHo Cho
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.