- 16 Mar, 2023 20 commits
-
-
Srinivas Pandruvada authored
This Intel Speed Select Technology - Performance Profile (SST-PP) feature introduces a mechanism that allows multiple optimized performance profiles per system. Each profile defines a set of CPUs that need to be online and rest offline to sustain a guaranteed base frequency. Five new IOCTLs are added: ISST_IF_PERF_LEVELS : Get number of performance levels ISST_IF_PERF_SET_LEVEL : Set to a new performance level ISST_IF_PERF_SET_FEATURE : Activate SST-BF/SST-TF for a performance level ISST_IF_GET_PERF_LEVEL_INFO : Get parameters for a performance level ISST_IF_GET_PERF_LEVEL_CPU_MASK : Get CPU mask for a performance level Once an instance is identified, read or write from correct MMIO offset for a given field as defined in the specification. For details on SST PP operations using intel-speed-selet utility, refer to: Documentation/admin-guide/pm/intel-speed-select.rst under the kernel documentation Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:
Zhang Rui <rui.zhang@intel.com> Tested-by:
Pragya Tanwar <pragya.tanwar@intel.com> Link: https://lore.kernel.org/r/20230308070642.1727167-6-srinivas.pandruvada@linux.intel.comSigned-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Srinivas Pandruvada authored
Intel Speed Select Technology Core Power (SST-CP) is an interface that allows users to define per core priority. This defines a mechanism to distribute power among cores when there is a power constrained scenario. This defines a class of service (CLOS) configuration. Three new IOCTLs are added: ISST_IF_CORE_POWER_STATE : Enable/Disable SST-CP ISST_IF_CLOS_PARAM : Configure CLOS parameters ISST_IF_CLOS_ASSOC : Associate CPUs to a CLOS To associate CPUs to CLOS, either Linux CPU numbering or PUNIT numbering scheme can be used, using parameter punit_cpu_map (1: for PUNIT numbering 0 for Linux CPU number). There is no change to IOCTL to get PUNIT CPU number for a CPU. Introduce get_instance() function, which is used by majority of IOCTLs processing to convert a socket and power domain to tpmi_per_power_domain_info * instance. This instance has all the MMIO offsets stored to read a particular field. Once an instance is identified, read or write from correct MMIO offset for a given field as defined in the specification. For details on SST CP operations using intel-speed-selet utility, refer to: Documentation/admin-guide/pm/intel-speed-select.rst under the kernel documentation Signed-off-by:
-
Srinivas Pandruvada authored
SST registers are presented to OS in multi-layer structures starting with a SST header showing version information freezing current definition. For details on SST terminology refer to Documentation/admin-guide/pm/intel-speed-select.rst under the kernel documentation SST TPMI details are published in the following document: https://github.com/intel/tpmi_power_management/blob/main/SST_TPMI_public_disclosure_FINAL.docx SST MMIO structure layout follows: SST-HEADER SST-CP Header SST-CP CONTROL SST-CP STATUS SST-CP CONFIG0 SST-CP CONFIG1 ... ... SST-PP Header SST-PP OFFSET_0 SST-PP OFFSET_1 SST_PP_0_INFO SST_PP_1_INFO SST_PP_2_INFO SST_PP_3_INFO SST-PP CONTROL SST-PP STATUS Each register bank contains information to get to next lower level information. This information is parsed and stored in the struct tpmi_per_power_domain_info for each domain. This information is used to process each SST requests. Signed-off-by:
-
Srinivas Pandruvada authored
Enumerate TPMI SST driver and create basic framework to add more features. The basic user space interface is still same as the legacy using /dev/isst_interface. Users of "intel-speed-select" utility should be able to use same commands as prior gens without being aware of new underlying hardware interface. TPMI SST driver enumerates on device "intel_vsec.tpmi-sst". Since there can be multiple instances and there is one common SST core, split implementation into two parts: A common core part and an enumeration part. The enumeration driver is loaded for each device instance and register with the TPMI SST core driver. On very first enumeration the TPMI SST core driver register with SST core driver to get IOCTL callbacks. The api_version is incremented for IOCTL ISST_IF_GET_PLATFORM_INFO, so that user space can issue new IOCTLs. Each TPMI package contains multiple power domains. Each power domain has its own set of SST controls. For each domain map the MMIO memory and update per domain struct tpmi_per_power_domain_info. This information will be used to implement other SST interfaces. Implement first IOCTL commands to get number of TPMI SST instances and instance mask as some of the power domains may not have any SST controls. Signed-off-by:
-
Srinivas Pandruvada authored
To map Linux CPU numbering scheme to hardware CPU numbering scheme MSR 0x53 is getting used. But for new generation of CPUs, this MSR is not valid. Since this is model specific MSR, this is possible. A new MSR 0x54 is defined for this purpose. User space can use the API version to distinguish format from MSR 0x53. Intel speed select utility is updated to use the new format based on the API version. Signed-off-by:
-
Koba Ko authored
Some platforms have the speaker-mute led and current driver doesn't control it. If the platform support the control of speaker-mute led, register it Signed-off-by:
Koba Ko <koba.ko@canonical.com> Link: https://lore.kernel.org/r/20230308062414.1048913-1-koba.ko@canonical.comReviewed-by:
-
Maximilian Luz authored
Add support for the POS-subsystem tablet-mode switch used on the Surface Pro 9. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20230304194611.87770-4-luzmaximilian@gmail.comReviewed-by:
-
Maximilian Luz authored
Implement support for the Type-Cover posture source (ID 0x00), found on the Surface Pro 9. Signed-off-by:
-
Maximilian Luz authored
The device posture subsystem (POS) can provide different posture sources. Different sources can provide different posture states and sources can be identified by their ID. For example, screen posture of the Surface Laptop Studio (SLS), which is currently the only supported source, uses a source ID of 0x03. The Surface Pro 9 uses the same subsystem for its Type-Cover, however, provides different states for that under the ID 0x00. To eventually support the Surface Pro 9 and potential future devices, we need to properly disambiguate between source IDs. Therefore, add the source ID to the state we carry and determine the tablet-mode state (as well as state names) based on that. Signed-off-by:
-
Hans de Goede authored
Add a new driver for the power-, wake- and reset-source functionality of the Bay Trail (BYT) version of the Crystal Cove PMIC. The main functionality here is detecting which power-sources (USB / DC in / battery) are active. This is normally exposed to userspace as a power_supply class charger device with an online sysfs attribute. But if a charger is online or not is already exposed on BYT-CRC devices through either an ACPI AC power_supply device, or through a native driver for the battery charger chip (e.g. a BQ24292i). So instead of adding duplicate info under the power_supply class this driver exports the info through debugfs and likewise adds debugfs files for the reset- and wake-source info / registers. Despite this driver only exporting debugfs bits it is still useful to have this driver because it clears the wake- and reset-source registers after reading them. Not clearing these can have undesirable side-effects. Specifically if the WAKESRC register contains 0x01 (wake by powerbutton) on reboot then the firmware on some tablets turns the reboot into a poweroff. I guess this may be necessary to make long power-presses turn into a poweroff somehow? Signed-off-by:
-
Hans de Goede authored
Immutable branch between pdx86 and backlight due for the v6.4 merge window
-
Hans de Goede authored
Add a depends on PMIC_OPREGION to x86-android-tablets Kconfig to fix the following build error: ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element" [drivers/platform/x86/x86-android-tablets/x86-android-tablets.ko] undefined! Fixes: 9b1d2662 ("platform/x86: x86-android-tablets: Add touchscreen support for Lenovo Yoga Tab 3 Pro YT3-X90F") Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202303091711.howZNrIY-lkp@intel.com/Signed-off-by:
-
Hans de Goede authored
On some MacBooks both the apple_bl and the apple-gmux backlight drivers may be able to export a /sys/class/backlight device. To avoid having 2 backlight devices for one LCD panel until now the apple-gmux driver has been calling apple_bl_unregister() to move the apple_bl backlight device out of the way when it loads. Similar problems exist on other x86 laptops and all backlight drivers which may be used on x86 laptops have moved to using acpi_video_get_backlight_type() to determine whether they should load or not. Switch apple_bl to this model too, so that it is consistent with all the other x86 backlight drivers. Besides code-simplification and consistency this has 2 other benefits: 1) It removes a race during boot where userspace will briefly see an apple_bl backlight and then have it disappear again, leading to e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 2) This allows user to switch between the drivers by passing acpi_backlight=apple_gmux or acpi_backlight=vendor on the kernel commandline. Signed-off-by:
Daniel Thompson <daniel.thompson@linaro.org> Acked-by:
Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230307120540.389920-1-hdegoede@redhat.com
-
Dan Carpenter authored
The copy_to/from_user() functions return the number of bytes remaining to be copied, but we want to return -EFAULT to the user. Fixes: ce3fef2eb235 ("platform/x86: apple-gmux: add debugfs interface") Signed-off-by:Dan Carpenter <error27@gmail.com> Reviewed-by:
Orlando Chamberlain <orlandlch.dev@gmail.com> Link: https://lore.kernel.org/r/0bdfa8c2-cb22-4bec-8773-584060613043@kili.mountainReviewed-by:
-
Orlando Chamberlain authored
Commit fc83fbc80e1a ("platform/x86: apple-gmux: refactor gmux types") neglected to update the documentation of apple_gmux_detect's arguments. Update the documentation to reflect that commit's changes. include/linux/apple-gmux.h:99: warning: Function parameter or member 'type_ret' not described in 'apple_gmux_detect' include/linux/apple-gmux.h:99: warning: Excess function parameter 'indexed_ret' description in 'apple_gmux_detect' Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/lkml/20230309122822.77435e33@canb.auug.org.au/ Fixes: fc83fbc80e1a ("platform/x86: apple-gmux: refactor gmux types") Signed-off-by:
Orlando Chamberlain <orlandoch.dev@gmail.com> Link: https://lore.kernel.org/r/20230309104353.10905-1-orlandoch.dev@gmail.comReviewed-by:
-
Hans de Goede authored
Make apple-gmux backlight registration honor the acpi_backlight=... kernel commandline option which is used to select the backlight control method on x86/ACPI devices. Reported-and-tested-by:
Aditya Garg <gargaditya08@live.com> Link: https://lore.kernel.org/platform-driver-x86/BM1PR01MB0931B467250831916F7C55B3B8A59@BM1PR01MB0931.INDPRD01.PROD.OUTLOOK.COM/Signed-off-by:
-
Orlando Chamberlain authored
Allow reading and writing gmux ports from userspace. For example: echo 4 > /sys/kernel/debug/apple_gmux/selected_port cat /sys/kernel/debug/apple_gmux/selected_port_data | xxd -p Will show the gmux version information (00000005 in this case) Reviewed-by:
-
Orlando Chamberlain authored
In some newer dual gpu MacBooks, the T2 Coprocessor functions as the gmux, and the Intel side can interract with this new gmux type through MMIO. Add support for these gmux controllers to the apple-gmux driver. We start using the GMSP(0) acpi method on these gmux's when clearing interrupts, as this prevents a flood of status=0 interrupts that can't be cleared. It's unknown if this helps or hinders older gmux types, so it isn't enabled for those. Interestingly, the ACPI table only allocates 8 bytes for GMUX, but we actually need 16, and as such we request 16 with request_mem_region. Reading and writing from ports: 16 bytes from 0xfe0b0200 are used. 0x0 to 0x4 are where data to read appears, and where data to write goes. Writing to 0xe sets the gmux port being accessed, and writing to 0xf sends commands. These commands are 0x40 & data_length for write, and data_length for read, where data_length is 1, 2 or 4. Once byte base+0xf is 0, the command is done. Issues: As with other retina models, we can't switch DDC lines so switching at runtime doesn't work if the inactive gpu driver already disabled eDP due to it not being connected when that driver loaded. Additionally, turning on the dgpu back on on the MacBookPro16,1 does not work. Reviewed-by: -
Orlando Chamberlain authored
Add apple_gmux_config struct containing operations and data specific to each mux type. This is in preparation for adding a third, MMIO based, gmux type. Reviewed-by:
-
Orlando Chamberlain authored
On T2 Macs with MMIO gmux, when GMUX_PORT_SWITCH_DISPLAY is read, it can have values of 2, 3, 4, and 5. Odd values correspond to the discrete gpu, and even values correspond to the integrated gpu. The current logic is that only 2 corresponds to IGD, but this doesn't work for T2 Macs. Instead, check the first bit to determine the connected gpu. As T2 Macs with gmux only can switch the internal display, it is untested if this change (or a similar change) would be applicable to GMUX_PORT_SWITCH_DDC and GMUX_PORT_SWITCH_EXTERNAL. Reviewed-by:
-
- 07 Mar, 2023 20 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230302144732.1903781-30-u.kleine-koenig@pengutronix.deReviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20230302144732.1903781-11-u.kleine-koenig@pengutronix.deReviewed-by:
-
