Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello, On 2014-08-19 01:32, Joerg Roedel wrote: On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote: .../devicetree/bindings/iommu/samsung,sysmmu.txt | 93 ++- Documentation/power/notifiers.txt | 14 + arch/arm/boot/dts/exynos4.dtsi | 118 arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4x12.dtsi | 82 +++ arch/arm/include/asm/dma-iommu.h | 36 ++ arch/arm/mach-exynos/pm_domains.c | 12 +- arch/arm/mach-integrator/impd1.c | 2 +- arch/arm/mm/dma-mapping.c | 47 ++ drivers/base/bus.c | 4 +- drivers/base/dd.c | 10 +- drivers/base/platform.c| 2 +- drivers/base/power/domain.c| 70 ++- drivers/clk/samsung/clk-exynos4.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c| 1 + drivers/gpu/drm/exynos/exynos_drm_gsc.c| 1 + drivers/gpu/drm/exynos/exynos_drm_rotator.c| 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/iommu/exynos-iommu.c | 663 + drivers/iommu/iommu.c | 3 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 107 ++-- drivers/pci/host/pci-mvebu.c | 2 +- drivers/pci/host/pci-rcar-gen2.c | 2 +- drivers/pci/host/pci-tegra.c | 2 +- drivers/pci/host/pcie-rcar.c | 2 +- drivers/soc/tegra/pmc.c| 2 +- include/dt-bindings/clock/exynos4.h| 10 +- include/linux/device.h | 12 +- include/linux/iommu.h | 1 + include/linux/pm.h | 2 + include/linux/pm_domain.h | 19 + 33 files changed, 1016 insertions(+), 356 deletions(-) This touches a lot of non-iommu stuff. What is your strategy on getting this in, do you plan to get the non-iommu changes merged first or do you want to collect the respective Acks and merge this all through one tree? Those patches are posted as one patchset mainly to demonstrate how to get everything to work together. I also posted this as a single patch series to get some feedback from other iommu developers, especially all those involved in the generic iommu dt bindings. For merging, I will split them into smaller series and try to get respective acks. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello, On 2014-08-19 13:39, Andreas Färber wrote: Hi Marek and Inki, Am 19.08.2014 08:07, schrieb Marek Szyprowski: On 2014-08-19 01:32, Joerg Roedel wrote: On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote: [...] 33 files changed, 1016 insertions(+), 356 deletions(-) This touches a lot of non-iommu stuff. What is your strategy on getting this in, do you plan to get the non-iommu changes merged first or do you want to collect the respective Acks and merge this all through one tree? Those patches are posted as one patchset mainly to demonstrate how to get everything to work together. I also posted this as a single patch series to get some feedback from other iommu developers, especially all those involved in the generic iommu dt bindings. For merging, I will split them into smaller series and try to get respective acks. I'm working on 5250 based Spring Chromebook and noticed that v3.17-rc1 got some more iommu support. With the new CONFIG_DRM_EXYNOS_IOMMU=y my machine stops booting. So I'm wondering, is any of this a fix for 3.17, or is all of this unrelated -next material? This is probably a side effect of patch 3170447c1f264d51b8d1f3898bf2588588a64fdc (iommu/exynos: Select ARM_DMA_USE_IOMMU). It added selection of ARM_DMA_USE_IOMMU symbol, on which IOMMU support in Exynos DRM subsystem depends. However selecting this symbol is all that this patch does, without providing any code code which implements real support for ARM DMA IOMMU integration, which is needed by Exynos DRM driver. Please disable CONFIG_DRM_EXYNOS_IOMMU in kernel .config and your system should be bootable again. Also, are you or someone working on the respective DT changes for Exynos5? I can prepare DT changes for Exynos5 as well, but first I wanted to clarify if everyone involved in generic IOMMU bindings and Exynos IOMMU driver agrees on my proposal. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi, Am 19.08.2014 14:01, schrieb Marek Szyprowski: On 2014-08-19 13:39, Andreas Färber wrote: I'm working on 5250 based Spring Chromebook and noticed that v3.17-rc1 got some more iommu support. With the new CONFIG_DRM_EXYNOS_IOMMU=y my machine stops booting. So I'm wondering, is any of this a fix for 3.17, or is all of this unrelated -next material? This is probably a side effect of patch 3170447c1f264d51b8d1f3898bf2588588a64fdc (iommu/exynos: Select ARM_DMA_USE_IOMMU). It added selection of ARM_DMA_USE_IOMMU symbol, on which IOMMU support in Exynos DRM subsystem depends. However selecting this symbol is all that this patch does, without providing any code code which implements real support for ARM DMA IOMMU integration, which is needed by Exynos DRM driver. Please disable CONFIG_DRM_EXYNOS_IOMMU in kernel .config and your system should be bootable again. Yes, that's what my report implied. :) I'm bringing this up for -rc2 though: It sounds as if that option should remain unavailable until the required code is in? Thanks. Also, are you or someone working on the respective DT changes for Exynos5? I can prepare DT changes for Exynos5 as well, but first I wanted to clarify if everyone involved in generic IOMMU bindings and Exynos IOMMU driver agrees on my proposal. Sure. I'm updating my old spring-bridge.v6 branch [1] to 3.17-rc1 [2], which involves three drm bridge patches rebased onto the new drm panel prepare/unprepare infrastructure plus two LVDS DT patches in addition to the IOMMU patches. That old branch included DT changes for 5250 in ARM: dts: add System MMU nodes of Exynos SoCs, but that'll probably need updating for the new bindings. Regards, Andreas [1] https://github.com/afaerber/linux/commits/spring-bridge.v6 [2] https://github.com/afaerber/linux/commits/spring-next -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hi Marek and Inki, Am 19.08.2014 08:07, schrieb Marek Szyprowski: On 2014-08-19 01:32, Joerg Roedel wrote: On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote: [...] 33 files changed, 1016 insertions(+), 356 deletions(-) This touches a lot of non-iommu stuff. What is your strategy on getting this in, do you plan to get the non-iommu changes merged first or do you want to collect the respective Acks and merge this all through one tree? Those patches are posted as one patchset mainly to demonstrate how to get everything to work together. I also posted this as a single patch series to get some feedback from other iommu developers, especially all those involved in the generic iommu dt bindings. For merging, I will split them into smaller series and try to get respective acks. I'm working on 5250 based Spring Chromebook and noticed that v3.17-rc1 got some more iommu support. With the new CONFIG_DRM_EXYNOS_IOMMU=y my machine stops booting. So I'm wondering, is any of this a fix for 3.17, or is all of this unrelated -next material? Also, are you or someone working on the respective DT changes for Exynos5? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote: .../devicetree/bindings/iommu/samsung,sysmmu.txt | 93 ++- Documentation/power/notifiers.txt | 14 + arch/arm/boot/dts/exynos4.dtsi | 118 arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4x12.dtsi | 82 +++ arch/arm/include/asm/dma-iommu.h | 36 ++ arch/arm/mach-exynos/pm_domains.c | 12 +- arch/arm/mach-integrator/impd1.c | 2 +- arch/arm/mm/dma-mapping.c | 47 ++ drivers/base/bus.c | 4 +- drivers/base/dd.c | 10 +- drivers/base/platform.c| 2 +- drivers/base/power/domain.c| 70 ++- drivers/clk/samsung/clk-exynos4.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c| 1 + drivers/gpu/drm/exynos/exynos_drm_gsc.c| 1 + drivers/gpu/drm/exynos/exynos_drm_rotator.c| 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/iommu/exynos-iommu.c | 663 + drivers/iommu/iommu.c | 3 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 107 ++-- drivers/pci/host/pci-mvebu.c | 2 +- drivers/pci/host/pci-rcar-gen2.c | 2 +- drivers/pci/host/pci-tegra.c | 2 +- drivers/pci/host/pcie-rcar.c | 2 +- drivers/soc/tegra/pmc.c| 2 +- include/dt-bindings/clock/exynos4.h| 10 +- include/linux/device.h | 12 +- include/linux/iommu.h | 1 + include/linux/pm.h | 2 + include/linux/pm_domain.h | 19 + 33 files changed, 1016 insertions(+), 356 deletions(-) This touches a lot of non-iommu stuff. What is your strategy on getting this in, do you plan to get the non-iommu changes merged first or do you want to collect the respective Acks and merge this all through one tree? Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello Everyone, A lot of things has happened in the area of improving Exynos IOMMU driver and discussion about generic IOMMU bindings, which finally motivated me to get back to IOMMU related tasks. Just to remind, here are those 2 important threads: 1. [PATCH v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT: https://lkml.org/lkml/2014/5/12/34 2. [PATCH v4] devicetree: Add generic IOMMU device tree bindings: https://lkml.org/lkml/2014/7/4/349 As a follow up of those discussions I've decided to finish our internal code, which adapts Exynos SYSMMU driver to meet generic IOMMU bindings requirements and implement all needed glue code to finally demonstare seemless integration IOMMU controller with DMA-mapping subsystem for the drivers available on Exynos SoCs. 1. Introduction - a few words for those who are not fully aware of the Exynos SoC hardware Exynos SoC consists of various devices integrated directly into SoCs. Most of them are multimedia devices, which usually process large buffers. Some of them (like i.e. MFC - a multimedia codec or FIMD - a multi-window framebuffer device lcd panel controller) are equipped with more than one memory interface for higher processing performance. There are also really complex subsystems (like ISP, the camera sensor interface processor), which consist of many sub-blocks, each having its own memory interface/channel/bus (different names are used for the same thing). Each such memory controller might be equipped with SYSMMU device, which acts as IOMMU controller for the parent device (called master device, a device which that memory interface belongs to). Each SYSMMU controller has its own register set and clock, belongs to the same power domain as master device. There is also some non-direct relation from master's device gate clock - SYSMMU registers can be accessed only when master's gate clock is enabled. Basically we have following dependencies between hardware and drivers: - each multimedia device might have 1 or more SYSMMU controller - each SYSMMU controller belongs only to 1 master device - all SYSMMU controllers are independent of each other, there is no global hardware ID that must be assigned to enable given SYSMMU controller - multimedia devices are modeled usually by a separate node in device tree with it's own compatible string and separate driver for them - sub-blocks of complex devices right now are not modeled by a separate device tree nodes, but this might be changed in the future - some multimedia devices have limited address space per each memory controller/channel (i.e. codec might access buffers only in a 256MiB window for each of it's memory channels) - some drivers for independent device are used together to provide a more complex subsystem, i.e. FIMD, HDMI-mixer and others form together Exynos DRM subsystem; it is highly welcome to let them to operate in the same, shared DMA address space to simplify buffer sharing 2. Introduction part 2 - a few word of summary of the discussions about generic IOMMU DT bindings There have been a lot of discussions on the method of modeling IOMMU controllers in device tree. The approach which has been selected as the generic IOMMU binding candidate has been described in the '[PATCH v4] devicetree: Add generic IOMMU device tree bindings' thread. Those bindings describe how to link an IOMMU controller with its master device. Basically an 'iommus' property placed in the master's device node has been introduced. This property contains phandle to IOMMU controller node. Optional properties of the particular binding can also be specified after the phandle, assuming that IOMMU controller node contains '#iommu-cells' property, which defines number of cells used for those parameters. Those parameters are then interpreted by particular IOMMU controller driver. Those parameters might be some hw channel id required for correct hardware setup, base address and size pair for limited IO address space window or others hardware dependant properties. 3. IOMMU integration to DMA-mapping subsystem By default we assume that each master device, which has been equipped with IOMMU controller gets its own DMA (IO) address space. This is created automatically and transparently without any changes in the device driver code. All DMA-mapping functions are replaced with the IOMMU aware versions. This has to be done somewhere by the architecture or SoC startup code, so when master's driver probe() function is called, everything is in place. However some device drivers might need (for various reasons) to manually manage DMA (IO) address space. For this case a driver need to notify kernel about that and do the management of DMA address space on its own. This has been achieved by introducing DRIVER_HAS_OWN_IOMMU_MANAGER flag, which can be set in struct device_driver. This way the startup code can easily determine if creating the default per-device separate DMA address space is required
