[RFC,v8] arm64: allwinner: add TrimUI Smart Pro (A133) board support

Board bring-up for the TrimUI Smart Pro handheld (Allwinner A133 Plus):

- New board DTS (sun50i-a133-trimui-smartpro.dts): display pipeline
  (mixer/TCON/DSI/D-PHY), regulators, MMC, PWM backlight.
- New OTM1289A/ER68576 DSI panel driver (panel-orisetech-otm1289a.c),
  including real panel timings and DCS init sequence.
- New PWM driver for this SoC's newer-generation PWM IP
  (pwm-sun50i-a133.c), with binding doc.
- sun8i_mixer: A133 DE2 mixer0/mixer1 configs.
- sun8i_tcon_top: A133 quirks entry, plus two new helpers
  (sun8i_tcon_top_set_dsi_gate/set_de0_port) needed because this
  board's TCON quirks table has no .set_mux callback to reach them
  through the existing paths.
- sun4i_tcon: CPU/8080-interface DSI bring-up (sun4i_tcon0_mode_set_cpu
  register formulas, an hrtimer-driven TRIGGER_START retrigger, IRQ
  ordering/ack fixes) plus TCON-TOP wiring for this board's DSI clock
  gate and DE0 port routing. All of the CPU/8080-interface-specific
  additions are gated behind a new, more specific
  "allwinner,sun50i-a133-tcon-lcd" compatible string
  (dsi_cpu_needs_retrigger quirk field), so none of it affects
  Pinephone/Pinetab (A64), the one other real board sharing this
  driver's shared DSI/CPU-mode code path.
- sun6i_mipi_dsi: an additional DSI_START_TRI instruction-jump-table
  case for continuous per-frame retriggering (distinct from the
  existing one-shot HS-clock-enable case), a DRQ_SET formula fix, and
  reordering the HS-clock-enable step to run before the panel's DCS
  init sequence.
- ccu-sun50i-a100: CLK_SET_RATE_PARENT on the tcon-lcd0 clock so its
  rate request can actually explore parent PLL rates.

Sending as RFC rather than waiting for the display to fully work:
posting the board/DTS foundation now so it's in front of people who
know this hardware, rather than sitting on it indefinitely.

Known issue, and the actual reason for the RFC tag: the panel attaches
and the backlight lights, but no pixel data reaches it.
TCON0_CPU_IF_REG's TRIGGER_START bit (a documented self-clearing
one-shot) never self-clears, despite the rest of the pixel pipeline
matching a working vendor system register-for-register -- every
static register value, D-PHY lane state, control-flow/sequencing
cross-referenced against a symbol-resolved decompile of the vendor
kernel, and even measured real-time timing all confirmed matching.
Full writeup, including what's been ruled out and how:
https://github.com/leow149/trimui-a133-mainline-port/blob/main/COMMUNITY_HELP_REQUEST.md

If anyone recognizes this symptom on the CPU/8080-interface DSI path,
or can spot something the writeup missed, I would very much like to
hear about it.

Cc: Chen-Yu Tsai <wens@kernel.org>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Samuel Holland <samuel@sholland.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Paul Kocialkowski <paulk@sys-base.io>
Signed-off-by: leow149 <leow149@lucidmail.xyz>
---

Changelog (kept below the cut, not in the commit message -- see the
automated-review replies on this thread for full per-finding detail):

