Uh oh!
There was an error while loading. Please reload this page.
dcp: Corrent scanout surface handling on all SoCs - #520
Closed
chadmed wants to merge 35 commits into
Closed
Conversation
chadmedforce-pushed
the
dcp/surface-caps
branch
3 times, most recently
from
August 1, 2026 01:38
ed710d3 to
13db32dCompareThe 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. In addition, B0RM key has changed endianness. Reviewed-by: Sven Peter <sven@kernel.org> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Reviewed-by: Janne Grunau <j@jannau.net> Cc: stable@vger.kernel.org Fixes: 0ebf821 ("power: supply: Add macsmc-power driver for Apple Silicon") Signed-off-by: Sasha Finkelstein <k@chaosmail.tech> Link: https://patch.msgid.link/20260712-gate-power-v4-1-aa59c6583247@chaosmail.tech Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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>
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. 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>
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>
jannau
commented
Aug 11, 2026
Member
manually merged with rework by me (mostly diff minimasation) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Take two of a mechanism by which each DCP can safely expose all of its scanout surfaces for compositors/clients to do with as they please.
Tested on t6000, t6021, t8112, t8103.