This includes
- GXF
- SPRR
- PAN (A7-A9)
- Atomics (A7-A10)
- FIPI (A7-A10)
- DCP
SPRR on T8030 seems to be quite different from M1 (at least according to
qemu-t8030), so keep it disabled for those CPU parts.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
It seems this model does not need it *and* it somehow causes
nondeterministic problems.
Also add a delay to the poweroff/on sequence to be more conservative.
Fixes: #406
Signed-off-by: Hector Martin <marcan@marcan.st>
dcpext0 behaves like dcp on M1* devices and can sleep after display
init. This has the advantage of not breaking macOS when starting with an
initialized display.
dcpext* are according to Apple's tech specs slightly more powerful than
dcp. They are advertised as 6K at 60Hz while dcp seems to be limited to
5K at 60Hz.
Signed-off-by: Janne Grunau <j@jannau.net>
Required for stage 1 loader to allow chainloaded display/dcp experiments
to start with the state left by iboot.
Signed-off-by: Janne Grunau <j@jannau.net>
Power up display early (fixes HPD sometimes) and delay at least one
frame after swapping before quiescing DCP, otherwise the swap somehow
doesn't complete.
Signed-off-by: Hector Martin <marcan@marcan.st>
stage1 ends up with an ugly Asahi 100% logo on top of a 200% Apple logo.
Let's just clear it so it looks nicer.
Signed-off-by: Hector Martin <marcan@marcan.st>
This works around issues switching to 120Hz mode on systems affected by
the Sonoma situation, and in general it's probably a good idea anyway.
Signed-off-by: Hector Martin <marcan@marcan.st>
It appears that when macOS is set to non-ProMotion mode, DCP firmware
<14.0 booted from DCP firmware 14.0+ needs a delay before modesetting to
complete the modeset properly.
The cases here are:
- Older m1n1 stage1 will, as far as it's concerned, initialize the
display properly, but it won't work. It also misses the retina flag,
since this codepath was intended for external displays. Use the
missing retina flag as a signal to trigger reconfig.
- If installed as stage1, we reconfigure the display as usual, now with
the extra delay. We also set the Retina flag now.
The persistence mechanism for the ProMotion flag is unknown. It doesn't
seem to be nvram. It also doesn't matter if we successfully modeset to
120Hz mode and then reboot, it breaks again, so it's not about the
"current" mode sticking.
Signed-off-by: Hector Martin <marcan@marcan.st>
On M2* desktop systems the HDMI output is not managed by dcp/dcp0. This
allows more flexibility, for example dcp on the M2 Mac mini can be
routed to the USB-C/ThunderBolt ports.
For m1n1 this adds quite ab bit of complexity. In addition to the DCP
iboot endpoint/protocol two additional endpoints have to be started.
Only the dptx-port endpoint has a meaningful AP <=> DCP communication.
In addition we start the system endpoint to optionally enable more
verbose syslog messages (if RTKIT_SYSLOG is defined).
In addition the dptx-phy or lpdptx-phy has to be programmed. Those two
phy look mostly identical. MacOS seems to use a static DP configuration
(4 lanes, HBR3*) regardless of the connected display.
The added SMC gpio support is used to power the MCDP29xx DP to HDMI
converter on.
Config is unfortunately a mess since Apple can't name the device tree
nodes consistently. On M2 Ultra devices only the four dcpext*/dispext*
on each die are used. M2 Ultra support is untested.
* link rate might differ on t602x based devices for 8k60 support
Signed-off-by: Janne Grunau <j@jannau.net>
Fixes a copy and paste error in 1b5dee2496 checking dart-dcp twice.
Fixes: 1b5dee2496 ("display: Map the framebuffer if it is not mapped")
Signed-off-by: Janne Grunau <j@jannau.net>
0 is a valid and used device virtual address. Daart functions returning
device address can not use 0 to indicate errors.
Signed-off-by: Janne Grunau <j@jannau.net>
This stops DCP from killing our modeset if the connection cycles.
Also force a (potential) configure cycle if the display is external;
this makes sure updated stage2s will have a chance at fixing issues of
old stage1s. Modesetting is fast when it's the same mode as before.
Signed-off-by: Hector Martin <marcan@marcan.st>
If an explicitly specified display mode exceeds the allocated
framebuffer allocate a new one from the top of RAM.
Note: macOS panics immediately with a realloced framebuffer.
Signed-off-by: Janne Grunau <j@jannau.net>
The reserved framebuffer on the Mac Studio is 0x854000 bytes. This is
too small for 1920x1200 with 4 byte per pixel. Setting 1920x1200 as
mode crashes dcp but not the actual display controller. The display
remains working and even comes back after display hotplug/power cycle.
Signed-off-by: Janne Grunau <j@jannau.net>