v1 -> v2: Fixed sun6i_dsi_clear_int_status() using regmap_update_bits()
on a write-1-to-clear register, which silently no-op'd the write and
broke the retrigger timer's edge detection. Also fixed a timer/IRQ not
being torn down on CRTC disable, an IRQF_NO_AUTOEN regression that
would have permanently disabled vblank for other boards sharing this
TCON code, a spurious-vblank issue from treating bare FSYNC_INT as a
frame event, a clock-gate write getting silently undone by "disable
unused clocks", a PWM register race across channels, a PWM 100%-duty
truncation bug, a divide-by-zero guard, and a DT schema gap. Hardware
testing after all of the above showed the regmap fix, while real, did
NOT resolve the core TRIGGER_START symptom. That same testing turned
up two more real, hardware-confirmed bugs, also fixed here: TCON0's
own interrupt line storming at tens of thousands of firings/sec,
tripping genirq's "nobody cared" protection and permanently killing
the IRQ handler's own retrigger backstop -- fixed by treating every
firing as handled unconditionally in DSI/CPU mode, since this driver
is the line's only legitimate consumer in that mode; and
sun6i_dsi_encoder_enable() enabling both VIDEO_VBLK and VIDEO_LINE on
DSI's own interrupt register when a live vendor register dump on a
working reference system shows only VIDEO_VBLK enabled -- matched
vendor exactly. Neither of these, nor the regmap fix, resolved the
core bug.

v2 -> v3: Fixed the retrigger timer racing sun6i_dsi_encoder_enable()
on a guessed 1000ms wall-clock delay instead of sequencing on real
completion (added a tcon back-reference so encoder_enable() arms the
timer itself once actually done, via a new
sun4i_tcon_dsi_start_retrigger()). Rejected two atomic-context
sleeping claims (disable_irq()/mutex_lock()/msleep()) as false
positives, checked directly against drm_atomic_helper_commit_tail()'s
own wait_for_vblanks() call chain and the PWM core's own
pwm_apply_might_sleep() naming. Answered a question about whether
TRI_FINISH_ENABLE being unset blocks the retrigger backstop, using
data already on hand: a working vendor system's live GINT0 dump
(0x00000a00) shows TRI_FINISH_INT's status bit asserting without its
own enable too, same as FSYNC -- not an untested assumption.

v3 -> v4: Fixed both sun4i_tcon_regmap_config and
sun6i_dsi_regmap_config missing fast_io -- without it, regmap defaults
to mutex-based locking, a sleep-in-hardirq hazard given
sun4i_tcon_handler() is a genuine non-threaded hardirq handler
concurrently accessed by the retrigger hrtimer. Fixed by adding
fast_io and switching to spinlock-based locking (verified against
regmap_lock_spinlock()'s spin_lock_irqsave() usage), and switching the
retrigger timer to HRTIMER_MODE_REL_SOFT while here, moving its
frequent callback out of genuine hardirq context. Fixed
sun6i_dsi_tri_start()/read_int_status()/clear_int_status() missing
EXPORT_SYMBOL -- a real modular-build failure (CONFIG_DRM_SUN4I=m
would fail to resolve these across the sun4i_tcon.c/sun6i_mipi_dsi.c
module boundary), not just a modpost nag. Fixed a non-DSI enable_irq()
call living in sun4i_tcon_mode_set(), which a plain DPMS off/on cycle
never calls again -- moved to sun4i_tcon_set_status()'s enable=true
branch, symmetric with the existing disable=false branch. Swapped
CLK_IS_CRITICAL for CLK_IGNORE_UNUSED on the TCON-TOP DSI gate (the
former forces the clock, and its parent PLL, permanently on -- an
unintended power regression; the latter exempts the same
disable_unused sweep without forcing anything on). Rejected the same
atomic-context claim reapplied to otm1289a's msleep() and
sun4i_tcon_set_status()'s disable_irq(), and a CPU-hog concern about
unconditionally treating every DSI/CPU-mode IRQ firing as handled --
accepted as a real, documented trade-off (the alternative, letting
genirq disable the line, is empirically worse), not fixed.

v4 -> v5: Fixed a bus-fault race between sun6i_dsi_encoder_disable()
gating DSI clocks/reset and this driver's own retrigger timer/IRQ
teardown running later, by moving the teardown into
sun6i_dsi_encoder_disable() itself (closing the window at its actual
source, via a new sun4i_tcon_dsi_stop_retrigger()). Fixed the GINT0
acknowledge write missing TRI_COUNTER_INT (a potential hard lockup if
it were ever the bit driving the level line). Hardened (not fully
fixed -- it's a narrower, pre-existing TOCTOU shared with the pristine
hdmi_src/de_config functions) the sun8i_tcon_top raw
of_find_device_by_node()/dev_get_drvdata() lookup with a NULL guard;
this driver's .remove() (pristine, unmodified here) was confirmed to
correctly tear down the whole DRM aggregate first, contradicting an
earlier, incorrect claim that it had no .remove() at all. Found and
fixed a real quirks-scoping gap: this board's TCON0 DT node reused
sun8i_a83t_lcd_quirks verbatim with real A83T hardware, so several of
this series' changes applied to every DSI board sharing that struct
(including Pinephone/Pinetab on A64). Fixed via a new
"allwinner,sun50i-a133-tcon-lcd" compatible string and a new
dsi_cpu_needs_retrigger quirk field gating every one of this series'
additions to sun4i_tcon0_mode_set_cpu(), verified against
drivers/of/base.c's actual DT compatible-matching algorithm. (TBS-A711
on A83T, cited earlier as another affected board, turned out to be
LVDS on checking its DTS, not DSI -- corrected.)

