Add surface patches #7

On some Surface 3, the DMI table gets corrupted for unknown reasons and breaks existing DMI matching used for device-specific quirks. This commit adds the (broken) DMI data into dmi_system_id tables used for quirks so that each driver can enable quirks even on the affected systems. On affected systems, DMI data will look like this: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:OEMB /sys/devices/virtual/dmi/id/board_vendor:OEMB /sys/devices/virtual/dmi/id/chassis_vendor:OEMB /sys/devices/virtual/dmi/id/product_name:OEMB /sys/devices/virtual/dmi/id/sys_vendor:OEMB Expected: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:Surface 3 /sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/product_name:Surface 3 /sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation Signed-off-by: Tsuchiya Yuto <[email protected]> Patchset: surface3-oemb

This commit adds reset_wsid quirk and uses this quirk for Surface 3 on card reset. To reset mwifiex on Surface 3, it seems that calling the _DSM method exists in \_SB.WSID [1] device is required. On Surface 3, calling the _DSM method removes/re-probes the card by itself. So, need to place the reset function before performing FLR and skip performing any other reset-related works. Note that Surface Pro 3 also has the WSID device [2], but it seems to need more work. This commit only supports Surface 3 yet. [1] https://github.com/linux-surface/acpidumps/blob/05cba925f3a515f222acb5b3551a032ddde958fe/surface_3/dsdt.dsl#L11947-L12011 [2] https://github.com/linux-surface/acpidumps/blob/05cba925f3a515f222acb5b3551a032ddde958fe/surface_pro_3/dsdt.dsl#L12164-L12216 Signed-off-by: Tsuchiya Yuto <[email protected]> Patchset: mwifiex

(made referring to http://git.osdn.net/view?p=android-x86/kernel.git;a=commitdiff;h=18e2e857c57633b25b3b4120f212224a108cd883) On some Surface 3, the DMI table gets corrupted for unknown reasons and breaks existing DMI matching used for device-specific quirks. This commit adds the (broken) DMI info for the affected Surface 3. On affected systems, DMI info will look like this: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:OEMB /sys/devices/virtual/dmi/id/board_vendor:OEMB /sys/devices/virtual/dmi/id/chassis_vendor:OEMB /sys/devices/virtual/dmi/id/product_name:OEMB /sys/devices/virtual/dmi/id/sys_vendor:OEMB Expected: $ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\ chassis_vendor,product_name,sys_vendor} /sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc. /sys/devices/virtual/dmi/id/board_name:Surface 3 /sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation /sys/devices/virtual/dmi/id/product_name:Surface 3 /sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation Signed-off-by: Tsuchiya Yuto <[email protected]> Patchset: mwifiex

Currently, mwifiex fw will crash after suspend on recent kernel series. On Windows, it seems that the root port of wifi will never enter D3 state (stay on D0 state). And on Linux, disabling the D3 state for the bridge fixes fw crashing after suspend. This commit disables the D3 state of root port on driver initialization and fixes fw crashing after suspend. Signed-off-by: Tsuchiya Yuto <[email protected]> Patchset: mwifiex

The most recent firmware of the 88W8897 card reports a hardcoded LTR value to the system during initialization, probably as an (unsuccessful) attempt of the developers to fix firmware crashes. This LTR value prevents most of the Microsoft Surface devices from entering deep powersaving states (either platform C-State 10 or S0ix state), because the exit latency of that state would be higher than what the card can tolerate. Turns out the card works just the same (including the firmware crashes) no matter if that hardcoded LTR value is reported or not, so it's kind of useless and only prevents us from saving power. To get rid of those hardcoded LTR reports, it's possible to reset the PCI bridge device after initializing the cards firmware. I'm not exactly sure why that works, maybe the power management subsystem of the PCH resets its stored LTR values when doing a function level reset of the bridge device. Doing the reset once after starting the wifi firmware works very well, probably because the firmware only reports that LTR value a single time during firmware startup. Patchset: mwifiex

The Marvell 88W8897 combined wifi and bluetooth card (pcie+usb version) is used in a lot of Microsoft Surface devices, and all those devices suffer from very low 2.4GHz wifi connection speeds while bluetooth is enabled. The reason for that is that the default passive scanning interval for Bluetooth Low Energy devices is quite high in Linux (interval of 60 msec and scan window of 30 msec, see hci_core.c), and the Marvell chip is known for its bad bt+wifi coexisting performance. So decrease that passive scan interval and make the scan window shorter on this particular device to allow for spending more time transmitting wifi signals: The new scan interval is 250 msec (0x190 * 0.625 msec) and the new scan window is 6.25 msec (0xa * 0,625 msec). This change has a very large impact on the 2.4GHz wifi speeds and gets it up to performance comparable with the Windows driver, which seems to apply a similar quirk. The interval and window length were tested and found to work very well with a lot of Bluetooth Low Energy devices, including the Surface Pen, a Bluetooth Speaker and two modern Bluetooth headphones. All devices were discovered immediately after turning them on. Even lower values were also tested, but they introduced longer delays until devices get discovered. Patchset: mwifiex

On the 88W8897 card it's very important the TX ring write pointer is updated correctly to its new value before setting the TX ready interrupt, otherwise the firmware appears to crash (probably because it's trying to DMA-read from the wrong place). Since PCI uses "posted writes" when writing to a register, it's not guaranteed that a write will happen immediately. That means the pointer might be outdated when setting the TX ready interrupt, leading to firmware crashes especially when ASPM L1 and L1 substates are enabled (because of the higher link latency, the write will probably take longer). So fix those firmware crashes by always forcing non-posted writes. We do that by simply reading back the register after writing it, just as a lot of other drivers do. There are two reproducers that are fixed with this patch: 1) During rx/tx traffic and with ASPM L1 substates enabled (the enabled substates are platform dependent), the firmware crashes and eventually a command timeout appears in the logs. That crash is fixed by using a non-posted write in mwifiex_pcie_send_data(). 2) When sending lots of commands to the card, waking it up from sleep in very quick intervals, the firmware eventually crashes. That crash appears to be fixed by some other non-posted write included here. Patchset: mwifiex

