docs: ASCII typography and style normalization across all repo text

Replace every em dash with real punctuation (rewrites, not hyphen swaps)
in docs, code comments, scripts, configs, and the port records; convert
en dashes, curly quotes, ellipsis glyphs, arrows, and section signs to
ASCII; drop machine-writing tell phrases from living docs. ADR titles
now use a colon. The M2 bring-up DTS model string carried an em dash
into the patch series and its record echoes; fixed at both, and the full
series re-verified to apply cleanly onto pristine 6.18.46. One comment
in freshness.h deliberately names the em dash glyph the UI renders as
the unknown mark; that is data, kept as prose naming it.

Verified: cargo tests (sim, config-lint, rs485-bridge), shellcheck,
both driver MC/DC harnesses, patches-apply.
This commit is contained in:
BFE Engineering
2026-08-31 12:31:27 -06:00
parent 80d9a9539b
commit 42fb386f60
111 changed files with 1261 additions and 1261 deletions
+10 -10
View File
@@ -1,13 +1,13 @@
# M4 display (VOP) port to 6.18
# M4: display (VOP) port to 6.18
The RV1106 VOP is the older RV-series "lite" VOP (`rockchip,rv1106-vop`, VOP_VERSION
2.0xc), driven by mainline's `rockchip_drm_vop.c` (VOP1), **not** VOP2. Its sibling
**rv1126** is already in mainline 6.18, so the register data is a small reuse like
**rv1126** is already in mainline 6.18, so the register data is a small reuse, like
the clk/pinctrl ports.
## The driver delta (`rockchip_vop_reg.c`)
`rv1106_vop_data.c.frag` add this `vop_data` (reuses rv1126's common/modeset/
`rv1106_vop_data.c.frag`: add this `vop_data` (reuses rv1126's common/modeset/
output/misc/intr/win sub-structs; only the version, the smaller 1280² raster, and
the **`VOP_FEATURE_INTERNAL_RGB` feature** differ), plus the match entry:
@@ -15,18 +15,18 @@ the **`VOP_FEATURE_INTERNAL_RGB` feature** differ), plus the match entry:
{ .compatible = "rockchip,rv1106-vop", .data = &rv1106_vop },
```
`VOP_FEATURE_INTERNAL_RGB` is essential it is what makes `vop_bind` call
`VOP_FEATURE_INTERNAL_RGB` is essential: it is what makes `vop_bind` call
`rockchip_rgb_init()` for the parallel-RGB output (rv1126 routes through MIPI and
omits it).
## The DT (in `../dts/rv1106-warden.dts`)
- `&vop` enabled + **named resets** `resets = <&cru SRST_H_VOP>, <&cru SRST_D_VOP>;
reset-names = "ahb", "dclk";` the mainline driver requires these (the vendor
reset-names = "ahb", "dclk";`, the mainline driver requires these (the vendor
node omits them; without them: `vop_bind: failed to get ahb reset`).
- `&vop_out_rgb` repointed straight to the panel (mainline has no separate rgb
node `rockchip_rgb_init` is a helper the VOP calls).
- `panel` (`panel-dpi`, 720×720, 30 MHz) + `pwm-backlight` on `&pwm1`.
node: `rockchip_rgb_init` is a helper the VOP calls).
- `panel` (`panel-dpi`, 720x720, 30 MHz) + `pwm-backlight` on `&pwm1`.
## Verified on warden-c8a3 (2026-08-24)
@@ -36,14 +36,14 @@ rockchip-drm display-subsystem: bound ff990000.vop
[drm] Initialized rockchip 1.0.0 for display-subsystem on minor 0
```
`/dev/dri/card0` is present and the **PWM backlight is up** (`/sys/class/backlight`,
brightness settable). **The VOP driver port is validated** the register data,
brightness settable). **The VOP driver port is validated**: the register data,
version, feature, and resets are right.
## RESOLVED full UI renders on the panel (2026-08-25)
## RESOLVED: full UI renders on the panel (2026-08-25)
The connector *and* the deeper black-screen chain that followed it are fixed; the
86-Panel now draws the full WardenOS Dashboard on 6.18 (`_b`), verified by webcam.
The two final root causes were VOP driver bugs `rgb_dclk_pol` hardcoded inverted,
The two final root causes were VOP driver bugs: `rgb_dclk_pol` hardcoded inverted,
and the wrong primary scanout window (rv1106 scans out via **WIN1**, not WIN2).
See **`VERIFIED.md`** for the complete bring-up chain, the `_a`-vs-`_b` register
diff that pinned it down, and every file changed.
+19 -19
View File
@@ -1,8 +1,8 @@
# Display (VOP + RGB panel) VERIFIED on warden-c8a3 (2026-08-25)
# Display (VOP + RGB panel): VERIFIED on warden-c8a3 (2026-08-25)
The 86-Panel renders the **full WardenOS Dashboard UI** on our self-built Linux
6.18.46 (`_b` slot), pixel-identical to the stock 5.10 `_a` slot. Verified by
webcam pointed at the physical panel (pixels can't be checked over serial/ssh)
webcam pointed at the physical panel (pixels can't be checked over serial/ssh);
`warden-ui -b DRM` drawing the Dashboard: nav sidebar, "Wellhead 03" site card,
Mesh/WAN/LAN/RS485 status rows, correct colors, no banding, no colour swap.
@@ -13,10 +13,10 @@ black-screen chain that followed it).
1. **Connector never created** (`Cannot find any crtc`): `CONFIG_ROCKCHIP_RGB`
was not set, AND the vendor `&rgb` bridge node's dangling endpoint
(`rgb_in_vop -> vop_out_rgb`) read to fw_devlink as a voppanel dependency
(`rgb_in_vop -> vop_out_rgb`) read to fw_devlink as a vop<->panel dependency
cycle, so the VOP probed before the panel. Fix: enable `ROCKCHIP_RGB` +
`/delete-node/ &rgb;` so `vop_out_rgb <-> panel_in_vop` is the only graph link
(rockchip_rgb_init then defers + retries and finds the panel `LVDS-1`).
(rockchip_rgb_init then defers + retries and finds the panel -> `LVDS-1`).
2. **Backlight dark**: `&pwm1` had `pinctrl-names = "active"`; mainline
pwm-rockchip relies on the driver core auto-applying the **`"default"`** state,
so the PWM pin was never muxed. Fix: rename to `"default"`.
@@ -37,22 +37,22 @@ black-screen chain that followed it).
## The two root causes of the final "backlit-black" (VOP driver bugs)
With connector + backlight + pins + panel-init all correct, the screen was still
physically black (backlight on, `LVDS-1` connected, VOP streaming, fb0 720×720,
`modetest`/splash written) the classic "everything healthy, glass dark" state.
physically black (backlight on, `LVDS-1` connected, VOP streaming, fb0 720x720,
`modetest`/splash written): the classic "everything healthy, glass dark" state.
Found by dumping the VOP register block `0xff990000` on the **working `_a` slot**
and diffing against `_b` (same SoC, same register map):
**Bug 1 DCLK polarity inverted.** `rockchip_drm_vop.c` hardcodes
**Bug 1: DCLK polarity inverted.** `rockchip_drm_vop.c` hardcodes
`rgb_dclk_pol = 1` for the LVDS/RGB output. The panel latches pixel data on the
**non-inverted** edge `_a` reads `PX30_DSP_CTRL0` (0xff990020) = `0x1`
**non-inverted** edge: `_a` reads `PX30_DSP_CTRL0` (0xff990020) = `0x1`
(rgb_dclk_pol bit1 = **0**). The vendor 5.10 derives it as
`(bus_flags & PIXDATA_DRIVE_NEGEDGE) ? 1 : 0`, which is 0 for this panel. With the
inverted clock the panel samples RGB on the wrong edge black. **Fix:** set
inverted clock the panel samples RGB on the wrong edge -> black. **Fix:** set
`rgb_dclk_pol` to 0 in the `DRM_MODE_CONNECTOR_LVDS` case.
**Bug 2 wrong primary scanout window.** The rv1106 VOP scans out through
**Bug 2: wrong primary scanout window.** The rv1106 VOP scans out through
**WIN1**, but our port reused rv1126's win table (`win0`-overlay + **`win2`**-primary).
The vendor `rv1106_vop_win_data` is `{ NULL-win0, rk3366_lit_win1_data-primary }`
The vendor `rv1106_vop_win_data` is `{ NULL-win0, rk3366_lit_win1_data-primary }`,
i.e. WIN1 (`PX30_WIN1_*` at 0x090). Mainline was configuring WIN2, which never
reaches this SoC's RGB interface, so WIN1 stayed all-zero and nothing scanned out.
Register evidence (`_a` working vs `_b` broken, before the fix):
@@ -62,26 +62,26 @@ Register evidence (`_a` working vs `_b` broken, before the fix):
| 0x090 | WIN1_CTRL0 (enable) | `0x00000001` | `0x00000000` |
| 0x098 | WIN1_VIR (stride) | `0x000002D0` (720) | `0x00000000` |
| 0x0a0 | WIN1_MST (fb addr) | `0x0F900000` | `0x00000000` |
| 0x0a4 | WIN1_DSP_INFO (size)| `0x02CF02CF` (720×720) | `0x00EF013F` (stale) |
| 0x0a4 | WIN1_DSP_INFO (size)| `0x02CF02CF` (720x720) | `0x00EF013F` (stale) |
**Fix:** `rv1106_vop_win_data[] = { { .phy = &px30_win1_data, PRIMARY } }`
(`px30_win1_data` already exists in mainline over `PX30_WIN1_*` just wasn't wired
for rv1106). After the fix `_b` reads WIN1_CTRL0=1, WIN1_DSP_INFO=0x02CF02CF
(`px30_win1_data` already exists in mainline over `PX30_WIN1_*`, just wasn't wired
for rv1106). After the fix `_b` reads WIN1_CTRL0=1, WIN1_DSP_INFO=0x02CF02CF:
matching `_a`.
## Files changed (in research/linux-6.18.46)
- `drivers/gpu/drm/rockchip/rockchip_drm_vop.c` `rgb_dclk_pol` 1 0 (LVDS case).
- `drivers/gpu/drm/rockchip/rockchip_vop_reg.c` `rv1106_vop_win_data` uses
- `drivers/gpu/drm/rockchip/rockchip_drm_vop.c`: `rgb_dclk_pol` 1 -> 0 (LVDS case).
- `drivers/gpu/drm/rockchip/rockchip_vop_reg.c`: `rv1106_vop_win_data` uses
`px30_win1_data` as the single PRIMARY window (was rv1126's win0+win2).
- `drivers/gpu/drm/panel/panel-simple.c` `panel_dpi_probe()` reads DT `bus-format`.
- `arch/arm/boot/dts/rockchip/rv1106-warden.dts` `&vop` pinctrl `<&lcd_pins>`;
- `drivers/gpu/drm/panel/panel-simple.c`: `panel_dpi_probe()` reads DT `bus-format`.
- `arch/arm/boot/dts/rockchip/rv1106-warden.dts`: `&vop` pinctrl `<&lcd_pins>`;
`&pwm1` pinctrl "default"; `/delete-node/ &rgb`; panel `bus-format` RGB666,
no reset-gpios.
## Known separate issue (NOT display)
`_b` still cold-reboots periodically (pre-existing `_b` general-stability issue,
independent of the display the panel renders correctly the whole time it is up).
independent of the display: the panel renders correctly the whole time it is up).
Tracked separately; the high-bootlimit env (`bootlimit=10000`) keeps these reboots
from tripping `altbootcmd=download` into the loader during bring-up.