Kernel Mode Setting (KMS)

KMS core 초기화와 framebuffer 크기

Driver는 DRM device에서 `drmm_mode_config_init()`를 호출해 mode setting core를 초기화해야 합니다. 이 함수는 `struct drm_device`의 `mode_config` field를 초기화하며 실패하지 않습니다. 호출이 끝나면 아래 field를 설정해 mode configuration을 완성해야 합니다.

`int min_width, min_height; int max_width, max_height;`는 framebuffer의 최소·최대 너비와 높이를 pixel 단위로 지정합니다. `struct drm_mode_config_funcs *funcs;`는 mode setting function table을 가리킵니다.

=========================
Kernel Mode Setting (KMS)
=========================

Drivers must initialize the mode setting core by calling
drmm_mode_config_init() on the DRM device. The function
initializes the :c:type:`struct drm_device <drm_device>`
mode_config field and never fails. Once done, mode configuration must
be setup by initializing the following fields.

-  int min_width, min_height; int max_width, max_height;
   Minimum and maximum width and height of the frame buffers in pixel
   units.

-  struct drm_mode_config_funcs \*funcs;
   Mode setting functions.

Userspace KMS object와 내부 output pipeline

KMS가 userspace에 제시하는 기본 object 구조는 비교적 단순합니다. `struct drm_framebuffer`가 plane에 pixel data를 공급하고, 하나 이상의 plane 또는 plane이 없는 상태가 `struct drm_crtc`로 들어가 blending됩니다. 정확한 blending 단계는 Plane Composition Properties 절과 관련 장에서 설명합니다.

Output routing의 첫 단계인 `struct drm_encoder`는 실제로 KMS driver helper library의 내부 산물입니다. Userspace가 가능한 CRTC·connector 연결과 cloning 지원을 알아내기 어렵게 만들 뿐 userspace API에서 별도 목적은 없습니다. 그러나 이미 ABI에 노출되어 제거할 수 없고, driver가 제한을 잘못 설정하거나 실제 hardware 제약을 충분히 표현하지 못하는 경우도 많습니다. CRTC는 여러 encoder에 연결될 수 있으며 active CRTC에는 최소 하나의 encoder가 있어야 합니다.

Display chain의 실제 최종 endpoint는 `struct drm_connector`입니다. Connector는 여러 가능한 encoder를 가질 수 있지만 각 connector에서 사용할 encoder는 kernel driver가 선택합니다. 예를 들어 DVI는 analog encoder와 digital encoder 사이를 전환할 수 있습니다. Encoder 하나가 서로 다른 connector 여러 개를 구동할 수도 있지만 active encoder마다 active connector는 정확히 하나입니다.

내부 output pipeline은 현대 hardware에 더 가깝고 두 helper object가 추가됩니다. Encoder code를 공유하기 위해 하나 이상의 `struct drm_bridge`를 encoder에 정적으로 연결할 수 있습니다. 이 연결은 변경할 수 없으므로 cross-bar가 있다면 CRTC와 encoder 사이에 mapping해야 합니다.

Bridge를 쓰는 driver는 encoder level에 남는 code가 없는 경우가 많습니다. Atomic driver는 encoder callback을 모두 생략해 userspace ABI 호환을 위한 dummy routing object만 남길 수 있습니다. 두 번째 helper object인 `struct drm_panel`은 고정 binding point가 없고 일반적으로 `struct drm_connector`를 embed한 driver private structure에 연결됩니다. Bridge chaining과 connector·panel 상호작용은 현재도 변하는 중이며 완전히 정리된 상태가 아닙니다.

Overview
========

.. kernel-render:: DOT
   :alt: KMS Display Pipeline
   :caption: KMS Display Pipeline Overview

   digraph "KMS" {
      node [shape=box]

      subgraph cluster_static {
          style=dashed
          label="Static Objects"

          node [bgcolor=grey style=filled]
          "drm_plane A" -> "drm_crtc"
          "drm_plane B" -> "drm_crtc"
          "drm_crtc" -> "drm_encoder A"
          "drm_crtc" -> "drm_encoder B"
      }

      subgraph cluster_user_created {
          style=dashed
          label="Userspace-Created"

          node [shape=oval]
          "drm_framebuffer 1" -> "drm_plane A"
          "drm_framebuffer 2" -> "drm_plane B"
      }

      subgraph cluster_connector {
          style=dashed
          label="Hotpluggable"

          "drm_encoder A" -> "drm_connector A"
          "drm_encoder B" -> "drm_connector B"
      }
   }

