架構

§1這條路上有哪些角色

先建立一件事：「CPU」不是一顆。M1 Pro 這顆 SoC 裡，跑 Linux 的那組核心叫 AP（Application Processor），旁邊還有十幾顆各自跑 Apple 韌體的協處理器。 顯示這條路上，AP 其實什麼都不直接做 —— 它在指揮別人。

§2device tree 把它們接起來

上面那些 driver 彼此完全不知道對方存在。 把它們綁在一起的是 device tree —— ARM 的硬體不會自我介紹，所以必須有人寫下「誰接誰」。 這台機器的接線在 arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi：

// 第 12 行：這一整條路要不要存在，由這個開關決定
#define ENABLE_DCPEXT_TYPEC

typec1: connector {                          // 第 188 行 —— 左前那個 USB-C 孔
        displayport = <&dcpext1>;           // 第 196 行 —— 這個孔的 DP 輸出來自 dcpext1
        ports {
                port@1 {
                        typec1_connector_ss: endpoint {
                                remote-endpoint = <&atcphy1_typec_lanes>;   // 第 211 行
                        };                   //   高速 lane 接到 atcphy1
                };
        };
};

&dcpext1 {                                   // 第 278 行
        phys = <&atcphy1 PHY_TYPE_DP>;       // 第 284 行 —— DCP 要用的 PHY 是 atcphy1 的 DP 模式
        mux-controls = <&atcphy1_xbar 0>;    // 第 286 行 —— 它要佔用 crossbar 的第 0 路
        mux-control-names = "dp-xbar";       // 第 287 行 —— driver 用這個名字去拿
};

§3driver 地圖

哪個檔案管哪一塊硬體，以及它對外掛出什麼 —— 最後一欄是重點， 那決定了別人能怎麼呼叫它。

§4它們之間怎麼交互

沒有任何一個 driver 直接呼叫另一個 driver 的函式。 全部走核心框架：一邊 register，另一邊靠 device tree 的接線去 get， 然後呼叫框架的通用 API，框架再轉給對方的 callback。 一共用到五組，把它們認完，這條路上就沒有黑箱了。

① Type-C mux framework —— 切實體 lane

tipd/core.c        typec_mux_set(cd321x->mux, &cd321x->state)   // 559, 599, 614, 628, 635
   ↓（框架查出 DT 接線指向 atcphy1）
phy/apple/atc.c    atcphy_mux_set()                              // 由 typec_mux_register(2374) 掛上

CD321x 的 driver 從頭到尾沒有 #include 過 atc.c 的任何東西。 它只知道「我有一個 mux」，那個 mux 是誰，是 device tree 第 211 行那條 remote-endpoint 決定的。

② DRM out-of-band hotplug —— 從 Type-C 跨進顯示

tipd/core.c        drm_connector_oob_hotplug_event(cd321x->connector_fwnode, status)  // 694, 754
   ↓（框架用 fwnode 找到對應的 drm_connector）
apple_drv.c        apple_connector_oob_hotplug()                 // 87，由 .oob_hotplug_event(250) 掛上
   ↓
dcp.c              dcp_dptx_connect_oob() / dcp_dptx_disconnect_oob()   // 433 / 439

「out-of-band」的意思是：這個 hotplug 訊號不是從顯示線本身收到的， 是 USB-PD 那一側告訴顯示子系統的。一般 DP 螢幕靠 HPD pin，這裡靠 CD321x 轉述 —— 所以 Type-C 的 driver 才會需要認識一個 DRM connector。

③ mux framework —— 佔用 crossbar

dcp.c              devm_mux_control_get(dev, "dp-xbar")          // 1262（名字來自 DT 第 287 行）
dcp.c              mux_control_select(dcp->xbar, mux_index)      // 1267
   ↓
mux/apple-display-crossbar.c                                     // devm_mux_chip_register(401)

④ PHY framework —— 但方向是反的

dptxep.c           phy_set_mode_ext(dptx->atcphy, PHY_MODE_DP, dcp->index)  // 484
dptxep.c           phy_configure(dptx->atcphy, &dptx->phy_ops)             // 322, 429
   ↓
phy/apple/dptx.c   dptx_phy_set_mode(526) / dptx_phy_configure(570)
                   → dptx_phy_activate(125) / set_link_rate(324) / set_active_lane_count(81)

⑤ RTKit / AFK / EPIC —— 跟 DCP 講話的三層

所以 dmesg 裡那句 new service DCPDPService on channel 17/19 是這一層在講話： DCP 韌體宣告它開了一個服務，AP 這邊把 dptxep.c 掛上去。 服務沒開起來，dcp_dptx_connect() 第一件事就是拒絕 （dptx service for port %d not enabled，dcp.c:372）。

§5為什麼要這麼多層

第一次看會覺得繞，但每一層都在解決一個具體問題：