The data-path page starts after the panel already works. This one is about everything before that: what is physically inside the module, how it is wired, the order its supplies have to come up in, and — when the screen stays dark — which command to run at which block. Four figures, one small-panel module.数据通路那一页，是从屏已经能亮之后讲起的。这一页讲之前的事：模组里面物理上有什么、怎么接线、供电必须按什么顺序上来，以及屏一直不亮的时候，在哪一块敲哪条命令。四张图，一块小尺寸屏模组。
Every kernel path named on this page was read out of a real tree — Linux 4.14.139 — and carries a file and a line number in the last section. The panel is a representative small-panel module: the layer count, the pin assignment and the timing minima are typical of that class of part rather than a specific product, and each figure says so on its face. Measure your own stack and read your own datasheet before quoting any number here.这一页提到的每一条内核路径，都是从一棵真实的树里读出来的 —— Linux 4.14.139 —— 最后一节逐条附文件和行号。屏本身是一块有代表性的小尺寸模组：层数、引脚分配、时序下限都是这一类器件的典型值，不是某个具体型号，每张图上也都写明了这一点。要引用这里任何一个数字之前，先量自己的叠层、读自己那块屏的规格书。
A block diagram will tell you the display controller talks to the panel. It will not tell you that between the glass you touch and the light you see there are twelve distinct materials, that two of them are adhesive and cure once, or that the layer carrying the pixel transistors also carries the electrode the touch controller transmits on. That last one is not a curiosity. It is the reason a display-side stall can take touch down with it while every touch register still reads back normal — and no block diagram can show it, because at that level the two subsystems look completely separate.框图会告诉你显示控制器连着屏。它不会告诉你：你手指碰到的玻璃和你看到的光之间隔着十二种不同的材料，其中两层是胶、固化一次就回不去，以及承载像素晶体管的那一层，同时也承载着触摸控制器发射用的电极。最后这件事不是冷知识。它就是「显示侧一卡，触摸跟着停，而触摸寄存器读回来全是正常值」的原因 —— 而任何框图都画不出来，因为在框图那个层次上，这两个子系统看起来完全是分开的。
One piece of metal, two jobs, time-shared同一片金属，两个岗位，分时轮着用
On a panel with touch integrated into the display, the common electrode the display drives and the transmit electrode the touch scan drives are the same conductor. They take turns. So the failure that catches people is not “touch is broken” — it is that touch went quiet because the display half stopped handing the line over, and every register on the touch side still reads exactly as it should. If you are chasing a touch problem and the display side has any complaint at all, settle the display side first.触摸做进显示里的屏，显示驱动的公共电极和触摸扫描的发射电极是同一根导体，两边轮流用。所以真正咬人的故障不是「触摸坏了」，而是显示那一半不再交出这根线，触摸就跟着安静了 —— 而触摸侧每一个寄存器读回来都完全正常。查触摸问题的时候，只要显示侧有任何异常，先把显示侧弄清楚。
A pinout has to be two things at once: the row of pads drawn the way the part is actually built, and the table of what each one carries. A table on its own cannot be checked against the part in your hand. A strip on its own does not tell you what any pad is. And the mistake that costs a board is neither — it is that the drawing was made from the component side and read from the pad side, which mirrors it end to end.引脚图必须同时是两样东西：按实物真实排法画出来的那一排焊盘，和「每一根是什么」的表。光有表，没法拿实物对着核；光有排布图，不知道每根是什么。而真正会烧板子的错误两者都不是 —— 是图从元件面画、人从焊盘面读，左右整个镜像了。
Four supplies, a reference clock, a reset line and a backlight — and the only thing that makes them a panel rather than a pile of rails is the order and the waiting. Each gap in the figure has a number on it, and each number is there because something visible happens when you take it away: a panel that never lights, a white flash at boot, or an image that lingers for a second after power-down. Bring-up bugs cluster here because the sequence is split across two driver callbacks, and it is easy to move one step across that boundary without noticing.四路电源、一个参考时钟、一根复位、一路背光 —— 让它们成为一块屏而不是一堆电源轨的，只有顺序和等待。图上每一段间隔都标了数字，而每个数字之所以在那儿，是因为拿掉它就会看见后果：屏根本不亮、开机闪一下白、或者断电后画面还残留一秒。点亮阶段的问题集中在这里，因为这个顺序被拆在两个驱动回调里，很容易在没察觉的情况下把某一步挪过了边界。
An architecture diagram leaves you knowing the shape of the system and still not knowing what to type. So this one pins the exact path under every block, and colours it by consequence rather than by category: green only reads, gold changes hardware or kernel state. Nobody arrives at a bring-up session holding a block diagram — they arrive holding a symptom, which is why the left column, not the architecture, is the entry point.架构图能让你知道系统长什么样，但还是不知道该敲什么。所以这张图把具体路径钉在每一块下面，并且按后果上色，不按类别上色：绿色只读，金色会改硬件或内核状态。没有人是捧着框图进点亮现场的，进来时手里拿的是一个现象 —— 所以入口是左边那一列，不是架构本身。
A missing debugfs file is not proof the block is idledebugfs 里少一个文件，不等于那一块没在工作
Everything under /sys/kernel/debug exists only where debugfs is mounted and the matching kernel option was built in. On a lean product config half of these paths are simply absent, and reading that absence as “nothing is happening here” sends people down the wrong branch for hours. Check the option before you check the file./sys/kernel/debug 下面的东西，只有在挂了 debugfs 且编进了对应内核选项时才存在。产品配置精简过之后，这些路径有一半根本不在，而把「不在」读成「这里什么都没发生」，能让人在错误的分支上待好几个小时。先确认选项，再去看文件。
Read out of Linux 4.14.139. Line numbers move between versions; the point of listing them is that each claim was checked against a tree rather than recalled, and that you can run the same check on yours.全部从 Linux 4.14.139 里读出来。行号会随版本变；列出来的意义是：每一条都是对着一棵树查过的，不是凭印象写的，而且你可以在自己的树上跑同一次检查。
fs/proc/interrupts.c:51 — created by proc_create("interrupts", …).fs/proc/interrupts.c:51 —— 由 proc_create("interrupts", …) 建立。drivers/clk/clk.c:2307 — debugfs_create_file("clk_summary", …).drivers/clk/clk.c:2307 —— debugfs_create_file("clk_summary", …)。drivers/regulator/core.c:4495.drivers/regulator/core.c:4495。drivers/pinctrl/pinmux.c:680.drivers/pinctrl/pinmux.c:680。drivers/gpio/gpiolib.c:3794.drivers/gpio/gpiolib.c:3794。drivers/dma-buf/dma-buf.c:1169.drivers/dma-buf/dma-buf.c:1169。drivers/gpu/drm/drm_atomic.c:1815 — the state entry in the DRM debugfs list.drivers/gpu/drm/drm_atomic.c:1815 —— DRM debugfs 列表里的 state 一项。drivers/gpu/drm/drm_sysfs.c:233 — DEVICE_ATTR_RO(enabled).drivers/gpu/drm/drm_sysfs.c:233 —— DEVICE_ATTR_RO(enabled)。lib/dynamic_debug.c:967 — the only gold pill on the figure, because writing to it changes kernel state.lib/dynamic_debug.c:967 —— 图上唯一一颗金色药丸，因为往里写会改内核状态。drivers/base/dd.c:303 — sysfs_create_link(&dev->kobj, …, "driver"), created only when the bind succeeds, which is why its absence answers “did it bind”.drivers/base/dd.c:303 —— sysfs_create_link(&dev->kobj, …, "driver")，只有绑定成功才建立，所以「它在不在」正好回答「绑上了没有」。include/drm/drm_panel.h:37-70 — the header states that .prepare() turns the panel on and .enable() typically turns on the backlight. That is the boundary the power sequence is split across.include/drm/drm_panel.h:37-70 —— 头文件里写明 .prepare() 负责把屏打开、.enable() 通常负责点背光。上电时序正是被这条边界切成两半的。The deferred-probe file is not in this treedeferred-probe 那个文件不在这棵树里
An earlier draft of the debug map carried /sys/kernel/debug/devices_deferred. Grepping 4.14.139 found nothing — that file arrived in a later kernel. Rather than ship a path that cannot be checked here, the figure asks the question a different way: the driver symlink under a device exists only after the bind succeeded, and that holds in every tree.这张图的早先一版写的是 /sys/kernel/debug/devices_deferred。在 4.14.139 上 grep 什么都没有 —— 那个文件是后来的内核才加的。与其发一条在这里核不了的路径，不如换个问法：设备目录下的 driver 符号链接只有在绑定成功之后才存在，而这一点在任何一棵树上都成立。