Add NVIDIA JetSon K1 IOMMU support
This series adds support for the IOMMU found on Tegra124 SoCs. The SMMU groups memory clients into SWGROUPs and each SWGROUP can be assigned to one I/O virtual address space. Translation of virtual addresses can be enabled per memory client. Patch 1 adds an IOMMU device registry. The driver in patch 4 will add the IOMMU device with this registry, which will in turn be used by the client drivers to attach to the IOMMU device. Note that the API that is introduced in this patch may not be sufficient in the long term (f.e. when multiple master interfaces need to be supported). Patch 2 is v3 of the generic IOMMU device tree binding that has been discussed previously. Patch 3 defines the device tree binding for the NVIDIA Tegra124 memory controller (and references the generic IOMMU binding). Patch 4 implements a memory controller driver for NVIDIA Tegra124. It initializes the latency allowance programming to sensible defaults and registers an IOMMU device. Note that this is still somewhat work in progress. The page tables aren't properly cleaned up yet and other features of the memory controller may be useful to implement subsequently. Patches 5 through 8 add the device tree node for the memory controller and enable IOMMU support in the display and SDMMC controllers as examples. Patches 9 and 10 add support for IOMMU to the DRM and SDMMC drivers. SDMMC uses the DMA mapping API, which will make use of ARM's DMA/IOMMU integration. DRM has special needs (buffers that are mapped can be scanned out by either display controller) and not a good fit for the DMA mapping API, so it uses the IOMMU API directly. This has been tested using both SDMMC and DRM drivers via the IOMMU. For DRM when an IOMMU is detected it will use shmem as backing store, which removes the need for CMA. Importing from gk20a via the Nouveau driver also works, but buffers occasionally have some kind of offset that I haven't been able to track down yet. Thierry Thierry Reding (10): iommu: Add IOMMU device registry devicetree: Add generic IOMMU device tree bindings of: Add NVIDIA Tegra124 memory controller binding memory: Add Tegra124 memory controller support ARM: tegra: Add memory controller on Tegra124 ARM: tegra: tegra124: Enable IOMMU for display controllers ARM: tegra: tegra124: Enable IOMMU for SDMMC controllers ARM: tegra: Select ARM_DMA_USE_IOMMU drm/tegra: Add IOMMU support mmc: sdhci-tegra: Add IOMMU support Documentation/devicetree/bindings/iommu/iommu.txt | 156 ++ .../memory-controllers/nvidia,tegra124-mc.txt | 12 + arch/arm/boot/dts/tegra124.dtsi | 18 + arch/arm/mach-tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 21 + drivers/gpu/drm/tegra/drm.c | 17 + drivers/gpu/drm/tegra/drm.h | 3 + drivers/gpu/drm/tegra/fb.c | 16 +- drivers/gpu/drm/tegra/gem.c | 236 ++- drivers/gpu/drm/tegra/gem.h | 4 + drivers/iommu/iommu.c | 93 + drivers/memory/Kconfig | 9 + drivers/memory/Makefile | 1 + drivers/memory/tegra124-mc.c | 1945 ++++++++++++++++++++ drivers/mmc/host/sdhci-tegra.c | 8 + include/dt-bindings/memory/tegra124-mc.h | 30 + include/linux/iommu.h | 27 + 17 files changed, 2573 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.txt create mode 100644 drivers/memory/tegra124-mc.ccreate mode 100644 include/dt-bindings/memory/tegra124-mc.h
ARM: Initial support for Tegra 114 SoC.
Hardware cursor support
The hardware cursor extension reduces software overheads associated with maintaining a cursor image in the controller frame buffer.
Before the hardware cursor was introduced, moving the cursor required software to:
save an image of the area under the next cursor position
update the area with the cursor image
repair the last cursor position with a previously saved image.
In addition, the LCD driver had to check whether the graphics operation had overwritten the cursor, and correct it. With a cursor size of 64x64 and 24-bit color, each cursor move involved reading and writing approximately 75KB of data.
The hardware cursor removes the requirement for this management by providing a completely separate image buffer for the cursor, and superimposing the cursor image on the LCD output stream at the current cursor (X,Y) coordinate.
To move the hardware cursor, the software driver supplies a new cursor coordinate. The frame buffer requires no modification. This significantly reduces the software overhead.
The cursor image is held in the controller in a 256x32-bit dual-port RAM. You program the contents using the AHB slave interface.
LCD powering up and powering down sequence support
The controller requires the following power-up sequence to be performed:
- Vdd is simultaneously applied to the SoC that contains the controller and panel display driver logic. The following signals are held LOW:
- CLLP
- CLCP
- CLFP
- CLAC
- CLD[23:0]
- CLLE.
- When Vdd is stabilized, a 1 is written to the LcdEn bit in the LCDControl Register. See LCD Control Register. This enables the following signals into their active states:
- CLLP
- CLCP
- CLFP
- CLAC
- CLLE.
The CLD[23:0] signals remain in an inactive state. - When the signals in step 2 have stabilized, where appropriate, the contrast voltage, Vee (not controlled or supplied by the controller) is then applied.
- If required, you can use a software timer routine to provide the minimum display specific delay time between application of the control signals and power to the panel display. On completion of the software timer routine, power is applied to the panel by writing a 1 to the LcdPwr bit in the LcdControl Register that, in turn, sets the CLPOWER signal HIGH and enables the CLD[23:0] signals into their active states. Normally,CLPOWER is used to gate the power to the LCD panel.
The power-down sequence is the reverse of the above four stages and you must follow it strictly, this time, writing the respective register bits with 0.
Figure 1.1 shows the power-up and power-down sequences.
Figure 1.1. Power-up and power-down sequences
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0293c/DDI0293.pdf
https://github.com/torvalds/linux/blob/v3.19/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
https://android.googlesource.com/kernel/tegra.git/+/c3f5e27564ea4a81ed9d8bebedb88d4da07147db
https://android.googlesource.com/kernel/tegra.git/+/c3f5e27564ea4a81ed9d8bebedb88d4da07147dbhttps://lkml.org/lkml/2014/12/10/69
https://gitorious.org/thierryreding/linux/commit/b95596d7fd1e736971791078dede749517777460?diffmode=sidebyside
https://github.com/torvalds/linux/blob/v3.19/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
https://android.googlesource.com/kernel/tegra.git/+/c3f5e27564ea4a81ed9d8bebedb88d4da07147db
https://android.googlesource.com/kernel/tegra.git/+/c3f5e27564ea4a81ed9d8bebedb88d4da07147dbhttps://lkml.org/lkml/2014/12/10/69
https://gitorious.org/thierryreding/linux/commit/b95596d7fd1e736971791078dede749517777460?diffmode=sidebyside
