Skip to content

serial: apple-dockchannel: never wait for a reader with apple,tx-never-wait - #889

Closed
funkzy wants to merge 2 commits into
aurora-silicon:t6050/basefrom
funkzy:pr/t6050-dockchannel-console
Closed

funkzy wants to merge 2 commits into
aurora-silicon:t6050/basefrom
funkzy:pr/t6050-dockchannel-console

Conversation

@funkzy

@funkzy funkzy commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Summary

The DockChannel console drains only while a debug USB host reads the channel. On a Mac Studio M5 Ultra (J775D)
that boots unattended with nothing attached, the TX FIFO stays full. Each console character then spun up to 10000
reads of TX_FREE, every close waited for output that could never drain, and boot stalled. With the new property
apple,tx-never-wait, output that doesn't fit is dropped instead.

What it changes

  • With the property, console writes (the driver's and the early console's) send what TX_FREE says fits and drop
    the rest. tty output is sent from the drain timer and dropped after two ticks without room. A close does not
    wait, and tx_empty reports empty.
  • Without the property, every other DockChannel Mac behaves as before.

Testing (J775D)

  • With the property set and nothing reading, J775D boots unattended to its login (every boot since 2026-10-30).
    With a reader attached, the console carries the whole boot log.
  • On this base: builds with no warnings.
  • Booted on these bases (2026-11-02): one tree of t6050/base with nvme: apple: Add resident T6050 ANS over APIF #473 and PCI: apple: Add T6050 APIF hosts and native AIC MSI #474 plus the DockChannel, PCIe and
    NVMe PRs, and the J775D board DT with apple,tx-never-wait. Cold boot and warm reboot in both directions: from
    another kernel into this one, ALARM came up on its NVMe root; out of it, a systemctl reboot took 38 s with a 2 s
    stop phase and no stop timeouts. With nothing reading the console, 20 lines to /dev/console took 3 ms. 64 KiB to /dev/ttyDC0 took 140 ms and 20 KERN_ERR lines 5 ms.
    Without the property, the same tree spent about a second per console line once the channel filled, and a reboot
    out of it hung until the watchdog reset the machine.
  • checkpatch: clean.

Not tested

  • Other DockChannel Macs with the property set (none need it).

Dependencies

None beyond t6050/base. A board whose console is on DockChannel and may boot with nothing reading it should set
the property; the J775D board DT will.

Assisted-by: LLM

funkzy and others added 2 commits November 2, 2026 02:26
A DockChannel UART drains only while a debug USB host reads it. On a
board that boots unattended with nothing attached, its TX FIFO stays
full. apple,tx-never-wait tells the driver not to wait for room.

Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r-wait

The DockChannel console drains only while a debug USB host reads the
channel. With none attached, as on an M5 Ultra Mac Studio (J775D) that
boots unattended, the TX FIFO stays full: the write loops spun up to
10000 reads of TX_FREE per character and every close waited for output
that could not drain, so boot and every console write stalled.

With apple,tx-never-wait, console writes (the driver's and the early
console's) send what TX_FREE says fits and drop the rest, tty output is
sent from the drain timer and dropped after two ticks without room, a
close does not wait, and tx_empty reports empty. Without the property,
every other DockChannel Mac's driver and early console behave as
before.

Testing: J775D boots unattended to its login with nothing reading the
channel (the property set), and with a reader attached the console
carries the whole boot log.

Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@funkzy

funkzy commented Nov 3, 2026

Copy link
Copy Markdown
Contributor Author

Closing: this change now lives in the funkzy/j775d branch of aurora-silicon/linux-aurora (the J775D series as built and booted, 681521644671), which dj merges directly; no PR flow for it any more.

@funkzy funkzy closed this Nov 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant