diff --git a/index.html b/index.html index ab1a78e..62bca1f 100644 --- a/index.html +++ b/index.html @@ -1,7 +1,7 @@ TJ的技术博客

Kernel CFI failure实例分析

2024-06-01|stab-cfi
最近压测碰到一例内核死机, 提示CFI failure. 先了解下CFI: -Control-flow integrity (CFI) is a technique used to reduce the ability to redirect the execution of a program’s code in attacker-specified wa...

阅读全文

Linux kernel DRM overview

2024-05-25|dd-drm
I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me provide an overview of this...

阅读全文

我的PC组装升级记

2024-05-18|tools-pc
18年左右为了编译Android组装了一台PC，AMD AM4，2K，主要配置如下： +Control-flow integrity (CFI) is a technique used to reduce the ability to redirect the execution of a program’s code in attacker-specified wa...

阅读全文

Linux kernel DRM overview

2024-05-25|dd-drm
I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me start by getting an overvie...

阅读全文

我的PC组装升级记

2024-05-18|tools-pc
18年左右为了编译Android组装了一台PC，AMD AM4，2K，主要配置如下： 主板：技嘉 GA-A320M-S2H (rev. 1.x) CPU ：AMD Ryzen 3 2200G (盒装) 1100 (+mb) diff --git a/linux-kernel-drm-overview.html b/linux-kernel-drm-overview.html index a7a20b9..948f874 100644 --- a/linux-kernel-drm-overview.html +++ b/linux-kernel-drm-overview.html @@ -1,4 +1,4 @@ -Linux kernel DRM overview | TJ的技术博客

Linux kernel DRM overview

2024-05-25

I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me provide an overview of this.

+Linux kernel DRM overview | TJ的技术博客

Linux kernel DRM overview

2024-05-25

I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me start by getting an overview of this firstly.

DRM(Direct Rendering Manager) was initially designed for accessing GPU hardware, but it has expanded to cover more functions previously handled by userpace, such as GEM(Graphics Execution Manager) and KMS(kernel mode-setting).

The software architecture is as follows:

@@ -14,13 +14,13 @@
  • CRTC: Read pixel data from different planes and blends them together.
  • Connector: Phyical connector, like VGA, HDMI, DisplayPort(DP).
  • Encoder: Encodes the signal from CRTC for the connector.
    • -
  • Panel: The actual screen that diplays the image. Panel types include LCD(IPS, VA, TN) and OLED.
    • +
  • Panel: The actual screen that displays the image. Panel types include LCD(IPS, VA, TN) and OLED.
  • Monitor: Panel plus other components(power supply, connect port, etc.).
  • Bridge: Convert signals, such as MIPI DSI to eDP.

    • We can use libdrm/modetest to test KMS. The DRM device is /dev/dri/cardX, the code is in drivers/gpu/drm.

    OK, that’s all. No need to read kernel documents about DRM now, the wiki is enough.

    -

    references

      +

      References

      diff --git a/search.xml b/search.xml index 9c363b4..054a4cb 100644 --- a/search.xml +++ b/search.xml @@ -33,7 +33,7 @@ /linux-kernel-drm-overview.html - I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me provide an overview of this.

      DRM(Direct Rendering Manager) was initially designed for accessing GPU hardware, but it has expanded to cover more functions previously handled by userpace, such as GEM(Graphics Execution Manager) and KMS(kernel mode-setting).

      The software architecture is as follows:

      There are two parts: DRM core and DRM driver(GEM + KMS). Access the DRM via userspace libdrm to avoid duplicate code.

      GEM is the memory managerment in DRM. For example, userspace can use GEM to request memory to store a framebuffer or data required by GPU.

      KMS mode includes screen resolution, color depth and refresh rate.

      The display output pipeline is as follows:

      fb ->plane
            \
           crtc -> encoder -> bridge (optional) -> connector -> display device (monitor, laptop panel...)
            /
      fb ->plane
      • Framebuffer(fb): Includes pixel data for a single frame or image to be displayed on the screen.
      • Plane: Image source, framebuffer feed.
      • CRTC: Read pixel data from different planes and blends them together.
      • Connector: Phyical connector, like VGA, HDMI, DisplayPort(DP).
      • Encoder: Encodes the signal from CRTC for the connector.
      • Panel: The actual screen that diplays the image. Panel types include LCD(IPS, VA, TN) and OLED.
      • Monitor: Panel plus other components(power supply, connect port, etc.).
      • Bridge: Convert signals, such as MIPI DSI to eDP.

      We can use libdrm/modetest to test KMS. The DRM device is /dev/dri/cardX, the code is in drivers/gpu/drm.

      OK, that’s all. No need to read kernel documents about DRM now, the wiki is enough.

      references

      ]]>       + I have not touched Linux DRM before, although I’m very familiar with BSP. Now I need to fix display-related issues due to OpenHarmony porting, so let me start by getting an overview of this firstly.

      DRM(Direct Rendering Manager) was initially designed for accessing GPU hardware, but it has expanded to cover more functions previously handled by userpace, such as GEM(Graphics Execution Manager) and KMS(kernel mode-setting).

      The software architecture is as follows:

      There are two parts: DRM core and DRM driver(GEM + KMS). Access the DRM via userspace libdrm to avoid duplicate code.

      GEM is the memory managerment in DRM. For example, userspace can use GEM to request memory to store a framebuffer or data required by GPU.

      KMS mode includes screen resolution, color depth and refresh rate.

      The display output pipeline is as follows:

      fb ->plane
            \
           crtc -> encoder -> bridge (optional) -> connector -> display device (monitor, laptop panel...)
            /
      fb ->plane
      • Framebuffer(fb): Includes pixel data for a single frame or image to be displayed on the screen.
      • Plane: Image source, framebuffer feed.
      • CRTC: Read pixel data from different planes and blends them together.
      • Connector: Phyical connector, like VGA, HDMI, DisplayPort(DP).
      • Encoder: Encodes the signal from CRTC for the connector.
      • Panel: The actual screen that displays the image. Panel types include LCD(IPS, VA, TN) and OLED.
      • Monitor: Panel plus other components(power supply, connect port, etc.).
      • Bridge: Convert signals, such as MIPI DSI to eDP.

      We can use libdrm/modetest to test KMS. The DRM device is /dev/dri/cardX, the code is in drivers/gpu/drm.

      OK, that’s all. No need to read kernel documents about DRM now, the wiki is enough.

      References

      ]]>