Some Surface devices, specifically the Surface Go and AMD version of the Surface Laptop 3 (wich both come with QCA6174 WiFi chips), work better with a different board file, as it seems that the firmeware included upstream is buggy. As it is generally not a good idea to randomly overwrite files, let alone doing so via packages, we add module parameters to override those file names in the driver. This allows us to package/deploy the override via a modprobe.d config. Signed-off-by: Maximilian Luz <[email protected]> Patchset: ath10k

Patchset: ipts

Based on linux-surface/intel-precise-touch@3f362c Signed-off-by: Dorian Stoll <[email protected]> Patchset: ipts

Adds a quirk so that IOMMU uses passthrough mode for the IPTS device. Otherwise, when IOMMU is enabled, IPTS produces DMAR errors like: DMAR: [DMA Read NO_PASID] Request device [00:16.4] fault addr 0x104ea3000 [fault reason 0x06] PTE Read access is not set This is very similar to the bug described at: https://bugs.launchpad.net/bugs/1958004 Fixed with the following patch which this patch basically copies: https://launchpadlibrarian.net/586396847/43255ca.diff Patchset: ipts

…CONFIG_SURFACE_AGGREGATOR_BUS is disabled In SSAM subsystem drivers that handle both ACPI and SSAM-native client devices, we may want to check whether we have a SSAM (native) client device. Further, we may want to do this even when instantiation thereof cannot happen due to CONFIG_SURFACE_AGGREGATOR_BUS=n. Currently, doing so causes an error due to an undefined reference error due to ssam_device_type being placed in the bus source unit. Therefore, if CONFIG_SURFACE_AGGREGATOR_BUS is not defined, simply let is_ssam_device() return false to prevent this error. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

