2020-10-09 22:11:24 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
#
|
|
|
|
|
# Microsoft Surface Platform-Specific Drivers
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
menuconfig SURFACE_PLATFORMS
|
|
|
|
|
bool "Microsoft Surface Platform-Specific Device Drivers"
|
2022-01-15 22:08:49 +08:00
|
|
|
depends on ARM64 || X86 || COMPILE_TEST
|
2020-10-09 22:11:24 +08:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Say Y here to get to see options for platform-specific device drivers
|
|
|
|
|
for Microsoft Surface devices. This option alone does not add any
|
|
|
|
|
kernel code.
|
|
|
|
|
|
|
|
|
|
If you say N, all options in this submenu will be skipped and disabled.
|
2020-10-09 22:11:25 +08:00
|
|
|
|
|
|
|
|
if SURFACE_PLATFORMS
|
|
|
|
|
|
|
|
|
|
config SURFACE3_WMI
|
|
|
|
|
tristate "Surface 3 WMI Driver"
|
|
|
|
|
depends on ACPI_WMI
|
|
|
|
|
depends on DMI
|
|
|
|
|
depends on INPUT
|
|
|
|
|
depends on SPI
|
|
|
|
|
help
|
|
|
|
|
Say Y here if you have a Surface 3.
|
|
|
|
|
|
|
|
|
|
To compile this driver as a module, choose M here: the module will
|
|
|
|
|
be called surface3-wmi.
|
|
|
|
|
|
2020-10-09 22:11:27 +08:00
|
|
|
config SURFACE_3_POWER_OPREGION
|
|
|
|
|
tristate "Surface 3 battery platform operation region support"
|
2021-12-03 03:16:27 +08:00
|
|
|
depends on ACPI
|
2020-12-16 21:37:52 +08:00
|
|
|
depends on I2C
|
2020-10-09 22:11:27 +08:00
|
|
|
help
|
|
|
|
|
This driver provides support for ACPI operation
|
|
|
|
|
region of the Surface 3 battery platform driver.
|
|
|
|
|
|
platform/surface: Add Surface ACPI Notify driver
The Surface ACPI Notify (SAN) device provides an ACPI interface to the
Surface Aggregator EC, specifically the Surface Serial Hub interface.
This interface allows EC requests to be made from ACPI code and can
convert a subset of EC events back to ACPI notifications.
Specifically, this interface provides a GenericSerialBus operation
region ACPI code can execute a request by writing the request command
data and payload to this operation region and reading back the
corresponding response via a write-then-read operation. Furthermore,
this interface provides a _DSM method to be called when certain events
from the EC have been received, essentially turning them into ACPI
notifications.
The driver provided in this commit essentially takes care of translating
the request data written to the operation region, executing the request,
waiting for it to finish, and finally writing and translating back the
response (if the request has one). Furthermore, this driver takes care
of enabling the events handled via ACPI _DSM calls. Lastly, this driver
also exposes an interface providing discrete GPU (dGPU) power-on
notifications on the Surface Book 2, which are also received via the
operation region interface (but not handled by the SAN driver directly),
making them accessible to other drivers (such as a dGPU hot-plug driver
that may be added later on).
On 5th and 6th generation Surface devices (Surface Pro 5/2017, Pro 6,
Book 2, Laptop 1 and 2), the SAN interface provides full battery and
thermal subsystem access, as well as other EC based functionality. On
those models, battery and thermal sensor devices are implemented as
standard ACPI devices of that type, however, forward ACPI calls to the
corresponding Surface Aggregator EC request via the SAN interface and
receive corresponding notifications (e.g. battery information change)
from it. This interface is therefore required to provide said
functionality on those devices.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20201221183959.1186143-10-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-12-22 02:39:59 +08:00
|
|
|
config SURFACE_ACPI_NOTIFY
|
|
|
|
|
tristate "Surface ACPI Notify Driver"
|
|
|
|
|
depends on SURFACE_AGGREGATOR
|
|
|
|
|
help
|
|
|
|
|
Surface ACPI Notify (SAN) driver for Microsoft Surface devices.
|
|
|
|
|
|
|
|
|
|
This driver provides support for the ACPI interface (called SAN) of
|
|
|
|
|
the Surface System Aggregator Module (SSAM) EC. This interface is used
|
|
|
|
|
on 5th- and 6th-generation Microsoft Surface devices (including
|
|
|
|
|
Surface Pro 5 and 6, Surface Book 2, Surface Laptops 1 and 2, and in
|
|
|
|
|
reduced functionality on the Surface Laptop 3) to execute SSAM
|
|
|
|
|
requests directly from ACPI code, as well as receive SSAM events and
|
|
|
|
|
turn them into ACPI notifications. It essentially acts as a
|
|
|
|
|
translation layer between the SSAM controller and ACPI.
|
|
|
|
|
|
|
|
|
|
Specifically, this driver may be needed for battery status reporting,
|
|
|
|
|
thermal sensor access, and real-time clock information, depending on
|
|
|
|
|
the Surface device in question.
|
|
|
|
|
|
2020-12-22 02:39:58 +08:00
|
|
|
config SURFACE_AGGREGATOR_CDEV
|
|
|
|
|
tristate "Surface System Aggregator Module User-Space Interface"
|
|
|
|
|
depends on SURFACE_AGGREGATOR
|
|
|
|
|
help
|
|
|
|
|
Provides a misc-device interface to the Surface System Aggregator
|
|
|
|
|
Module (SSAM) controller.
|
|
|
|
|
|
|
|
|
|
This option provides a module (called surface_aggregator_cdev), that,
|
|
|
|
|
when loaded, will add a client device (and its respective driver) to
|
|
|
|
|
the SSAM controller. Said client device manages a misc-device
|
|
|
|
|
interface (/dev/surface/aggregator), which can be used by user-space
|
|
|
|
|
tools to directly communicate with the SSAM EC by sending requests and
|
|
|
|
|
receiving the corresponding responses.
|
|
|
|
|
|
|
|
|
|
The provided interface is intended for debugging and development only,
|
|
|
|
|
and should not be used otherwise.
|
|
|
|
|
|
platform/surface: Set up Surface Aggregator device registry
The Surface System Aggregator Module (SSAM) subsystem provides various
functionalities, which are separated by spreading them across multiple
devices and corresponding drivers. Parts of that functionality / some of
those devices, however, can (as far as we currently know) not be
auto-detected by conventional means. While older (specifically 5th- and
6th-)generation models do advertise most of their functionality via
standard platform devices in ACPI, newer generations do not.
As we are currently also not aware of any feasible way to query said
functionalities dynamically, this poses a problem. There is, however, a
device in ACPI that seems to be used by Windows for identifying
different Surface models: The Windows Surface Integration Device (WSID).
This device seems to have a HID corresponding to the overall set of
functionalities SSAM provides for the associated model.
This commit introduces a registry providing non-detectable device
information via software nodes. In addition, a SSAM platform hub driver
is introduced, which takes care of creating and managing the SSAM
devices specified in this registry. This approach allows for a
hierarchical setup akin to ACPI and is easily extendable, e.g. via
firmware node properties.
Note that this commit only provides the basis for the platform hub and
registry, and does not add any content to it. The registry will be
expanded in subsequent commits.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210212115439.1525216-2-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-02-12 19:54:34 +08:00
|
|
|
config SURFACE_AGGREGATOR_REGISTRY
|
|
|
|
|
tristate "Surface System Aggregator Module Device Registry"
|
|
|
|
|
depends on SURFACE_AGGREGATOR
|
|
|
|
|
depends on SURFACE_AGGREGATOR_BUS
|
|
|
|
|
help
|
|
|
|
|
Device-registry and device-hubs for Surface System Aggregator Module
|
|
|
|
|
(SSAM) devices.
|
|
|
|
|
|
|
|
|
|
Provides a module and driver which act as a device-registry for SSAM
|
|
|
|
|
client devices that cannot be detected automatically, e.g. via ACPI.
|
|
|
|
|
Such devices are instead provided via this registry and attached via
|
|
|
|
|
device hubs, also provided in this module.
|
|
|
|
|
|
|
|
|
|
Devices provided via this registry are:
|
|
|
|
|
- Platform profile (performance-/cooling-mode) device (5th- and later
|
|
|
|
|
generations).
|
|
|
|
|
- Battery/AC devices (7th-generation).
|
|
|
|
|
- HID input devices (7th-generation).
|
|
|
|
|
|
|
|
|
|
Select M (recommended) or Y here if you want support for the above
|
|
|
|
|
mentioned devices on the corresponding Surface models. Without this
|
|
|
|
|
module, the respective devices will not be instantiated and thus any
|
|
|
|
|
functionality provided by them will be missing, even when drivers for
|
|
|
|
|
these devices are present. In other words, this module only provides
|
|
|
|
|
the respective client devices. Drivers for these devices still need to
|
|
|
|
|
be selected via the other options.
|
|
|
|
|
|
platform/surface: Add DTX driver
The Microsoft Surface Book series devices consist of a so-called
clipboard part (containing the CPU, touchscreen, and primary battery)
and a base part (containing keyboard, secondary battery, and optional
discrete GPU). These parts can be separated, i.e. the clipboard can be
detached and used as tablet.
This detachment process is initiated by pressing a button. On the
Surface Book 2 and 3 (targeted with this commit), the Surface Aggregator
Module (i.e. the embedded controller on those devices) attempts to send
a notification to any listening client driver and waits for further
instructions (i.e. whether the detachment process should continue or be
aborted). If it does not receive a response in a certain time-frame, the
detachment process (by default) continues and the clipboard can be
physically separated. In other words, (by default and) without a driver,
the detachment process takes about 10 seconds to complete.
This commit introduces a driver for this detachment system (called DTX).
This driver allows a user-space daemon to control and influence the
detachment behavior. Specifically, it forwards any detachment requests
to user-space, allows user-space to make such requests itself, and
allows handling of those requests. Requests can be handled by either
aborting, continuing/allowing, or delaying (i.e. resetting the timeout
via a heartbeat commend). The user-space API is implemented via the
/dev/surface/dtx miscdevice.
In addition, user-space can change the default behavior on timeout from
allowing detachment to disallowing it, which is useful if the (optional)
discrete GPU is in use.
Furthermore, this driver allows user-space to receive notifications
about the state of the base, specifically when it is physically removed
(as opposed to detachment requested), in what manner it is connected
(i.e. in reverse-/tent-/studio- or laptop-mode), and what type of base
is connected. Based on this information, the driver also provides a
simple tablet-mode switch (aliasing all modes without keyboard access,
i.e. tablet-mode and studio-mode to its reported tablet-mode).
An implementation of such a user-space daemon, allowing configuration of
detachment behavior via scripts (e.g. safely unmounting USB devices
connected to the base before continuing) can be found at [1].
[1]: https://github.com/linux-surface/surface-dtx-daemon
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210308184819.437438-2-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-09 02:48:17 +08:00
|
|
|
config SURFACE_DTX
|
|
|
|
|
tristate "Surface DTX (Detachment System) Driver"
|
|
|
|
|
depends on SURFACE_AGGREGATOR
|
|
|
|
|
depends on INPUT
|
|
|
|
|
help
|
|
|
|
|
Driver for the Surface Book clipboard detachment system (DTX).
|
|
|
|
|
|
|
|
|
|
On the Surface Book series devices, the display part containing the
|
|
|
|
|
CPU (called the clipboard) can be detached from the base (containing a
|
|
|
|
|
battery, the keyboard, and, optionally, a discrete GPU) by (if
|
|
|
|
|
necessary) unlocking and opening the latch connecting both parts.
|
|
|
|
|
|
|
|
|
|
This driver provides a user-space interface that can influence the
|
|
|
|
|
behavior of this process, which includes the option to abort it in
|
|
|
|
|
case the base is still in use or speed it up in case it is not.
|
|
|
|
|
|
2021-03-09 02:48:18 +08:00
|
|
|
Note that this module can be built without support for the Surface
|
|
|
|
|
Aggregator Bus (i.e. CONFIG_SURFACE_AGGREGATOR_BUS=n). In that case,
|
|
|
|
|
some devices, specifically the Surface Book 3, will not be supported.
|
|
|
|
|
|
platform/surface: Add Driver to set up lid GPEs on MS Surface device
Conventionally, wake-up events for a specific device, in our case the
lid device, are managed via the ACPI _PRW field. While this does not
seem strictly necessary based on ACPI spec, the kernel disables GPE
wakeups to avoid non-wakeup interrupts preventing suspend by default and
only enables GPEs associated via the _PRW field with a wake-up capable
device. This behavior has been introduced in commit f941d3e41da7 ("ACPI:
EC / PM: Disable non-wakeup GPEs for suspend-to-idle") and is described
in more detail in its commit message.
Unfortunately, on MS Surface devices, there is no _PRW field present on
the lid device, thus no GPE is associated with it, and therefore the GPE
responsible for sending the status-change notification to the lid gets
disabled during suspend, making it impossible to wake the device via the
lid.
This patch introduces a pseudo-device and respective driver which, based
on some DMI matching, marks the corresponding GPE of the lid device for
wake and enables it during suspend. The behavior of this driver models
the behavior of the ACPI/PM core for normal wakeup GPEs, properly
declared via the _PRW field.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20201028105427.1593764-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-28 18:54:27 +08:00
|
|
|
config SURFACE_GPE
|
|
|
|
|
tristate "Surface GPE/Lid Support Driver"
|
2021-12-03 03:16:27 +08:00
|
|
|
depends on ACPI
|
platform/surface: Add Driver to set up lid GPEs on MS Surface device
Conventionally, wake-up events for a specific device, in our case the
lid device, are managed via the ACPI _PRW field. While this does not
seem strictly necessary based on ACPI spec, the kernel disables GPE
wakeups to avoid non-wakeup interrupts preventing suspend by default and
only enables GPEs associated via the _PRW field with a wake-up capable
device. This behavior has been introduced in commit f941d3e41da7 ("ACPI:
EC / PM: Disable non-wakeup GPEs for suspend-to-idle") and is described
in more detail in its commit message.
Unfortunately, on MS Surface devices, there is no _PRW field present on
the lid device, thus no GPE is associated with it, and therefore the GPE
responsible for sending the status-change notification to the lid gets
disabled during suspend, making it impossible to wake the device via the
lid.
This patch introduces a pseudo-device and respective driver which, based
on some DMI matching, marks the corresponding GPE of the lid device for
wake and enables it during suspend. The behavior of this driver models
the behavior of the ACPI/PM core for normal wakeup GPEs, properly
declared via the _PRW field.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20201028105427.1593764-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-10-28 18:54:27 +08:00
|
|
|
depends on DMI
|
|
|
|
|
help
|
|
|
|
|
This driver marks the GPEs related to the ACPI lid device found on
|
|
|
|
|
Microsoft Surface devices as wakeup sources and prepares them
|
|
|
|
|
accordingly. It is required on those devices to allow wake-ups from
|
|
|
|
|
suspend by opening the lid.
|
|
|
|
|
|
platform/surface: Add Surface Hot-Plug driver
Some Surface Book 2 and 3 models have a discrete GPU (dGPU) that is
hot-pluggable. On those devices, the dGPU is contained in the base,
which can be separated from the tablet part (containing CPU and
touchscreen) while the device is running.
It (in general) is presented as/behaves like a standard PCIe hot-plug
capable device, however, this device can also be put into D3cold. In
D3cold, the device itself is turned off and can thus not submit any
standard PCIe hot-plug events. To properly detect hot-(un)plugging while
the dGPU is in D3cold, out-of-band signaling is required. Without this,
the device state will only get updated during the next bus-check, eg.
via a manually issued lspci call.
This commit adds a driver to handle out-of-band PCIe hot-(un)plug events
on Microsoft Surface devices. On those devices, said events can be
detected via GPIO interrupts, which are then forwarded to the
corresponding ACPI DSM calls by this driver. The DSM then takes care of
issuing the appropriate bus-/device-check, causing the PCI core to
properly pick up the device change.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210205012657.1951753-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-02-05 09:26:57 +08:00
|
|
|
config SURFACE_HOTPLUG
|
|
|
|
|
tristate "Surface Hot-Plug Driver"
|
2021-12-03 03:16:27 +08:00
|
|
|
depends on ACPI
|
platform/surface: Add Surface Hot-Plug driver
Some Surface Book 2 and 3 models have a discrete GPU (dGPU) that is
hot-pluggable. On those devices, the dGPU is contained in the base,
which can be separated from the tablet part (containing CPU and
touchscreen) while the device is running.
It (in general) is presented as/behaves like a standard PCIe hot-plug
capable device, however, this device can also be put into D3cold. In
D3cold, the device itself is turned off and can thus not submit any
standard PCIe hot-plug events. To properly detect hot-(un)plugging while
the dGPU is in D3cold, out-of-band signaling is required. Without this,
the device state will only get updated during the next bus-check, eg.
via a manually issued lspci call.
This commit adds a driver to handle out-of-band PCIe hot-(un)plug events
on Microsoft Surface devices. On those devices, said events can be
detected via GPIO interrupts, which are then forwarded to the
corresponding ACPI DSM calls by this driver. The DSM then takes care of
issuing the appropriate bus-/device-check, causing the PCI core to
properly pick up the device change.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210205012657.1951753-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-02-05 09:26:57 +08:00
|
|
|
depends on GPIOLIB
|
|
|
|
|
help
|
|
|
|
|
Driver for out-of-band hot-plug event signaling on Microsoft Surface
|
|
|
|
|
devices with hot-pluggable PCIe cards.
|
|
|
|
|
|
|
|
|
|
This driver is used on Surface Book (2 and 3) devices with a
|
|
|
|
|
hot-pluggable discrete GPU (dGPU). When not in use, the dGPU on those
|
|
|
|
|
devices can enter D3cold, which prevents in-band (standard) PCIe
|
|
|
|
|
hot-plug signaling. Thus, without this driver, detaching the base
|
|
|
|
|
containing the dGPU will not correctly update the state of the
|
|
|
|
|
corresponding PCIe device if it is in D3cold. This driver adds support
|
|
|
|
|
for out-of-band hot-plug notifications, ensuring that the device state
|
|
|
|
|
is properly updated even when the device in question is in D3cold.
|
|
|
|
|
|
|
|
|
|
Select M or Y here, if you want to (fully) support hot-plugging of
|
|
|
|
|
dGPU devices on the Surface Book 2 and/or 3 during D3cold.
|
|
|
|
|
|
2021-02-12 04:17:03 +08:00
|
|
|
config SURFACE_PLATFORM_PROFILE
|
|
|
|
|
tristate "Surface Platform Profile Driver"
|
2021-12-03 03:16:27 +08:00
|
|
|
depends on ACPI
|
2021-02-12 04:17:03 +08:00
|
|
|
depends on SURFACE_AGGREGATOR_REGISTRY
|
|
|
|
|
select ACPI_PLATFORM_PROFILE
|
|
|
|
|
help
|
|
|
|
|
Provides support for the ACPI platform profile on 5th- and later
|
|
|
|
|
generation Microsoft Surface devices.
|
|
|
|
|
|
|
|
|
|
More specifically, this driver provides ACPI platform profile support
|
|
|
|
|
on Microsoft Surface devices with a Surface System Aggregator Module
|
|
|
|
|
(SSAM) connected via the Surface Serial Hub (SSH / SAM-over-SSH). In
|
|
|
|
|
other words, this driver provides platform profile support on the
|
|
|
|
|
Surface Pro 5, Surface Book 2, Surface Laptop, Surface Laptop Go and
|
|
|
|
|
later. On those devices, the platform profile can significantly
|
|
|
|
|
influence cooling behavior, e.g. setting it to 'quiet' (default) or
|
|
|
|
|
'low-power' can significantly limit performance of the discrete GPU on
|
|
|
|
|
Surface Books, while in turn leading to lower power consumption and/or
|
|
|
|
|
less fan noise.
|
|
|
|
|
|
|
|
|
|
Select M or Y here, if you want to include ACPI platform profile
|
|
|
|
|
support on the above mentioned devices.
|
|
|
|
|
|
2020-10-09 22:11:28 +08:00
|
|
|
config SURFACE_PRO3_BUTTON
|
|
|
|
|
tristate "Power/home/volume buttons driver for Microsoft Surface Pro 3/4 tablet"
|
2021-12-03 03:16:27 +08:00
|
|
|
depends on ACPI
|
2020-12-16 21:37:52 +08:00
|
|
|
depends on INPUT
|
2020-10-09 22:11:28 +08:00
|
|
|
help
|
|
|
|
|
This driver handles the power/home/volume buttons on the Microsoft Surface Pro 3/4 tablet.
|
|
|
|
|
|
platform/surface: Add Surface Aggregator subsystem
Add Surface System Aggregator Module core and Surface Serial Hub driver,
required for the embedded controller found on Microsoft Surface devices.
The Surface System Aggregator Module (SSAM, SAM or Surface Aggregator)
is an embedded controller (EC) found on 4th and later generation
Microsoft Surface devices, with the exception of the Surface Go series.
This EC provides various functionality, depending on the device in
question. This can include battery status and thermal reporting (5th and
later generations), but also HID keyboard (6th+) and touchpad input
(7th+) on Surface Laptop and Surface Book 3 series devices.
This patch provides the basic necessities for communication with the SAM
EC on 5th and later generation devices. On these devices, the EC
provides an interface that acts as serial device, called the Surface
Serial Hub (SSH). 4th generation devices, on which the EC interface is
provided via an HID-over-I2C device, are not supported by this patch.
Specifically, this patch adds a driver for the SSH device (device HID
MSHW0084 in ACPI), as well as a controller structure and associated API.
This represents the functional core of the Surface Aggregator kernel
subsystem, introduced with this patch, and will be expanded upon in
subsequent commits.
The SSH driver acts as the main attachment point for this subsystem and
sets-up and manages the controller structure. The controller in turn
provides a basic communication interface, allowing to send requests from
host to EC and receiving the corresponding responses, as well as
managing and receiving events, sent from EC to host. It is structured
into multiple layers, with the top layer presenting the API used by
other kernel drivers and the lower layers modeled after the serial
protocol used for communication.
Said other drivers are then responsible for providing the (Surface model
specific) functionality accessible through the EC (e.g. battery status
reporting, thermal information, ...) via said controller structure and
API, and will be added in future commits.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20201221183959.1186143-2-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2020-12-22 02:39:51 +08:00
|
|
|
source "drivers/platform/surface/aggregator/Kconfig"
|
|
|
|
|
|
2020-10-09 22:11:25 +08:00
|
|
|
endif # SURFACE_PLATFORMS
|
