요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
===============================================
drm/tegra NVIDIA Tegra GPU and display driver
===============================================
NVIDIA Tegra SoCs support a set of display, graphics and video functions via
the host1x controller. host1x supplies command streams, gathered from a push
buffer provided directly by the CPU, to its clients via channels. Software,
or blocks amongst themselves, can use syncpoints for synchronization.
Up until, but not including, Tegra124 (aka Tegra K1) the drm/tegra driver
supports the built-in GPU, comprised of the gr2d and gr3d engines. Starting
with Tegra124 the GPU is based on the NVIDIA desktop GPU architecture and
supported by the drm/nouveau driver.
The drm/tegra driver supports NVIDIA Tegra SoC generations since Tegra20. It
has three parts:
- A host1x driver that provides infrastructure and access to the host1x
services.
- A KMS driver that supports the display controllers as well as a number of
outputs, such as RGB, HDMI, DSI, and DisplayPort.
- A set of custom userspace IOCTLs that can be used to submit jobs to the
GPU and video engines via host1x.
Driver Infrastructure
=====================
The various host1x clients need to be bound together into a logical device in
order to expose their functionality to users. The infrastructure that supports
this is implemented in the host1x driver. When a driver is registered with the
infrastructure it provides a list of compatible strings specifying the devices
that it needs. The infrastructure creates a logical device and scan the device
tree for matching device nodes, adding the required clients to a list. Drivers
for individual clients register with the infrastructure as well and are added
to the logical host1x device.
Once all clients are available, the infrastructure will initialize the logical
device using a driver-provided function which will set up the bits specific to
the subsystem and in turn initialize each of its clients.
Similarly, when one of the clients is unregistered, the infrastructure will
destroy the logical device by calling back into the driver, which ensures that
the subsystem specific bits are torn down and the clients destroyed in turn.
Host1x Infrastructure Reference
-------------------------------
.. kernel-doc:: include/linux/host1x.h
.. kernel-doc:: drivers/gpu/host1x/bus.c
:export:
Host1x Syncpoint Reference
--------------------------
.. kernel-doc:: drivers/gpu/host1x/syncpt.c
:export:
KMS driver
==========
The display hardware has remained mostly backwards compatible over the various
Tegra SoC generations, up until Tegra186 which introduces several changes that
make it difficult to support with a parameterized driver.
Display Controllers
-------------------
Tegra SoCs have two display controllers, each of which can be associated with
zero or more outputs. Outputs can also share a single display controller, but
only if they run with compatible display timings. Two display controllers can
also share a single framebuffer, allowing cloned configurations even if modes
on two outputs don't match. A display controller is modelled as a CRTC in KMS
terms.
On Tegra186, the number of display controllers has been increased to three. A
display controller can no longer drive all of the outputs. While two of these
controllers can drive both DSI outputs and both SOR outputs, the third cannot
drive any DSI.
Windows
~~~~~~~
A display controller controls a set of windows that can be used to composite
multiple buffers onto the screen. While it is possible to assign arbitrary Z
ordering to individual windows (by programming the corresponding blending
registers), this is currently not supported by the driver. Instead, it will
assume a fixed Z ordering of the windows (window A is the root window, that
is, the lowest, while windows B and C are overlaid on top of window A). The
overlay windows support multiple pixel formats and can automatically convert
from YUV to RGB at scanout time. This makes them useful for displaying video
content. In KMS, each window is modelled as a plane. Each display controller
has a hardware cursor that is exposed as a cursor plane.
Outputs
-------
The type and number of supported outputs varies between Tegra SoC generations.
All generations support at least HDMI. While earlier generations supported the
very simple RGB interfaces (one per display controller), recent generations no
longer do and instead provide standard interfaces such as DSI and eDP/DP.
Outputs are modelled as a composite encoder/connector pair.
RGB/LVDS
~~~~~~~~
This interface is no longer available since Tegra124. It has been replaced by
the more standard DSI and eDP interfaces.
HDMI
~~~~
HDMI is supported on all Tegra SoCs. Starting with Tegra210, HDMI is provided
by the versatile SOR output, which supports eDP, DP and HDMI. The SOR is able
to support HDMI 2.0, though support for this is currently not merged.
DSI
~~~
Although Tegra has supported DSI since Tegra30, the controller has changed in
several ways in Tegra114. Since none of the publicly available development
boards prior to Dalmore (Tegra114) have made use of DSI, only Tegra114 and
later are supported by the drm/tegra driver.
eDP/DP
~~~~~~
eDP was first introduced in Tegra124 where it was used to drive the display
panel for notebook form factors. Tegra210 added support for full DisplayPort
support, though this is currently not implemented in the drm/tegra driver.
Userspace Interface
===================
The userspace interface provided by drm/tegra allows applications to create
GEM buffers, access and control syncpoints as well as submit command streams
to host1x.
GEM Buffers
-----------
The ``DRM_IOCTL_TEGRA_GEM_CREATE`` IOCTL is used to create a GEM buffer object
with Tegra-specific flags. This is useful for buffers that should be tiled, or
that are to be scanned out upside down (useful for 3D content).
After a GEM buffer object has been created, its memory can be mapped by an
application using the mmap offset returned by the ``DRM_IOCTL_TEGRA_GEM_MMAP``
IOCTL.
Syncpoints
----------
The current value of a syncpoint can be obtained by executing the
``DRM_IOCTL_TEGRA_SYNCPT_READ`` IOCTL. Incrementing the syncpoint is achieved
using the ``DRM_IOCTL_TEGRA_SYNCPT_INCR`` IOCTL.
Userspace can also request blocking on a syncpoint. To do so, it needs to
execute the ``DRM_IOCTL_TEGRA_SYNCPT_WAIT`` IOCTL, specifying the value of
the syncpoint to wait for. The kernel will release the application when the
syncpoint reaches that value or after a specified timeout.
Command Stream Submission
-------------------------
Before an application can submit command streams to host1x it needs to open a
channel to an engine using the ``DRM_IOCTL_TEGRA_OPEN_CHANNEL`` IOCTL. Client
IDs are used to identify the target of the channel. When a channel is no
longer needed, it can be closed using the ``DRM_IOCTL_TEGRA_CLOSE_CHANNEL``
IOCTL. To retrieve the syncpoint associated with a channel, an application
can use the ``DRM_IOCTL_TEGRA_GET_SYNCPT``.
After opening a channel, submitting command streams is easy. The application
writes commands into the memory backing a GEM buffer object and passes these
to the ``DRM_IOCTL_TEGRA_SUBMIT`` IOCTL along with various other parameters,
such as the syncpoints or relocations used in the job submission.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Tegra host1x·GPU·display 구성
1-25NVIDIA Tegra SoC는 `host1x` controller를 통해 display, graphics, video 기능을 제공합니다. Host1x는 CPU가 직접 제공한 push buffer에서 command stream을 모아 channel을 통해 client에 전달합니다. Software와 hardware block 사이의 synchronization에는 syncpoint를 사용합니다.
Tegra124(Tegra K1) 이전까지 `drm/tegra`는 내장 `gr2d`·`gr3d` GPU engine을 지원합니다. Tegra124부터 GPU는 NVIDIA desktop GPU architecture를 사용하므로 `drm/nouveau`가 지원합니다.
Drm/tegra는 Tegra20 이후 SoC generation을 지원하고 세 부분으로 구성됩니다. Host1x driver는 host1x service의 infrastructure와 access를 제공하고, KMS driver는 display controller와 RGB·HDMI·DSI·DisplayPort output을 지원합니다. Custom userspace IOCTL은 host1x를 통해 GPU·video engine job을 제출합니다.
Host service, display와 userspace submission을 분리합니다.
CPU push buffer에서 engine 실행까지의 경로입니다.
===============================================
drm/tegra NVIDIA Tegra GPU and display driver
===============================================
NVIDIA Tegra SoCs support a set of display, graphics and video functions via
the host1x controller. host1x supplies command streams, gathered from a push
buffer provided directly by the CPU, to its clients via channels. Software,
or blocks amongst themselves, can use syncpoints for synchronization.
Up until, but not including, Tegra124 (aka Tegra K1) the drm/tegra driver
supports the built-in GPU, comprised of the gr2d and gr3d engines. Starting
with Tegra124 the GPU is based on the NVIDIA desktop GPU architecture and
supported by the drm/nouveau driver.
The drm/tegra driver supports NVIDIA Tegra SoC generations since Tegra20. It
has three parts:
- A host1x driver that provides infrastructure and access to the host1x
services.
- A KMS driver that supports the display controllers as well as a number of
outputs, such as RGB, HDMI, DSI, and DisplayPort.
- A set of custom userspace IOCTLs that can be used to submit jobs to the
GPU and video engines via host1x.Host1x logical-device infrastructure
26-63여러 host1x client의 기능을 user에게 노출하려면 하나의 logical device로 묶어야 합니다. Host1x driver가 이 infrastructure를 구현합니다.
Subsystem driver는 필요한 device를 나타내는 compatible string list와 함께 infrastructure에 등록합니다. Infrastructure는 logical device를 만들고 device tree에서 matching node를 scan하여 필요한 client list를 구성합니다. 개별 client driver도 infrastructure에 등록되어 같은 logical host1x device에 추가됩니다.
모든 client가 준비되면 infrastructure는 driver가 제공한 callback으로 logical device를 초기화합니다. Callback은 subsystem-specific 부분을 설정하고 각 client를 순서대로 초기화합니다.
Client 하나가 unregister되면 반대 순서로 driver callback을 호출해 logical device를 destroy하고 subsystem-specific state와 client를 해제합니다.
Host1x infrastructure API는 `include/linux/host1x.h`와 `drivers/gpu/host1x/bus.c`의 exported kernel-doc에서, syncpoint API는 `drivers/gpu/host1x/syncpt.c`에서 가져옵니다.
Infrastructure와 synchronization의 source path입니다.
Device-tree matching에서 teardown까지의 순서입니다.
Driver Infrastructure
=====================
The various host1x clients need to be bound together into a logical device in
order to expose their functionality to users. The infrastructure that supports
this is implemented in the host1x driver. When a driver is registered with the
infrastructure it provides a list of compatible strings specifying the devices
that it needs. The infrastructure creates a logical device and scan the device
tree for matching device nodes, adding the required clients to a list. Drivers
for individual clients register with the infrastructure as well and are added
to the logical host1x device.
Once all clients are available, the infrastructure will initialize the logical
device using a driver-provided function which will set up the bits specific to
the subsystem and in turn initialize each of its clients.
Similarly, when one of the clients is unregistered, the infrastructure will
destroy the logical device by calling back into the driver, which ensures that
the subsystem specific bits are torn down and the clients destroyed in turn.
Host1x Infrastructure Reference
-------------------------------
.. kernel-doc:: include/linux/host1x.h
.. kernel-doc:: drivers/gpu/host1x/bus.c
:export:
Host1x Syncpoint Reference
--------------------------
.. kernel-doc:: drivers/gpu/host1x/syncpt.c
:export:
KMS driver
==========
Tegra KMS controller·window·output
64-127Display hardware는 Tegra generation 사이에 대체로 backward compatible했지만 Tegra186은 parameterized driver로 지원하기 어려운 여러 변경을 도입했습니다.
기존 Tegra SoC에는 display controller 두 개가 있고 각각 output 0개 이상에 연결할 수 있습니다. Compatible timing이면 output 여러 개가 controller 하나를 공유할 수 있습니다. Controller 두 개가 framebuffer 하나를 공유하면 두 output mode가 달라도 clone configuration을 만들 수 있습니다. KMS에서는 controller를 CRTC로 모델링합니다.
Tegra186은 controller가 세 개로 늘고 모든 controller가 모든 output을 구동할 수 없게 됩니다. 두 controller는 DSI 둘과 SOR output 둘을 구동할 수 있지만 세 번째는 DSI를 구동할 수 없습니다.
Controller의 window는 여러 buffer를 screen에 합성합니다. Hardware는 blending register로 arbitrary Z order를 지원하지만 driver는 고정 order를 가정합니다. Window A가 root·lowest이고 B와 C가 위에 overlay됩니다.
Overlay window는 여러 pixel format과 scanout 시 YUV→RGB 자동 변환을 지원해 video content에 유용합니다. KMS에서는 window를 plane으로 모델링하고 각 controller의 hardware cursor는 cursor plane으로 노출합니다.
Output type과 수는 generation마다 다르지만 모두 HDMI를 지원합니다. 초기 generation의 simple RGB interface는 controller마다 하나씩 있었으나 최신 generation은 DSI·eDP/DP 같은 표준 interface를 사용합니다. Output은 encoder/connector composite pair로 모델링합니다.
RGB/LVDS는 Tegra124부터 없어지고 DSI·eDP로 대체됩니다. HDMI는 모든 SoC에서 지원하며 Tegra210부터 eDP·DP·HDMI를 지원하는 SOR가 제공합니다. SOR는 HDMI 2.0 capability가 있지만 driver support는 아직 merge되지 않았습니다.
DSI hardware는 Tegra30부터 있지만 Tegra114에서 크게 바뀌었고 초기 공개 board가 DSI를 쓰지 않아 driver는 Tegra114 이후만 지원합니다. eDP는 Tegra124 notebook panel에 처음 도입됐고 Tegra210은 full DisplayPort를 추가했지만 drm/tegra에는 아직 구현되지 않았습니다.
Tegra display hardware를 DRM object로 표현합니다.
Buffer 합성에서 physical output까지의 흐름입니다.
The display hardware has remained mostly backwards compatible over the various
Tegra SoC generations, up until Tegra186 which introduces several changes that
make it difficult to support with a parameterized driver.
Display Controllers
-------------------
Tegra SoCs have two display controllers, each of which can be associated with
zero or more outputs. Outputs can also share a single display controller, but
only if they run with compatible display timings. Two display controllers can
also share a single framebuffer, allowing cloned configurations even if modes
on two outputs don't match. A display controller is modelled as a CRTC in KMS
terms.
On Tegra186, the number of display controllers has been increased to three. A
display controller can no longer drive all of the outputs. While two of these
controllers can drive both DSI outputs and both SOR outputs, the third cannot
drive any DSI.
Windows
~~~~~~~
A display controller controls a set of windows that can be used to composite
multiple buffers onto the screen. While it is possible to assign arbitrary Z
ordering to individual windows (by programming the corresponding blending
registers), this is currently not supported by the driver. Instead, it will
assume a fixed Z ordering of the windows (window A is the root window, that
is, the lowest, while windows B and C are overlaid on top of window A). The
overlay windows support multiple pixel formats and can automatically convert
from YUV to RGB at scanout time. This makes them useful for displaying video
content. In KMS, each window is modelled as a plane. Each display controller
has a hardware cursor that is exposed as a cursor plane.
Outputs
-------
The type and number of supported outputs varies between Tegra SoC generations.
All generations support at least HDMI. While earlier generations supported the
very simple RGB interfaces (one per display controller), recent generations no
longer do and instead provide standard interfaces such as DSI and eDP/DP.
Outputs are modelled as a composite encoder/connector pair.
RGB/LVDS
~~~~~~~~
This interface is no longer available since Tegra124. It has been replaced by
the more standard DSI and eDP interfaces.
HDMI
~~~~
HDMI is supported on all Tegra SoCs. Starting with Tegra210, HDMI is provided
by the versatile SOR output, which supports eDP, DP and HDMI. The SOR is able
to support HDMI 2.0, though support for this is currently not merged.
DSI
~~~
Although Tegra has supported DSI since Tegra30, the controller has changed in
several ways in Tegra114. Since none of the publicly available development
boards prior to Dalmore (Tegra114) have made use of DSI, only Tegra114 and
later are supported by the drm/tegra driver.
GEM·syncpoint·command submission IOCTL
128-178Drm/tegra userspace interface는 application이 GEM buffer를 만들고 syncpoint를 access·control하며 host1x에 command stream을 제출하게 합니다.
`DRM_IOCTL_TEGRA_GEM_CREATE`는 Tegra-specific flag가 있는 GEM BO를 생성합니다. Tiled buffer나 3D content용 upside-down scanout buffer에 유용합니다. 생성 뒤 `DRM_IOCTL_TEGRA_GEM_MMAP`이 반환한 mmap offset으로 application이 memory를 mapping합니다.
`DRM_IOCTL_TEGRA_SYNCPT_READ`는 syncpoint 현재 값을 읽고 `DRM_IOCTL_TEGRA_SYNCPT_INCR`은 값을 증가시킵니다. `DRM_IOCTL_TEGRA_SYNCPT_WAIT`은 지정 value 또는 timeout까지 application을 block하고 kernel이 조건 충족 시 깨웁니다.
Command stream 제출 전 `DRM_IOCTL_TEGRA_OPEN_CHANNEL`로 engine channel을 열고 client ID로 target을 지정합니다. 더 이상 필요 없으면 `DRM_IOCTL_TEGRA_CLOSE_CHANNEL`로 닫고 `DRM_IOCTL_TEGRA_GET_SYNCPT`로 channel 연관 syncpoint를 얻습니다.
Channel을 연 뒤 application은 GEM BO backing memory에 command를 쓰고 `DRM_IOCTL_TEGRA_SUBMIT`에 syncpoint·relocation 등 job parameter와 함께 넘깁니다.
Buffer·syncpoint·channel·submission API입니다.
GEM command buffer를 host1x channel로 실행합니다.
eDP/DP
~~~~~~
eDP was first introduced in Tegra124 where it was used to drive the display
panel for notebook form factors. Tegra210 added support for full DisplayPort
support, though this is currently not implemented in the drm/tegra driver.
Userspace Interface
===================
The userspace interface provided by drm/tegra allows applications to create
GEM buffers, access and control syncpoints as well as submit command streams
to host1x.
GEM Buffers
-----------
The ``DRM_IOCTL_TEGRA_GEM_CREATE`` IOCTL is used to create a GEM buffer object
with Tegra-specific flags. This is useful for buffers that should be tiled, or
that are to be scanned out upside down (useful for 3D content).
After a GEM buffer object has been created, its memory can be mapped by an
application using the mmap offset returned by the ``DRM_IOCTL_TEGRA_GEM_MMAP``
IOCTL.
Syncpoints
----------
The current value of a syncpoint can be obtained by executing the
``DRM_IOCTL_TEGRA_SYNCPT_READ`` IOCTL. Incrementing the syncpoint is achieved
using the ``DRM_IOCTL_TEGRA_SYNCPT_INCR`` IOCTL.
Userspace can also request blocking on a syncpoint. To do so, it needs to
execute the ``DRM_IOCTL_TEGRA_SYNCPT_WAIT`` IOCTL, specifying the value of
the syncpoint to wait for. The kernel will release the application when the
syncpoint reaches that value or after a specified timeout.
Command Stream Submission
-------------------------
Before an application can submit command streams to host1x it needs to open a
channel to an engine using the ``DRM_IOCTL_TEGRA_OPEN_CHANNEL`` IOCTL. Client
IDs are used to identify the target of the channel. When a channel is no
longer needed, it can be closed using the ``DRM_IOCTL_TEGRA_CLOSE_CHANNEL``
IOCTL. To retrieve the syncpoint associated with a channel, an application
can use the ``DRM_IOCTL_TEGRA_GET_SYNCPT``.
After opening a channel, submitting command streams is easy. The application
writes commands into the memory backing a GEM buffer object and passes these
to the ``DRM_IOCTL_TEGRA_SUBMIT`` IOCTL along with various other parameters,
such as the syncpoints or relocations used in the job submission.
요약·해설
tegra.rst:1-178Tegra host1x infrastructure, KMS hardware와 userspace submission을 설명합니다.
Source와 관련 구현입니다.