Some SSAM devices, notably the keyboard cover (keyboard and touchpad) on the Surface Pro 8, can be hot-removed. When this occurs, communication with the device may fail and time out. This timeout can unnecessarily block and slow down device removal and even cause issues when the devices are detached and re-attached quickly. Thus, communication should generally be avoided once hot-removal is detected. While we already remove a device as soon as we detect its (hot-)removal, the corresponding device driver may still attempt to communicate with the device during teardown. This is especially critical as communication failure may also extend to disabling of events, which is typically done at that stage. Add a flag to allow marking devices as hot-removed. This can then be used during client driver teardown to check if any communication attempts should be avoided. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

…on unregistering When SSAM client devices have been (physically) hot-removed, communication attempts with those devices may fail and time out. This can even extend to event notifiers, due to which timeouts may occur during device removal, slowing down that process. Add a parameter to the notifier unregister function that allows skipping communication with the EC to prevent this. Furthermore, add wrappers for registering and unregistering notifiers belonging to SSAM client devices that automatically check if the device has been marked as hot-removed and communication should be avoided. Note that non-SSAM client devices can generally not be hot-removed, so also add a convenience wrapper for those, defaulting to allow communication. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

… notifier registration Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

…r registration Use newly introduced client device wrapper functions for notifier registration and unregistration. Signed-off-by: Maximilian Luz <[email protected]> Acked-by: Sebastian Reichel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

Add support for hot-removal of SSAM HID client devices. Once a device has been hot-removed, further communication with it should be avoided as it may fail and time out. While the device will be removed as soon as we detect hot-removal, communication may still occur during teardown, especially when unregistering notifiers. While hot-removal is a surprise event that can happen at any time, try to avoid communication as much as possible once it has been detected to prevent timeouts that can slow down device removal and cause issues, e.g. when quickly re-attaching the device. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

The KIP subsystem (full name unknown, abbreviation has been obtained through reverse engineering) handles detachable peripherals such as the keyboard cover on the Surface Pro X and Surface Pro 8. It is currently not entirely clear what this subsystem entails, but at the very least it provides event notifications for when the keyboard cover on the Surface Pro X and Surface Pro 8 have been detached or re-attached, as well as the state that the keyboard cover is currently in (e.g. folded-back, folded laptop-like, closed, etc.). Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

…nality The Surface System Aggregator Module (SSAM) has multiple subsystems that can manage detachable devices. At the moment, we only support the "base" (BAS/0x11) subsystem, which is used on the Surface Book 3 to manage devices (including keyboard, touchpad, and secondary battery) connected to the base of the device. The Surface Pro 8 has a new type-cover with keyboard and touchpad, which is managed via the KIP/0x0e subsystem. The general procedure is the same, but with slightly different events and setup. To make implementation of the KIP hub easier and prevent duplication, generify the parts of the base hub that we can use for the KIP hub (or any potential future subsystem hubs). This also switches over to use the newly introduced "hot-remove" functionality, which should prevent communication issues when devices have been detached. Lastly, also drop the undocumented and unused sysfs "state" attribute of the base hub. It has at best been useful for debugging. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

Use the target category of the (base) hub as instance id in the (virtual) hub device UID. This makes association of the hub with the respective subsystem easier. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

Add a Surface System Aggregator Module (SSAM) client device hub for hot-removable devices managed via the KIP subsystem. The KIP subsystem (full name unknown, abbreviation has been obtained through reverse engineering) is a subsystem that manages hot-removable SSAM client devices. Specifically, it manages HID input devices contained in the detachable keyboard cover of the Surface Pro 8 and Surface Pro X. The KIP subsystem handles a single group of devices (e.g. all devices contained in the keyboard cover) and cannot handle devices individually. Thus we model it as a client device hub, which (hot-)removes all devices contained under it once removal of the hub (e.g. keyboard cover) has been detected and (re-)adds all devices once the physical hub device has been (re-)attached. To do this, use the previously generified SSAM subsystem hub framework. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