v5 -> v6: Fixed a PWM clock-gate leak: pwm_a133_apply()'s disable path
cleared PWM_A133_PER_REG's channel enable bit but never cleared the
matching PWM_A133_PCGR_REG channel clock-gate bit, leaving a disabled
channel's clock running indefinitely. Fixed a DT binding schema gap:
allwinner,sun8i-r40-tcon-top.yaml required port@4/port@5
unconditionally across every compatible in the file, which this
board's HDMI-less tcon-top node can't satisfy -- restructured the
schema so those ports are required per-variant instead, checked
against R40/D1/H6's real in-tree dtsi and verified with dt-validate
against real compiled DTBs (this board's own, and a real upstream H6
one): the old schema genuinely rejects this board's DTB, the fixed one
accepts both. Rejected the same atomic-context claims again, and a
retrigger-timer TOCTOU claim (not reachable: it requires
TRI_FINISH_INT pending before TRIGGER_START has ever been written even
once).

v6 -> v7: Fixed a real IRQ re-enable race: a DPMS off/on cycle's
sun4i_tcon_dsi_stop_retrigger() masks the IRQ but never acks GINT0, so
a stale TRI_FINISH_INT/FSYNC_INT left latched from before the disable
can fire the hardirq the instant sun4i_tcon_dsi_retrigger_timer_fn()
re-enables it, double-kicking TRIGGER_START against this same
function's own about-to-happen kick. Fixed by clearing GINT0 right
before that enable_irq() call. Fixed the retrigger timer's own stop
condition never triggering once the hardirq-driven backstop is fast
enough to always win the race and keep TRIGGER_START looking busy from
the timer's perspective -- it would otherwise poll forever as a
low-frequency CPU hog instead of handing off. Fixed by adding an
explicit dsi_irq_retriggered flag the hardirq handler sets once it
successfully retriggers a frame, which the timer checks instead of
relying on sampling a transient register bit. Narrowed (not
eliminated) a separate, pre-existing write-0-to-clear TOCTOU window on
the same GINT0 acknowledge, by moving the ack earlier in the handler,
before the slower vblank/page-flip work. Rejected a front/back-porch-
swap claim on the panel's drm_display_mode: independently verified
against sun6i_dsi_setup_burst()'s DRQ_SET formula and a live register
read that the current horizontal front-porch value (88, not the
naively-derived 72) is the one already proven correct against real
hardware -- 72 was tried previously and directly disproven this same
way. Also caught and fixed a stale comment on that same mode struct
that had drifted to claim 72 was the confirmed/in-use value when the
code already correctly used 88; the mismatch is almost certainly what
the automated reviewer's static analysis flagged, since it has no way
to see the DRQ_SET hardware verification. Rejected the same
atomic-context claims a third time.

