45 lines · plain
1.. SPDX-License-Identifier: GPL-2.0+2 3.. |san_client_link| replace:: :c:func:`san_client_link`4.. |san_dgpu_notifier_register| replace:: :c:func:`san_dgpu_notifier_register`5.. |san_dgpu_notifier_unregister| replace:: :c:func:`san_dgpu_notifier_unregister`6 7===================8Surface ACPI Notify9===================10 11The Surface ACPI Notify (SAN) device provides the bridge between ACPI and12SAM controller. Specifically, ACPI code can execute requests and handle13battery and thermal events via this interface. In addition to this, events14relating to the discrete GPU (dGPU) of the Surface Book 2 can be sent from15ACPI code (note: the Surface Book 3 uses a different method for this). The16only currently known event sent via this interface is a dGPU power-on17notification. While this driver handles the former part internally, it only18relays the dGPU events to any other driver interested via its public API and19does not handle them.20 21The public interface of this driver is split into two parts: Client22registration and notifier-block registration.23 24A client to the SAN interface can be linked as consumer to the SAN device25via |san_client_link|. This can be used to ensure that the a client26receiving dGPU events does not miss any events due to the SAN interface not27being set up as this forces the client driver to unbind once the SAN driver28is unbound.29 30Notifier-blocks can be registered by any device for as long as the module is31loaded, regardless of being linked as client or not. Registration is done32with |san_dgpu_notifier_register|. If the notifier is not needed any more, it33should be unregistered via |san_dgpu_notifier_unregister|.34 35Consult the API documentation below for more details.36 37 38API Documentation39=================40 41.. kernel-doc:: include/linux/surface_acpi_notify.h42 43.. kernel-doc:: drivers/platform/surface/surface_acpi_notify.c44 :export:45