Sunday, March 22, 2015

Hardware cursor and IOMMU Support Jetson 


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.c 
 create 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:
  1. 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.
  2. 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.
  3. When the signals in step 2 have stabilized, where appropriate, the contrast voltage, Vee (not controlled or supplied by the controller) is then applied.
  4. 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


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)