… on Surface Pro 8 Add support for the detachable keyboard cover on the Surface Pro 8. The keyboard cover on the Surface Pro 8 is, unlike the keyboard covers of earlier Surface Pro generations, handled via the Surface System Aggregator Module (SSAM). The keyboard and touchpad (as well as other HID input devices) of this cover are standard SSAM HID client devices (just like keyboard and touchpad on e.g. the Surface Laptop 3 and 4), however, some care needs to be taken as they can be physically detached (similarly to the Surface Book 3). Specifically, the respective SSAM client devices need to be removed when the keyboard cover has been detached and (re-)initialized when the keyboard cover has been (re-)attached. On the Surface Pro 8, detachment of the keyboard cover (and by extension its devices) is managed via the KIP subsystem. Therefore, said devices need to be registered under the KIP device hub, which in turn will remove and re-create/re-initialize those devices as needed. Signed-off-by: Maximilian Luz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Patchset: surface-sam

With the introduction of the Surface Laptop Studio, more event- and target categories have been added. Therefore, increase the number of reserved events and extend the enum of know target categories to accommodate this. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…ument and return value Add helper macros for synchronous stack-allocated Surface Aggregator request with both argument and return value, similar to the current argument-only and return-value-only ones. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

Add a driver providing a tablet-mode switch input device for Surface models using the KIP subsystem to manage detachable peripherals. The Surface Pro 8 has a detachable keyboard cover. Unlike the keyboard covers of previous generation Surface Pro models, this cover is fully handled by the Surface System Aggregator Module (SSAM). The SSAM KIP subsystem (full name unknown, abbreviation found through reverse engineering) provides notifications for mode changes of the cover. Specifically, it allows us to know when the cover has been folded back, detached, or whether it is in laptop mode. The driver introduced with this change captures these events and translates them to standard SW_TABLET_MODE input events. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…itch on Surface Pro 8 Add a KIP subsystem tablet-mode switch device for the Surface Pro 8. The respective driver for this device provides SW_TABLET_MODE input events for user-space based on the state of the keyboard cover (e.g. detached, folded-back, normal/laptop mode). Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…itch on Surface Laptop Studio Add a POS subsystem tablet-mode switch device for the Surface Laptop Studio. The respective driver for this device provides SW_TABLET_MODE input events for user-space based on the posture of the screen. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…o core module Move helper functions for client device registration to the core module. This simplifies addition of future DT/OF support and also allows us to split out the device hub drivers into their own module. At the same time, also improve device node validation a bit by not silently skipping devices with invalid device UID specifiers. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

… module Split out subsystem device hub drivers into their own module. This allows us to load the hub drivers separately from the registry, which will help future DT/OF support. While doing so, also remove a small bit of code duplication. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

Update the copyright of various Surface drivers to the current year. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…on their function Rename HID device nodes based on their function. In particular, these are nodes for firmware updates via the CFU mechanism (component firmware update), HID based sensors, and a USB-C USCI client. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…on new findings On Windows, the HID devices with target ID 1 are grouped as "Surface Hot Plug - SAM". Rename their device nodes in the registry to reflect that and update the comments accordingly. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

…d USCI client to SP8 Add software nodes for the HID sensor collection and the UCM USCI HID client to the Surface Pro 8. In contrast to the type-cover devices, these devices are directly attached to the SAM controller, without any hub. This enables support for HID-based sensors, including the ones used for automatic screen rotation, on the Surface Pro 8. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

… Go 2 The Surface Laptop Go 2 seems to have the same SAM client devices as the Surface Laptop Go 1, so re-use its node group. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam

Microsoft Surface Pro 4 and Book 1 devices access the MSHW0030 I2C device via a generic serial bus operation region and RawBytes read access. On the Surface Book 1, this access is required to turn on (and off) the discrete GPU. Multiple things are to note here: a) The RawBytes access is device/driver dependent. The ACPI specification states: > Raw accesses assume that the writer has knowledge of the bus that > the access is made over and the device that is being accessed. The > protocol may only ensure that the buffer is transmitted to the > appropriate driver, but the driver must be able to interpret the > buffer to communicate to a register. Thus this implementation may likely not work on other devices accessing I2C via the RawBytes accessor type. b) The MSHW0030 I2C device is an HID-over-I2C device which seems to serve multiple functions: 1. It is the main access point for the legacy-type Surface Aggregator Module (also referred to as SAM-over-HID, as opposed to the newer SAM-over-SSH/UART). It has currently not been determined on how support for the legacy SAM should be implemented. Likely via a custom HID driver. 2. It seems to serve as the HID device for the Integrated Sensor Hub. This might complicate matters with regards to implementing a SAM-over-HID driver required by legacy SAM. In light of this, the simplest approach has been chosen for now. However, it may make more sense regarding breakage and compatibility to either provide functionality for replacing or enhancing the default operation region handler via some additional API functions, or even to completely blacklist MSHW0030 from the I2C core and provide a custom driver for it. Replacing/enhancing the default operation region handler would, however, either require some sort of secondary driver and access point for it, from which the new API functions would be called and the new handler (part) would be installed, or hard-coding them via some sort of quirk-like interface into the I2C core. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-sam-over-hid

Add driver exposing the discrete GPU power-switch of the Microsoft Surface Book 1 to user-space. On the Surface Book 1, the dGPU power is controlled via the Surface System Aggregator Module (SAM). The specific SAM-over-HID command for this is exposed via ACPI. This module provides a simple driver exposing the ACPI call via a sysfs parameter to user-space, so that users can easily power-on/-off the dGPU. Patchset: surface-sam-over-hid

The power button on the AMD variant of the Surface Laptop uses the same MSHW0040 device ID as the 5th and later generation of Surface devices, however they report 0 for their OEM platform revision. As the _DSM does not exist on the devices requiring special casing, check for the existance of the _DSM to determine if soc_button_array should be loaded. Fixes: c394159 ("Input: soc_button_array - add support for newer surface devices") Co-developed-by: Maximilian Luz <[email protected]> Signed-off-by: Sachi King <[email protected]> Patchset: surface-button

The AMD variant of the Surface Laptop report 0 for their OEM platform revision. The Surface devices that require the surfacepro3_button driver do not have the _DSM that gets the OEM platform revision. If the method does not exist, load surfacepro3_button. Fixes: 64dd243 ("platform/x86: surfacepro3_button: Fix device check") Co-developed-by: Maximilian Luz <[email protected]> Signed-off-by: Sachi King <[email protected]> Patchset: surface-button

The Type Cover for Microsoft Surface devices supports a special usb control request to disable or enable the built-in keyboard backlight. On Windows, this request happens when putting the device into suspend or resuming it, without it the backlight of the Type Cover will remain enabled for some time even though the computer is suspended, which looks weird to the user. So add support for this special usb control request to hid-multitouch, which is the driver that's handling the Type Cover. The reason we have to use a pm_notifier for this instead of the usual suspend/resume methods is that those won't get called in case the usb device is already autosuspended. Also, if the device is autosuspended, we have to briefly autoresume it in order to send the request. Doing that should be fine, the usb-core driver does something similar during suspend inside choose_wakeup(). To make sure we don't send that request to every device but only to devices which support it, add a new quirk MT_CLS_WIN_8_MS_SURFACE_TYPE_COVER to hid-multitouch. For now this quirk is only enabled for the usb id of the Surface Pro 2017 Type Cover, which is where I confirmed that it's working. Patchset: surface-typecover

The Surface Pro Type Cover has several non standard HID usages in it's hid report descriptor. I noticed that, upon folding the typecover back, a vendor specific range of 4 32 bit integer hid usages is transmitted. Only the first byte of the message seems to convey reliable information about the keyboard state. 0x22 => Normal (keys enabled) 0x33 => Folded back (keys disabled) 0x53 => Rotated left/right side up (keys disabled) 0x13 => Cover closed (keys disabled) 0x43 => Folded back and Tablet upside down (keys disabled) This list may not be exhaustive. The tablet mode switch will be disabled for a value of 0x22 and enabled on any other value. Patchset: surface-typecover

… info When the battery is neither charging or discharging and is not full, "not-charging" is a useful status description for the case in general. Currently this state is set as "unknown" by default, expect when this is explicitly replaced with "not-charging" on a per device or per vendor basis. A lot of devices have this state without a BIOS specification available explicitly describing it. e.g. some current Clevo barebones have a BIOS setting to stop charging at a user defined battery level. Signed-off-by: Werner Sembach <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Patchset: surface-battery

…aptop 4 The 13" Intel version of the Surface Laptop 4 uses the same GPE as the Surface Laptop Studio for wakeups via the lid. Set it up accordingly. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-gpe

… device The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Signed-off-by: Hans de Goede <[email protected]> Patchset: cameras

Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, The IPU driver allocates its own page table that is not mapped via the DMA, and thus the Intel IOMMU driver blocks access giving this error: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Read] Request device [00:05.0] PASID ffffffff fault addr 76406000 [fault reason 06] PTE Read access is not set As IPU is not an external facing device which is not risky, so use IOMMU passthrough mode for Intel IPUs. Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6 Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: zouxiaoh <[email protected]> Signed-off-by: Xu Chongyang <[email protected]> Patchset: cameras

The TPS68470 PMIC has an I2C passthrough mode through which I2C traffic can be forwarded to a device connected to the PMIC as though it were connected directly to the system bus. Enable this mode when the chip is initialised. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Add a driver for the DW9719 VCM. The driver creates a v4l2 subdevice and registers a control to set the desired focus. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

It should depend on VIDEO_DEV instead of VIDEO_V4L2. Signed-off-by: Maximilian Luz <[email protected]> Patchset: cameras

When iterating over the media graph, don't follow links that are not data links. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

To describe in the kernel the connection between devices and their supporting peripherals (for example, a camera sensor and the vcm driving the focusing lens for it), add a new type of media link to introduce the concept of these ancillary links. Add some elements to the uAPI documentation to explain the new link type, their purpose and some aspects of their current implementation. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Now we have three types of media link, printing the right name during debug output is slightly more complicated. Add a helper function to make it easier. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Add functions to create ancillary links, so that they don't need to be manually created by users. Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Upon an async fwnode match, there's some typical behaviour that the notifier and matching subdev will want to do. For example, a notifier representing a sensor matching to an async subdev representing its VCM will want to create an ancillary link to expose that relationship to userspace. To avoid lots of code in individual drivers, try to build these links within v4l2 core. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Creating links and registering subdev nodes during the .complete() callback has the unfortunate effect of preventing all cameras that connect to a notifier from working if any one of their drivers fails to probe. Moving the functionality from .complete() to .bound() allows those camera sensor drivers that did probe correctly to work regardless. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

Removing the .complete() callback had some unintended consequences. Because the VCM driver is not directly linked to the ipu3-cio2 driver .bound() never gets called for it, which means its devnode is never created if it probes late. Because .complete() waits for any sub-notifiers to also be complete it is captured in that call. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras

This patch is the work of Thomas Gleixner <[email protected]> and is copied from: https://lore.kernel.org/lkml/[email protected]/ This patch adds a quirk to the ACPI setup to patch in the the irq 7 pin setup that is missing in the laptops ACPI table. This patch was used for validation of the issue, and is not a proper fix, but is probably a better temporary hack than continuing to probe the Legacy PIC and run with the PIC in an unknown state. Patchset: amd-gpio

The 13" version of the Surface Laptop 4 has the same problem as the 15" version, but uses a different SKU. Add that SKU to the quirk as well. Patchset: amd-gpio

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add surface patches #7

Add surface patches #7

Commits on Nov 16, 2022