The basic object structure KMS presents to userspace is fairly simple.
Framebuffers (represented by :c:type:`struct drm_framebuffer <drm_framebuffer>`,
see `Frame Buffer Abstraction`_) feed into planes. Planes are represented by
:c:type:`struct drm_plane <drm_plane>`, see `Plane Abstraction`_ for more
details. One or more (or even no) planes feed their pixel data into a CRTC
(represented by :c:type:`struct drm_crtc <drm_crtc>`, see `CRTC Abstraction`_)
for blending. The precise blending step is explained in more detail in `Plane
Composition Properties`_ and related chapters.

For the output routing the first step is encoders (represented by
:c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those
are really just internal artifacts of the helper libraries used to implement KMS
drivers. Besides that they make it unnecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can't remove them
at this point.  Furthermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.

The final, and real, endpoint in the display chain is the connector (represented
by :c:type:`struct drm_connector <drm_connector>`, see `Connector
Abstraction`_). Connectors can have different possible encoders, but the kernel
driver selects which encoder to use for each connector. The use case is DVI,
which could switch between an analog and a digital encoder. Encoders can also
drive multiple different connectors. There is exactly one active connector for
every active encoder.

Internally the output pipeline is a bit more complex and matches today's
hardware more closely:

.. kernel-render:: DOT
   :alt: KMS Output Pipeline
   :caption: KMS Output Pipeline

   digraph "Output Pipeline" {
      node [shape=box]

      subgraph {
          "drm_crtc" [bgcolor=grey style=filled]
      }

      subgraph cluster_internal {
          style=dashed
          label="Internal Pipeline"
          {
              node [bgcolor=grey style=filled]
              "drm_encoder A";
              "drm_encoder B";
              "drm_encoder C";
          }

          {
              node [bgcolor=grey style=filled]
              "drm_encoder B" -> "drm_bridge B"
              "drm_encoder C" -> "drm_bridge C1"
              "drm_bridge C1" -> "drm_bridge C2";
          }
      }

      "drm_crtc" -> "drm_encoder A"
      "drm_crtc" -> "drm_encoder B"
      "drm_crtc" -> "drm_encoder C"


      subgraph cluster_output {
          style=dashed
          label="Outputs"

          "drm_encoder A" -> "drm_connector A";
          "drm_bridge B" -> "drm_connector B";
          "drm_bridge C2" -> "drm_connector C";

          "drm_panel"
      }
   }

Internally two additional helper objects come into play. First, to be able to
share code for encoders (sometimes on the same SoC, sometimes off-chip) one or
more :ref:`drm_bridges` (represented by :c:type:`struct drm_bridge
<drm_bridge>`) can be linked to an encoder. This link is static and cannot be
changed, which means the cross-bar (if there is any) needs to be mapped between
the CRTC and any encoders. Often for drivers with bridges there's no code left
at the encoder level. Atomic drivers can leave out all the encoder callbacks to
essentially only leave a dummy routing object behind, which is needed for
backwards compatibility since encoders are exposed to userspace.

The second object is for panels, represented by :c:type:`struct drm_panel
<drm_panel>`, see :ref:`drm_panel_helper`. Panels do not have a fixed binding
point, but are generally linked to the driver private structure that embeds
:c:type:`struct drm_connector <drm_connector>`.

Note that currently the bridge chaining and interactions with connectors and
panels are still in-flux and not really fully sorted out yet.

Mode config와 base object property

KMS core structure reference는 `drm_mode_config.h` 내부 interface와 `drm_mode_config.c` exported API를 제공합니다.

모든 KMS object의 base structure는 `struct drm_mode_object`입니다. 이 구조가 제공하는 기본 service 중 하나는 atomic ioctl에서 특히 중요한 property 추적입니다. Property는 각 object 안에 직접 instance화되지 않고 type과 value range를 정의하는 독립 mode object인 `struct drm_property`로 존재합니다. 하나의 property는 `drm_object_attach_property()`로 서로 다른 object에 여러 번 attach할 수 있습니다.

KMS Core Structures and Functions
=================================

.. kernel-doc:: include/drm/drm_mode_config.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
   :export:

.. _kms_base_object_abstraction:

Modeset Base Object Abstraction
===============================

.. kernel-render:: DOT
   :alt: Mode Objects and Properties
   :caption: Mode Objects and Properties

   digraph {
      node [shape=box]

      "drm_property A" -> "drm_mode_object A"
      "drm_property A" -> "drm_mode_object B"
      "drm_property B" -> "drm_mode_object A"
   }

The base structure for all KMS objects is :c:type:`struct drm_mode_object
<drm_mode_object>`. One of the base services it provides is tracking properties,
which are especially important for the atomic IOCTL (see `Atomic Mode
Setting`_). The somewhat surprising part here is that properties are not
directly instantiated on each object, but free-standing mode objects themselves,
represented by :c:type:`struct drm_property <drm_property>`, which only specify
the type and value range of a property. Any given property can be attached
multiple times to different objects using drm_object_attach_property().

.. kernel-doc:: include/drm/drm_mode_object.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
   :export:

Atomic transaction, state와 locking

Atomic mode setting은 plane을 포함한 modeset update를 transaction으로 제공하지만 일반적인 try-commit·rollback과는 다르게 설계됩니다.

첫째, commit이 실패할 경우 hardware 변경을 전혀 허용하지 않습니다. 이 규칙 덕분에 userspace가 특정 configuration의 가능 여부를 탐색하는 `DRM_MODE_ATOMIC_TEST_ONLY` mode를 구현할 수 있습니다. Software state만 설정했다가 rollback하는 방식도 기존 driver 전환에는 편리하지만 여러 data structure의 변경을 정확히 되돌리기 어려워 `atomic_check` 정확성 audit를 매우 어렵게 합니다.

셋째, 하위 호환성과 모든 use case 지원을 위해 atomic update는 incremental해야 하고 병렬 실행이 가능해야 합니다. Hardware가 항상 허용하지는 않지만 가능한 경우 서로 다른 CRTC의 plane update가 간섭하거나 다른 CRTC의 output routing 변경 때문에 지연되어서는 안 됩니다.

이 제약에는 두 가지 결과가 있습니다. 전체 state는 plane의 `struct drm_plane_state`, CRTC의 `struct drm_crtc_state`, connector의 `struct drm_connector_state`처럼 object별 구조체로 나뉩니다. Userspace에서 보고 설정할 수 있는 state를 가진 object는 이 세 종류뿐입니다. 내부 state가 필요하면 driver가 embedding으로 구조체를 subclass하거나 공유 hardware 기능용 `struct drm_private_state`를 추가할 수 있습니다.

Atomic update는 `drm_atomic_state` container 안에서 완전히 독립적인 structure 집합으로 조립·검증됩니다. Driver private state도 같은 container에서 추적합니다. Commit할 때만 driver와 modeset object에 적용하므로 rollback은 memory를 해제하고 framebuffer 같은 object reference를 놓는 것으로 끝납니다.

Atomic state structure의 locking은 내부적으로 `struct drm_modeset_lock`을 사용합니다. 일반적으로 driver에 lock을 노출하지 않고 `drm_atomic_get_crtc_state()`처럼 state를 복제하거나 조회하는 함수가 필요한 lock을 자동 획득해야 합니다. Lock은 software data structure만 보호하며 hardware commit 순서는 `struct drm_crtc_commit`으로 정렬합니다. 세부 주제는 이 장의 후속 절과 `drm_atomic_helper`를 함께 참조합니다.

Atomic Mode Setting
===================


.. kernel-render:: DOT
   :alt: Mode Objects and Properties
   :caption: Mode Objects and Properties

   digraph {
      node [shape=box]

      subgraph cluster_state {
          style=dashed
          label="Free-standing state"

          "drm_atomic_state" -> "duplicated drm_plane_state A"
          "drm_atomic_state" -> "duplicated drm_plane_state B"
          "drm_atomic_state" -> "duplicated drm_crtc_state"
          "drm_atomic_state" -> "duplicated drm_connector_state"
          "drm_atomic_state" -> "duplicated driver private state"
      }

      subgraph cluster_current {
          style=dashed
          label="Current state"

          "drm_device" -> "drm_plane A"
          "drm_device" -> "drm_plane B"
          "drm_device" -> "drm_crtc"
          "drm_device" -> "drm_connector"
          "drm_device" -> "driver private object"

          "drm_plane A" -> "drm_plane_state A"
          "drm_plane B" -> "drm_plane_state B"
          "drm_crtc" -> "drm_crtc_state"
          "drm_connector" -> "drm_connector_state"
          "driver private object" -> "driver private state"
      }

      "drm_atomic_state" -> "drm_device" [label="atomic_commit"]
      "duplicated drm_plane_state A" -> "drm_device"[style=invis]
   }

Atomic provides transactional modeset (including planes) updates, but a
bit differently from the usual transactional approach of try-commit and
rollback:

- Firstly, no hardware changes are allowed when the commit would fail. This
  allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
  userspace to explore whether certain configurations would work or not.

- This would still allow setting and rollback of just the software state,
  simplifying conversion of existing drivers. But auditing drivers for
  correctness of the atomic_check code becomes really hard with that: Rolling
  back changes in data structures all over the place is hard to get right.

- Lastly, for backwards compatibility and to support all use-cases, atomic
  updates need to be incremental and be able to execute in parallel. Hardware
  doesn't always allow it, but where possible plane updates on different CRTCs
  should not interfere, and not get stalled due to output routing changing on
  different CRTCs.

Taken all together there's two consequences for the atomic design:

- The overall state is split up into per-object state structures:
  :c:type:`struct drm_plane_state <drm_plane_state>` for planes, :c:type:`struct
  drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct
  drm_connector_state <drm_connector_state>` for connectors. These are the only
  objects with userspace-visible and settable state. For internal state drivers
  can subclass these structures through embedding, or add entirely new state
  structures for their globally shared hardware functions, see :c:type:`struct
  drm_private_state<drm_private_state>`.

- An atomic update is assembled and validated as an entirely free-standing pile
  of structures within the :c:type:`drm_atomic_state <drm_atomic_state>`
  container. Driver private state structures are also tracked in the same
  structure; see the next chapter.  Only when a state is committed is it applied
  to the driver and modeset objects. This way rolling back an update boils down
  to releasing memory and unreferencing objects like framebuffers.

Locking of atomic state structures is internally using :c:type:`struct
drm_modeset_lock <drm_modeset_lock>`. As a general rule the locking shouldn't be
exposed to drivers, instead the right locks should be automatically acquired by
any function that duplicates or peeks into a state, like e.g.
drm_atomic_get_crtc_state().  Locking only protects the software data
structure, ordering of committing state changes to hardware is sequenced using
:c:type:`struct drm_crtc_commit <drm_crtc_commit>`.

Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
coverage of specific topics.

Handling Driver Private State
-----------------------------

.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
   :doc: handling driver private state

Atomic Mode Setting Function Reference
--------------------------------------

.. kernel-doc:: include/drm/drm_atomic.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
   :export:

Atomic Mode Setting IOCTL and UAPI Functions
--------------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
   :doc: overview

.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
   :export:

CRTC, framebuffer, plane, connector와 encoder

CRTC abstraction과 color management 절은 scanout timing·pipeline state를 나타내는 CRTC core API와 color transform helper를 문서화합니다. Framebuffer abstraction은 userspace-created pixel storage를 KMS object로 다루는 interface를 제공합니다.

DRM format handling은 UAPI `drm_fourcc.h`의 format·modifier 정의와 kernel 내부 helper를 연결합니다. Dumb buffer object는 단순 userspace buffer allocation interface를 설명합니다.

Plane abstraction은 framebuffer를 CRTC에 배치하는 plane core, composition·blending, damage tracking, panic display 기능을 제공합니다. Display mode helper는 timing mode를 다루는 내부 type과 exported API를 제공합니다.

Connector abstraction은 실제 display endpoint와 probing·state interface를, writeback connector는 display output을 memory로 되돌리는 connector path를 문서화합니다. Encoder abstraction은 CRTC와 connector 사이의 routing object API를 제공합니다.

CRTC Abstraction
================

.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
   :doc: overview

CRTC Functions Reference
--------------------------------

.. kernel-doc:: include/drm/drm_crtc.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
   :export:

Color Management Functions Reference
------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
   :export:

.. kernel-doc:: include/drm/drm_color_mgmt.h
   :internal:

Frame Buffer Abstraction
========================

.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
   :doc: overview

Frame Buffer Functions Reference
--------------------------------

.. kernel-doc:: include/drm/drm_framebuffer.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
   :export:

DRM Format Handling
===================

.. kernel-doc:: include/uapi/drm/drm_fourcc.h
   :doc: overview

Format Functions Reference
--------------------------

.. kernel-doc:: include/drm/drm_fourcc.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_fourcc.c
   :export:

.. _kms_dumb_buffer_objects:

Dumb Buffer Objects
===================

.. kernel-doc:: drivers/gpu/drm/drm_dumb_buffers.c
   :doc: overview

Plane Abstraction
=================

.. kernel-doc:: drivers/gpu/drm/drm_plane.c
   :doc: overview

Plane Functions Reference
-------------------------

.. kernel-doc:: include/drm/drm_plane.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_plane.c
   :export:

Plane Composition Functions Reference
-------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_blend.c
   :export:

Plane Damage Tracking Functions Reference
-----------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_damage_helper.c
   :export:

.. kernel-doc:: include/drm/drm_damage_helper.h
   :internal:

Plane Panic Feature
-------------------

.. kernel-doc:: drivers/gpu/drm/drm_panic.c
   :doc: overview

Plane Panic Functions Reference
-------------------------------

.. kernel-doc:: include/drm/drm_panic.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_panic.c
   :export:

Display Modes Function Reference
================================

.. kernel-doc:: include/drm/drm_modes.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_modes.c
   :export:

Connector Abstraction
=====================

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: overview

Connector Functions Reference
-----------------------------

.. kernel-doc:: include/drm/drm_connector.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :export:

Writeback Connectors
--------------------

.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
  :doc: overview

.. kernel-doc:: include/drm/drm_writeback.h
  :internal:

.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
  :export:

Encoder Abstraction
===================

.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
   :doc: overview

Encoder Functions Reference
---------------------------

.. kernel-doc:: include/drm/drm_encoder.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
   :export:

KMS locking과 새 property 요구사항

KMS locking reference는 `drm_modeset_lock.c`의 locking 설명과 exported API, `drm_modeset_lock.h` 내부 interface를 제공합니다.

Property 문서는 주로 userspace developer를 대상으로 하며 driver API는 다른 절에서 다룹니다. KMS driver가 새 기능 지원을 위해 property를 추가할 수 있지만 새 property는 표준화되어야 합니다. 정확한 전체 name 문자열, enum이면 모든 유효 value name, 허용 value와 의미, property의 동작·사용법, 기존 property와의 상호작용을 문서화해야 합니다.

Core code에는 해당 object에 property를 등록하는 generic helper가 있어야 합니다. Property 내용은 core가 decode해 object의 associated state structure에 제공해야 하며 plane의 `struct drm_clip_rect`처럼 driver가 미리 계산할 값도 포함됩니다.

초기 state는 property가 도입되기 전 동작과 일치해야 합니다. Hardware의 고정 동작에 맞는 값일 수도 있고 boot 중 firmware가 남긴 state를 상속할 수도 있습니다. 합리적인 경우 IGT test도 제출해야 합니다.

역사적 이유로 비표준 driver-specific property가 존재합니다. Driver가 이를 지원하려면 가능한 범위에서 새 property 요구사항을 적용하고, 호환성을 위해 문서화한 동작이 기존 property의 사실상 의미와 일치해야 합니다. 처음 property를 추가한 driver 개발자는 이 작업을 도와야 하며 가능하면 문서화한 동작에 ACK해야 합니다.

KMS Locking
===========

.. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c
   :doc: kms locking

.. kernel-doc:: include/drm/drm_modeset_lock.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c
   :export:

KMS Properties
==============

This section of the documentation is primarily aimed at user-space developers.
For the driver APIs, see the other sections.

Requirements
------------

KMS drivers might need to add extra properties to support new features. Each
new property introduced in a driver needs to meet a few requirements, in
addition to the one mentioned above:

* It must be standardized, documenting:

  * The full, exact, name string;
  * If the property is an enum, all the valid value name strings;
  * What values are accepted, and what these values mean;
  * What the property does and how it can be used;
  * How the property might interact with other, existing properties.

* It must provide a generic helper in the core code to register that
  property on the object it attaches to.

* Its content must be decoded by the core and provided in the object's
  associated state structure. That includes anything drivers might want
  to precompute, like struct drm_clip_rect for planes.

* Its initial state must match the behavior prior to the property
  introduction. This might be a fixed value matching what the hardware
  does, or it may be inherited from the state the firmware left the
  system in during boot.

* An IGT test must be submitted where reasonable.

For historical reasons, non-standard, driver-specific properties exist. If a KMS
driver wants to add support for one of those properties, the requirements for
new properties apply where possible. Additionally, the documented behavior must
match the de facto semantics of the existing property to ensure compatibility.
Developers of the driver that first added the property should help with those
tasks and must ACK the documented behavior if possible.

Property type과 표준 KMS property 목록

Property core reference는 property type과 blob property 지원의 overview, 내부 interface, exported API를 제공합니다.

표준 property 문서는 connector 공통 property, HDMI 전용 connector property, analog TV property, CRTC·plane property를 구분합니다. Plane composition과 damage tracking, color management, tiled display group, explicit fencing, variable refresh, cursor hotspot도 각각 별도 property군으로 문서화됩니다.

Existing KMS Properties 절의 `kms-properties.csv` 표는 여러 module·driver가 노출하는 DRM property를 설명합니다. 표가 이미 매우 방대하므로 새 property를 이 CSV에 추가하면 안 되며, 대신 위쪽에 별도 절을 만들어 문서화해야 합니다.

Property Types and Blob Property Support
----------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_property.c
   :doc: overview

.. kernel-doc:: include/drm/drm_property.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_property.c
   :export:

.. _standard_connector_properties:

Standard Connector Properties
-----------------------------

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: standard connector properties

HDMI Specific Connector Properties
----------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: HDMI connector properties

Analog TV Specific Connector Properties
---------------------------------------

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: Analog TV Connector Properties

Standard CRTC Properties
------------------------

.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
   :doc: standard CRTC properties

Standard Plane Properties
-------------------------

.. kernel-doc:: drivers/gpu/drm/drm_plane.c
   :doc: standard plane properties

.. _plane_composition_properties:

Plane Composition Properties
----------------------------

.. kernel-doc:: drivers/gpu/drm/drm_blend.c
   :doc: overview

.. _damage_tracking_properties:

Damage Tracking Properties
--------------------------

.. kernel-doc:: drivers/gpu/drm/drm_plane.c
   :doc: damage tracking

Color Management Properties
---------------------------

.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
   :doc: overview

Tile Group Property
-------------------

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: Tile group

Explicit Fencing Properties
---------------------------

.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
   :doc: explicit fencing properties


Variable Refresh Properties
---------------------------

.. kernel-doc:: drivers/gpu/drm/drm_connector.c
   :doc: Variable refresh properties

Cursor Hotspot Properties
---------------------------

.. kernel-doc:: drivers/gpu/drm/drm_plane.c
   :doc: hotspot properties

Existing KMS Properties
-----------------------

The following table gives description of drm properties exposed by various
modules/drivers. Because this table is very unwieldy, do not add any new
properties here. Instead document them in a section above.

.. csv-table::
   :header-rows: 1
   :file: kms-properties.csv

Vertical blanking과 vblank work

Vertical blanking 절은 `drm_vblank.c`의 vblank handling 개요와 exported API, `drm_vblank.h` 내부 interface를 제공합니다. Display refresh의 blanking interval과 interrupt 처리에 필요한 core 기능을 모읍니다.

Vertical blank work 절은 `drm_vblank_work.c`의 vblank work 개요·exported API와 `drm_vblank_work.h` 내부 interface를 제공해 vblank 시점에 맞춰 work를 실행하는 기능을 문서화합니다.

Vertical Blanking
=================

.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
   :doc: vblank handling

Vertical Blanking and Interrupt Handling Functions Reference
------------------------------------------------------------

.. kernel-doc:: include/drm/drm_vblank.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
   :export:

Vertical Blank Work
===================

.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
   :doc: vblank works

Vertical Blank Work Functions Reference
---------------------------------------

.. kernel-doc:: include/drm/drm_vblank_work.h
   :internal:

.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
   :export: