Skip to content

WIP: Implement DCP 14.7 ABI - #562

Draft
chadmed wants to merge 48 commits into
AsahiLinux:asahi-wipfrom
chadmed:dcp/14.8.3
Draft

WIP: Implement DCP 14.7 ABI#562
chadmed wants to merge 48 commits into
AsahiLinux:asahi-wipfrom
chadmed:dcp/14.8.3

Conversation

@chadmed

@chadmed chadmed commented Aug 2, 2026

Copy link
Copy Markdown
Member

Depends on #520

Implements the macOS 14.7 EPIC IPC interface for DCP and drops 12.x (partially, WIP). Required for M3 series (excluding Ultra).

Draft until below is addressed

TODO:

  • Start RTKit
  • Start IOMFB
  • Modesetting
  • Single IOSurface
  • Multiple IOSurfaces
  • ARGB8888
  • ARGB2101010
  • Semiplanar Y'UV
  • Premultiplied alpha on surface 0
  • Clear empty/null surfaces (!! currently DCP still tries to read the destroyed framebuffer causing IOVA faults)
  • Backlight on laptops
  • Set colour transformation matrix
  • Get ColorElements and TimingElements
  • Start dcpext
  • Start AVService/s (looks like it initialises properly but never does anything)
  • Handle hotplug
  • Enumerate modes
  • Modeset external display
  • Output on external display
  • HDMI audio (AVService commands don't look like they've changed but service never responds)
  • Get EDID (as above)

WhatAmISupposedToPutHere and others added 30 commits June 21, 2026 10:10
The SMC firmware included in macOS 27 changed the size of BCF0 key from
4 to 1 bytes. This key is used for indicating that battery state is
critically low.

Reviewed-by: Sven Peter <sven@kernel.org>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.

Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
The current approach of silently disabling all rust drivers if the
toolchain is missing results in users that try to compile their own
kernels getting a "successful" build and then being confused about where
did their drivers go. In comparison, missing openssl results in a build
failure, not a disappearance of everything that depends on it.

This also means that allyesconfig will depend on rust, but since the
rust experiment concluded with "rust is here to stay", i believe that
allyesconfig should be building rust drivers too.

Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition
to 'gP00' keys. Add a second compatible to handle this keys with an
additional macsmc-gpio instance.

Signed-off-by: Janne Grunau <j@jannau.net>
Add support for SMC GPIO keys with a lower letter 'p' via the
"apple,smc-low-gpio" compatible. This adds support for a second
macsmc-gpio controller using 'gp00' keys.
These keys are used on Apple M3 Pro and Max MacBooks in the controller
for keyboard and trackpad and for the built-in DisplayPort to HDMI
converter.

Signed-off-by: Janne Grunau <j@jannau.net>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition
to 'gP00' keys. These keys are handled by an additional macsmc-gpio
instance using the "apple,smc-low-gpio" compatible.

Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: sofus <sofus.c@icloud.com>
Since immediate mode was enabled, unmapping a GPU VA can defer
drm_gpuvm_bo destruction until drm_gpuvm_bo_deferred_cleanup() is called.
The GEM bind and unbind paths drain that list, but Vm::drop() unmaps the
remaining user ranges without doing so.

Drain the deferred list after both teardown unmaps. Otherwise a deferred
drm_gpuvm_bo retains the imported GEM and dma-buf after its DRM file is
closed, leaving its backing pages pinned.

Fixes: 2aeee2d ("drm/asahi: Switch gpuvm to DRM_GPUVM_IMMEDIATE_MODE")
Signed-off-by: DesktopECHO <33142753+DesktopECHO@users.noreply.github.com>
jannau and others added 18 commits July 25, 2026 20:28
Add CONFIG_VIDEO_APPLE_AVD for AVD (Apple video decoder) support.

Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: sofus <sofus.c@icloud.com>
This is a hardcoded charge threshold feature present in firmware 13.0 or
newer. Userspace settings are rounded to one of the two possible
behaviors.

Since macOS Sequoia firmware, CHLS replaced CHWA and now allows an
arbitrary end charge threshold to be configured.

Prefer CHWA over CHLS since the SMC firmware from iBoot-10151.1.1
(macOS 14.0) is not compatible with our CHGLS usage. It was working
with the SMC firmware from iBoot-10151.121.1 (macOS 14.5).

Signed-off-by: Janne Grunau <j@jannau.net>
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Janne Grunau <j@jannau.net>
DCP is an interesting little bit of hardware. Each variant has quite
different scanout capabilities, including which hardware planes are
actually present. The firmware interface will always accept four
IOSurface structs, however the hardware will fail in weird and
wonderful ways if the firmware then tries to program the corresponding
scanout planes when they do not actually work. We need a way to
declare to KMS which hardware planes actually work on which SoCs.

Add an array to the Devicetree node representing the working hardware
surfaces (relative to the four possible IOSurfaces), and use this to
decide which KMS planes get created at driver init. Since we now
guarantee that every instantiated DRM plane corresponds to a valid
hardware surface, we can remove some superfluous sanity checks in
crtc_atomic_check too.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
All T602x DCPs support simultaneous scanout on surfaces 0, 1, and 3.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
All T600x DCPs support simultaneous scanout on surfaces 0 and 1.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
All T8103 DCPs support simultaneous scanout on surfaces 0 and 1.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
All T8112 DCPs support simultaneous scanout on surfaces 0, 1, and 3.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Now that we can safely declare the working hardware surfaces on
each SoC, let the driver test all possible positions for a working
surface.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
This firmware version was only ever used for extremely early alpha
installs based on ALARM (so basically just for developers testing things).
Remove support for it to make way for a new target ABI for M3 machines.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
WIP

This currently breaks with overlays and on machines that do not
use surface 0 by default. I am also not 100% sure about some of
the new fields and offsets. There seems to be some data at the
bottom of the blob that gets sent to swap_submit, but it's all
garbage. Also not sure why overlay surfaces now crash DCP.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Because we have not yet figured out how to clear surfaces, freeing old
framebuffer references crashes DCP with IOVA errors. Don't destroy them
for now so that we can continue working.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Some of this is 0xaa padding, some of it is zeroes, and
there is a conspicuous empty byte at the end.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
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.

6 participants