v7 -> v8: Fixed a permanent first-frame-loss deadlock:
sun4i_tcon_dsi_retrigger_timer_fn()'s initial software kick was gated
on tick==0 alone, so if TRIGGER_START happened to still read busy at
that exact first tick (e.g. a stale value surviving a DPMS off/on
cycle, since that doesn't re-run sun4i_tcon0_mode_set_cpu() and so
never rewrites CPU_IF_REG to reset it), the kick was skipped and never
attempted again for the rest of that cycle -- permanently losing the
frame. Fixed by tracking "have we kicked yet" (a new
dsi_retrigger_kicked flag) instead of "is this tick==0", so the timer
keeps retrying every 2ms until busy actually clears, then kicks
exactly once. Also corrected a stale comment claiming this driver sets
SUN4I_TCON0_CPU_IF_AUTO to handle Vsync-driven retriggering -- checked
directly, this driver never writes that bit at all.

Fixed a real clock-gate leak: sun4i_tcon0_set_dsi_gate(tcon, true) is
called on every DSI mode-set, but nothing ever called the matching
false to ungate it again on disable, leaving the TCON-TOP DSI clock
gate (and, via CLK_IGNORE_UNUSED, its CLK_MIPI_DSI parent) permanently
on past this TCON's own disable. Fixed by calling
sun4i_tcon0_set_dsi_gate(tcon, false) from sun4i_tcon_set_status()'s
disable path; safe to call unconditionally since the function is
already a no-op on boards without a matching TCON TOP remote node.

Rejected a DT schema claim that two new DE2 mixer compatible strings
(allwinner,sun50i-a133-de2-mixer-0/1) needed their own if/then
conditional block in allwinner,sun8i-a83t-de2-mixer.yaml: verified
with dt-validate that they correctly fall through to the schema's
existing else branch (single reg region), the same as every other
non-h616 compatible already in that enum -- there is no per-SoC
validation to bypass here beyond the one genuine special case
(sun50i-h616-de33-mixer-0's 3-region reg layout), which this board
doesn't share.

 .../display/allwinner,sun4i-a10-tcon.yaml     |   1 +
 .../allwinner,sun8i-a83t-de2-mixer.yaml       |   2 +
 .../display/allwinner,sun8i-r40-tcon-top.yaml |  58 +-
 .../pwm/allwinner,sun50i-a133-pwm.yaml        |  67 ++
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../allwinner/sun50i-a133-trimui-smartpro.dts | 697 +++++++++++++++++
 drivers/clk/sunxi-ng/ccu-sun50i-a100.c        |  16 +-
 drivers/gpu/drm/panel/Kconfig                 |   8 +
 drivers/gpu/drm/panel/Makefile                |   1 +
 .../gpu/drm/panel/panel-orisetech-otm1289a.c  | 435 +++++++++++
 drivers/gpu/drm/sun4i/sun4i_tcon.c            | 727 +++++++++++++++++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h            | 138 ++++
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c        | 227 +++++-
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h        |  23 +
 drivers/gpu/drm/sun4i/sun8i_mixer.c           |  48 ++
 drivers/gpu/drm/sun4i/sun8i_tcon_top.c        | 152 +++-
 drivers/gpu/drm/sun4i/sun8i_tcon_top.h        |   2 +
 drivers/pwm/Kconfig                           |  14 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-sun50i-a133.c                 | 335 ++++++++
 20 files changed, 2904 insertions(+), 49 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/allwinner,sun50i-a133-pwm.yaml
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a133-trimui-smartpro.dts
 create mode 100644 drivers/gpu/drm/panel/panel-orisetech-otm1289a.c
 create mode 100644 drivers/pwm/pwm-sun50i-a133.c

Message ID	20260912233238.110960-1-leow149@lucidmail.xyz (mailing list archive)
State	New
Headers	Return-Path: <linux-sunxi+bounces-25835-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id 065621C02D1 for <noreply@patchwork.local>; Sun, 13 Sep 2026 01:33:04 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=lucidmail.xyz; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-25835-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-25835-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 265A032F7C for <noreply@patchwork.local>; Sat, 12 Sep 2026 23:33:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 89E7E361975; Sat, 12 Sep 2026 23:33:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lucidmail.xyz header.i=@lucidmail.xyz header.b="MHkB17NN" X-Original-To: linux-sunxi@lists.linux.dev Received: from mail.lucidmail.xyz (mail.lucidmail.xyz [78.46.175.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6342145B27 for <linux-sunxi@lists.linux.dev>; Sat, 12 Sep 2026 23:32:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.46.175.68 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789255981; cv=none; b=D+fysKvjoub7n/3uxUHYv2D5D1LaTWTqTlj+BUI8x1nT5Chm7ARZE58J2MxgauBFybKjgYkMLZ2jCv3Lb1fhbJtm8axWT8u9NVj3ezOCSzSqkpVBkS/vkUJ+RXV6MtDzj5oXdAMxdYvkGU7xKV1kxhcVFcWVFypuSskSL1olQkg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789255981; c=relaxed/simple; bh=W9kPdXlUiEOMyDM277Av2G1Fb7Y5dzNLUrwninGO6TY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o/m0wCXXRyditFY7878fAAienYevfNABNLi1TxHplQHD22Xy6p2HZmfkqDoqYiQfIEEKRv0+EOExMDnazX08l6W8FHsiWzn16yB9V6O0+suzx8Sdh0utlAmsTcMc0ymbRShLXv2RO11PFh91qnhDYGwGFFenIjp4zyVUeL3oCVo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lucidmail.xyz; spf=pass smtp.mailfrom=lucidmail.xyz; dkim=pass (2048-bit key) header.d=lucidmail.xyz header.i=@lucidmail.xyz header.b=MHkB17NN; arc=none smtp.client-ip=78.46.175.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=lucidmail.xyz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lucidmail.xyz Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id CA1B9177C7A; Sun, 13 Sep 2026 01:32:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidmail.xyz; s=dkim; t=1789255971; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=sH8BhKtaUa9VS/FHV6lxG5eXef3pjIn0knHBVYFlNmA=; b=MHkB17NNCXzRv08YfCWd9x8hc80K6ziB1XKe6DHoODKMndrTxRFUEI9xbr8AlD4XdQjlhc Tw2YiU98pE0nLOIFo/zRv6XiibPPxjMplvVHF5z+aHr3n1PnqzDQ0PIqiFAK5NMIQurPTc e3t1K3bGKdc2UAXg1nb4EKy+Ulo5zFlJ1Ctr+KILd0F8s+R/QFX1m0yW4KDeEsTtVSuRhe 5FTFujGxzSDIauMZH8JFyctAAqyQ1kFNPEUIXl5zzWZNGa9G6ZmkASP2SOk8OCub66/d2L 2I3k47Y7Rzvr+tFWQ9Eos/IVhvYWEXjr89AzeHmEFrnI6Di/AfFYGzxE0U8xFA== From: leow149 <leow149@lucidmail.xyz> To: dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev Cc: wens@kernel.org, jernej.skrabec@gmail.com, samuel@sholland.org, mripard@kernel.org, paulk@sys-base.io, leow149 <leow149@lucidmail.xyz> Subject: [RFC PATCH v8] arm64: allwinner: add TrimUI Smart Pro (A133) board support Date: Sun, 13 Sep 2026 01:32:36 +0200 Message-ID: <20260912233238.110960-1-leow149@lucidmail.xyz> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260912230131.109229-1-leow149@lucidmail.xyz> References: <20260912230131.109229-1-leow149@lucidmail.xyz> Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Last-TLS-Session-Version: TLSv1.3 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
Series	[RFC,v8] arm64: allwinner: add TrimUI Smart Pro (A133) board support \| [RFC,v8] arm64: allwinner: add TrimUI Smart Pro (A133) board support

[RFC,v8] arm64: allwinner: add TrimUI Smart Pro (A133) board support

Commit Message

Comments

Patch