aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/gpu/komeda-kms.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/gpu/komeda-kms.rst')
-rw-r--r--Documentation/gpu/komeda-kms.rst4
1 files changed, 2 insertions, 2 deletions
diff --git a/Documentation/gpu/komeda-kms.rst b/Documentation/gpu/komeda-kms.rst
index eb693c857e2d..633a016563ae 100644
--- a/Documentation/gpu/komeda-kms.rst
+++ b/Documentation/gpu/komeda-kms.rst
@@ -328,7 +328,7 @@ of course we’d better share as much as possible between different products. To
achieve this, split the komeda device into two layers: CORE and CHIP.
- CORE: for common features and capabilities handling.
-- CHIP: for register programing and HW specific feature (limitation) handling.
+- CHIP: for register programming and HW specific feature (limitation) handling.
CORE can access CHIP by three chip function structures:
@@ -481,7 +481,7 @@ Build komeda to be a Linux module driver
Now we have two level devices:
- komeda_dev: describes the real display hardware.
-- komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS.
+- komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS.
All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev,
the module driver is only a simple wrapper to pass the Linux command