summaryrefslogtreecommitdiffstats
path: root/drivers/platform/x86/amd-pmc.c
Commit message (Collapse)AuthorAgeFilesLines
* platform/x86: amd-pmc: Fix build error unused-functionRen Zhijie2022-05-061-34/+35
| | | | | | | | | | | | | | | | | | | | | | | If CONFIG_SUSPEND and CONFIG_DEBUG_FS are not set. compile error: drivers/platform/x86/amd-pmc.c:323:12: error: ‘get_metrics_table’ defined but not used [-Werror=unused-function] static int get_metrics_table(struct amd_pmc_dev *pdev, struct smu_metrics *table) ^~~~~~~~~~~~~~~~~ drivers/platform/x86/amd-pmc.c:298:12: error: ‘amd_pmc_idlemask_read’ defined but not used [-Werror=unused-function] static int amd_pmc_idlemask_read(struct amd_pmc_dev *pdev, struct device *dev, ^~~~~~~~~~~~~~~~~~~~~ drivers/platform/x86/amd-pmc.c:196:12: error: ‘amd_pmc_get_smu_version’ defined but not used [-Werror=unused-function] static int amd_pmc_get_smu_version(struct amd_pmc_dev *dev) ^~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors To fix building warning, wrap all related code with CONFIG_SUSPEND or CONFIG_DEBUG_FS. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ren Zhijie <renzhijie2@huawei.com> Link: https://lore.kernel.org/r/20220505121958.138905-1-renzhijie2@huawei.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Shuffle location of amd_pmc_get_smu_version()Nathan Chancellor2022-04-271-20/+20
| | | | | | | | | | | | | | | | | | When CONFIG_DEBUG_FS is disabled, amd_pmc_get_smu_version() is unused: drivers/platform/x86/amd-pmc.c:196:12: warning: unused function 'amd_pmc_get_smu_version' [-Wunused-function] static int amd_pmc_get_smu_version(struct amd_pmc_dev *dev) ^ 1 warning generated. Eliminate the warning by moving amd_pmc_get_smu_version() to the CONFIG_DEBUG_FS block where it is used. Fixes: b0c07116c894 ("platform/x86: amd-pmc: Avoid reading SMU version at probe time") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220418213800.21257-1-nathan@kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Avoid reading SMU version at probe timeMario Limonciello2022-04-131-1/+7
| | | | | | | | | | | | | Currently the SMU version only used to determine whether the SMU supports reading the idle mask. To speed up startup, move it to the first time the idle mask is read. This decreases the startup time from ~28500us to 100us. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411143820.13971-3-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Move FCH init to first useMario Limonciello2022-04-131-11/+12
| | | | | | | | | | | | | FCH address is accessed only when looking at s0ix stats. As this is unnecessary for initialization, move it ito the first time stats are accessed from sysfs. This descrease startup time by about 200us. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411143820.13971-2-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Move SMU logging setup out of initMario Limonciello2022-04-131-19/+28
| | | | | | | | | | | | | | | | SMU logging is setup when the device is probed currently. In analyzing boot performance it was observed that amd_pmc_probe is taking ~116800us on startup on an OEM platform. This is longer than expected, and is caused by enabling SMU logging at startup. As the SMU logging is only needed for debugging, initialize it only upon use. This decreases the time for amd_pmc_probe to ~28800us. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411143820.13971-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix compilation without CONFIG_SUSPENDMario Limonciello2022-04-041-1/+13
| | | | | | | | | | | | | | | | | | Since commit b1f66033cd4e ("platform/x86: amd-pmc: Move to later in the suspend process") amd-pmc doesn't use traditional suspend resume callback anymore but relies on functions only created declared when CONFIG_SUSPEND is set. Check for CONFIG_SUSPEND and only use those functions in those circumstances. Fixes: commit b1f66033cd4e ("platform/x86: amd-pmc: Move to later in the suspend process") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20220402231122.3877-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Only report STB errors when STB enabledMario Limonciello2022-03-181-6/+8
| | | | | | | | | | | | | | Currently if STB is disabled but an earlier function reported an error an incorrect error will be emitted about failing to write to STB. Correct this logic error by only showing errors when STB is enabled. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220317190301.6818-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Drop CPU QoS workaroundMario Limonciello2022-03-171-29/+3
| | | | | | | | | | | | | | A workaround was previously introduced as part of commit 646f429ec2de ("platform/x86: amd-pmc: Set QOS during suspend on CZN w/ timer wakeup") to prevent CPUs from going into the deepest state during the execution of the `noirq` stage of `amd_pmc`. As `amd_pmc` has been pushed to the last step for suspend on AMD platforms, this workaround is no longer necessary. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220317141445.6498-4-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Output error codes in messagesMario Limonciello2022-03-171-5/+7
| | | | | | | | | | | | The return type for the s2idle callbacks is 'void', so any errors that occur will no longer be displayed. Output these error codes in the messages in case of any failures. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220317141445.6498-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Move to later in the suspend processMario Limonciello2022-03-171-15/+15
| | | | | | | | | | | | | | | | | | | | The `OS_HINT` message is supposed to indicate that everything else that is supposed to go into the deepest state has done so. This assumption is invalid as: 1) The CPUs will still go in and out of the deepest state 2) Other devices may still run their `noirq` suspend routines 3) The LPS0 ACPI device will still run To more closely mirror how this works on other operating systems, move the `amd-pmc` suspend to the very last thing before the s2idle loop via an lps0 callback. Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220317141445.6498-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Validate entry into the deepest state on resumeMario Limonciello2022-03-101-3/+26
| | | | | | | | | | | | | Currently the only way to discover if a system went into the deepest sleep state is to read from sysfs after you finished suspend. To better illustrate to users that problems have occurred, check as part of resume and display a warning. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220310150920.560583-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: uninitialized variable in amd_pmc_s2d_init()Dan Carpenter2022-03-081-1/+2
| | | | | | | | | The "size" variable can be uninitialized if amd_pmc_send_cmd() fails. Fixes: 3d7d407dfb05 ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220307141832.GA19660@kili Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Set QOS during suspend on CZN w/ timer wakeupMario Limonciello2022-03-021-9/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") adds support for using another platform timer in lieu of the RTC which doesn't work properly on some systems. This path was validated and worked well before submission. During the 5.16-rc1 merge window other patches were merged that caused this to stop working properly. When this feature was used with 5.16-rc1 or later some OEM laptops with the matching firmware requirements from that commit would shutdown instead of program a timer based wakeup. This was bisected to commit 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path"). This wasn't supposed to cause any negative impacts and also tested well on both Intel and ARM platforms. However this changed the semantics of when CPUs are allowed to be in the deepest state. For the AMD systems in question it appears this causes a firmware crash for timer based wakeup. It's hypothesized to be caused by the `amd-pmc` driver sending `OS_HINT` and all the CPUs going into a deep state while the timer is still being programmed. It's likely a firmware bug, but to avoid it don't allow setting CPUs into the deepest state while using CZN timer wakeup path. If later it's discovered that this also occurs from "regular" suspends without a timer as well or on other silicon, this may be later expanded to run in the suspend path for more scenarios. Cc: stable@vger.kernel.org # 5.16+ Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/linux-acpi/BL1PR12MB51570F5BD05980A0DCA1F3F4E23A9@BL1PR12MB5157.namprd12.prod.outlook.com/T/#mee35f39c41a04b624700ab2621c795367f19c90e Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path") Fixes: 23f62d7ab25b ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions") Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB featureSanket Goswami2022-02-171-14/+130
| | | | | | | | | | | | | | | Spill to DRAM functionality is a feature that allows STB (Smart Trace Buffer) to spill data from SRAM into DRAM on some future AMD ASICs. The size allocated for STB is more than the earlier SoC's which helps to collect more tracing and telemetry data. Co-developed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220204122527.3873552-1-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Correct usage of SMU versionMario Limonciello2022-01-241-5/+8
| | | | | | | | | | | | | | | | | Yellow carp has been outputting versions like `1093.24.0`, but this is supposed to be 69.24.0. That is the MSB is being interpreted incorrectly. The MSB is not part of the major version, but has generally been treated that way thus far. It's actually the program, and used to distinguish between two programs from a similar family but different codebase. Link: https://patchwork.freedesktop.org/patch/469993/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220120174439.12770-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Make amd_pmc_stb_debugfs_fops staticHans de Goede2022-01-241-1/+1
| | | | | | | | | | amd_pmc_stb_debugfs_fops is not used outside of amd-pmc.c, make it static. Cc: Sanket Goswami <Sanket.Goswami@amd.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220117112644.260168-1-hdegoede@redhat.com
* platform/x86: amd-pmc: only use callbacks for suspendMario Limonciello2021-12-211-1/+2
| | | | | | | | | | | | This driver is intended to be used exclusively for suspend to idle so callbacks to send OS_HINT during hibernate and S5 will set OS_HINT at the wrong time leading to an undefined behavior. Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211210143529.10594-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add support for AMD Smart Trace BufferSanket Goswami2021-12-211-0/+120
| | | | | | | | | | | | | | | | | | STB (Smart Trace Buffer), is a debug trace buffer that isolates the failures by analyzing the last running feature of a system. This non-intrusive way always runs in the background and stores the trace into the SoC. This patch enables the STB feature by passing module param "enable_stb=1" while loading the driver and provides mechanism to access the STB buffer using the read and write routines. Co-developed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20211130112318.92850-3-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Simplify error handling and store the pci_dev in ↵Sanket Goswami2021-12-211-15/+25
| | | | | | | | | | | | | | amd_pmc_dev structure Handle error-exits in the amd_pmc_probe() to avoid duplication and store the root port information in amd_pmc_probe() so that the information can be used across multiple routines. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20211130112318.92850-2-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix s2idle failures on certain AMD laptopsFabrizio Bertocci2021-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | On some AMD hardware laptops, the system fails communicating with the PMC when entering s2idle and the machine is battery powered. Hardware description: HP Pavilion Aero Laptop 13-be0097nr CPU: AMD Ryzen 7 5800U with Radeon Graphics GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:1638] (rev c1) Detailed description of the problem (and investigation) here: https://gitlab.freedesktop.org/drm/amd/-/issues/1799 Patch is a single line: reduce the polling delay in half, from 100uSec to 50uSec when waiting for a change in state from the PMC after a write command operation. After changing the delay, I did not see a single failure on this machine (I have this fix for now more than one week and s2idle worked every single time on battery power). Cc: stable@vger.kernel.org Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Fabrizio Bertocci <fabriziobertocci@gmail.com> Link: https://lore.kernel.org/r/CADtzkx7TdfbwtaVEXUdD6YXPey52E-nZVQNs+Z41DTx7gqMqtw@mail.gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Drop check for valid alarm timeMario Limonciello2021-10-271-3/+0
| | | | | | | | | | This is already checked when calling rtc_read_alarm. Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-3-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Downgrade dev_info message to dev_dbgMario Limonciello2021-10-271-1/+1
| | | | | | | | | | | For the majority of users this information will not be informative as they've chosen to program the RTC before going to sleep. Suggested-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: fix compilation without CONFIG_RTC_SYSTOHC_DEVICEMario Limonciello2021-10-271-1/+1
| | | | | | | | | | | | | Just hardcode the RTC to "rtc0" which is the default for CONFIG_RTC_SYSTOHC_DEVICE and used by all standard x86 distros. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Fixes: 59348401ebed ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211026171443.289-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeupMario Limonciello2021-10-211-1/+59
| | | | | | | | | | | | | | | | | | | | | | RTC based wakeup from s0i3 doesn't work properly on some Green Sardine platforms. Because of this, a newer SMU for Green Sardine has the ability to pass wakeup time as argument of the upper 16 bits of OS_HINT message. With older firmware setting the timer value in OS_HINT will cause firmware to reject the hint, so only run this path on: 1) Green Sardine 2) Minimum SMU FW 3) RTC alarm armed during s0i3 entry Using this method has some limitations that the s0i3 wakeup will need to be between 4 seconds and 18 hours, so check those boundary conditions as well and abort the suspend if RTC is armed for too short or too long of a duration. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211020162946.10537-2-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: adjust arguments for `amd_pmc_send_cmd`Mario Limonciello2021-10-211-3/+3
| | | | | | | | | | | | | Currently the "argument" for the "message" is listed as a boolean value. This works well for the commands used currently, but an additional upcoming command will pass more data in the message. Expand it to be a full 32 bit value. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211020162946.10537-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add alternative acpi id for PMC controllerSachi King2021-10-111-0/+1
| | | | | | | | | | | | | | The Surface Laptop 4 AMD has used the AMD0005 to identify this controller instead of using the appropriate ACPI ID AMDI0005. Include AMD0005 in the acpi id list. Link: https://github.com/linux-surface/acpidumps/tree/master/surface_laptop_4_amd Link: https://gist.github.com/nakato/2a1a7df1a45fe680d7a08c583e1bf863 Cc: <stable@vger.kernel.org> # 5.14+ Signed-off-by: Sachi King <nakato@nakato.io> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.io Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add a message to print resume time infoSanket Goswami2021-09-281-0/+2
| | | | | | | | | | | Add a message to print the resume time information obtained from the smu_metrics structure. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20210921120020.19454-1-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Send command to dump data after clearing OS_HINTSanket Goswami2021-09-281-3/+3
| | | | | | | | | | | | | | It was reported that the resume stats received from the firmware are always zero. This happens because the SMU expects the driver to send the command to dump the log data after clearing the OS_HINT. Adjust the order of the commands sent to SMU. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Link: https://lore.kernel.org/r/20210921115910.19401-1-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix compilation when CONFIG_DEBUGFS is disabledHans de Goede2021-09-281-43/+43
| | | | | | | | | | | | | | | | The amd_pmc_get_smu_version() and amd_pmc_idlemask_read() functions are used in the probe / suspend/resume code, so they are also used when CONFIG_DEBUGFS is disabled, move them outside of the #ifdef CONFIG_DEBUGFS block. Note this purely moves the code to above the #ifdef CONFIG_DEBUGFS, the code is completely unchanged. Fixes: f6045de1f532 ("platform/x86: amd-pmc: Export Idlemask values based on the APU") Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: Sanket Goswami <Sanket.Goswami@amd.com> Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Export Idlemask values based on the APUSanket Goswami2021-09-161-0/+76
| | | | | | | | | | | | | | | | | IdleMask is the metric used by the PM firmware to know the status of each of the Hardware IP blocks monitored by the PM firmware. Knowing this value is key to get the information of s2idle suspend/resume status. This value is mapped to PMC scratch registers, retrieve them accordingly based on the CPU family and the underlying firmware support. Co-developed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20210916124002.2529-1-Sanket.Goswami@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Check s0i3 cycle statusSanket Goswami2021-09-161-2/+3
| | | | | | | | | | | As the PM firmware returns the status of the last s0i3 in the smu_metrics structure, the existing name "s0i3_cyclecount" seems to be a misnomer. Change it accordingly to "s0i3_last_entry_status". Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210916124130.2581-1-Sanket.Goswami@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Increase the response register timeoutMario Limonciello2021-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | There have been reports of approximately a 0.9%-1.7% failure rate in SMU communication timeouts with s0i3 entry on some OEM designs. Currently the design in amd-pmc is to try every 100us for up to 20ms. However the GPU driver which also communicates with the SMU using a mailbox register which the driver polls every 1us for up to 2000ms. In the GPU driver this was increased by commit 055162645a40 ("drm/amd/pm: increase time out value when sending msg to SMU") Increase the maximum timeout used by amd-pmc to 2000ms to match this behavior. This has been shown to improve the stability for machines that randomly have failures. Cc: stable@kernel.org Reported-by: Julian Sikorski <belegdol@gmail.com> BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1629 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210914020115.655-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix undefined reference to __udivdi3Shyam Sundar S K2021-07-171-1/+2
| | | | | | | | | | | | | | | | | | | | | It was reported that on i386 config ------ on i386: ld: drivers/platform/x86/amd-pmc.o: in function `s0ix_stats_show': amd-pmc.c:(.text+0x100): undefined reference to `__udivdi3' ------- The reason for this is that 64-bit integer division is not supported on 32-bit architecture. Use do_div macro to fix this. Fixes: b9a4fa6978be ("platform/x86: amd-pmc: Add support for logging s0ix counters") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> # and build-tested Link: https://lore.kernel.org/r/20210716153802.2929670-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix missing unlock on error in amd_pmc_send_cmd()Yang Yingliang2021-07-151-1/+1
| | | | | | | | | | | Add the missing unlock before return from function amd_pmc_send_cmd() in the error handling case. Fixes: 95e1b60f8dc8 ("platform/x86: amd-pmc: Fix command completion code") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210715074327.1966083-1-yangyingliang@huawei.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Use return code on suspendMario Limonciello2021-07-141-1/+1
| | | | | | | | | | | | Right now the driver will still return success even if the OS_HINT command failed to send to the SMU. In the rare event of a failure, the suspend should really be aborted here so that relevant logs can may be captured. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210707141647.8871-1-mario.limonciello@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add new acpi id for future PMC controllersShyam Sundar S K2021-07-141-0/+4
| | | | | | | | | | The upcoming PMC controller would have a newer acpi id, add that to the supported acpid device list. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-8-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add support for ACPI ID AMDI0006Shyam Sundar S K2021-07-141-0/+1
| | | | | | | | | | Some newer BIOSes have added another ACPI ID for the uPEP device. SMU statistics behave identically on this device. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-7-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add support for logging s0ix countersShyam Sundar S K2021-07-141-1/+44
| | | | | | | | | | | | | | | | | | Even the FCH SSC registers provides certain level of information about the s0ix entry and exit times which comes handy when the SMU fails to report the statistics via the mailbox communication. This information is captured via a new debugfs file "s0ix_stats". A non-zero entry in this counters would mean that the system entered the s0ix state. If s0ix entry time and exit time don't change during suspend to idle, the silicon has not entered the deepest state. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-6-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add support for logging SMU metricsShyam Sundar S K2021-07-141-8/+139
| | | | | | | | | | | | | | | | | SMU provides a way to dump the s0ix debug statistics in the form of a metrics table via a of set special mailbox commands. Add support to the driver which can send these commands to SMU and expose the information received via debugfs. The information contains the s0ix entry/exit, active time of each IP block etc. As a side note, SMU subsystem logging is not supported on Picasso based SoC's. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-5-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: call dump registers only onceShyam Sundar S K2021-07-141-4/+1
| | | | | | | | | | | Currently amd_pmc_dump_registers() routine is being called at multiple places. The best to call it is after command submission to SMU. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-4-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix SMU firmware reporting mechanismShyam Sundar S K2021-07-141-10/+0
| | | | | | | | | | | | | | It was lately understood that the current mechanism available in the driver to get SMU firmware info works only on internal SMU builds and there is a separate way to get all the SMU logging counters (addressed in the next patch). Hence remove all the smu info shown via debugfs as it is no more useful. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-3-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix command completion codeShyam Sundar S K2021-07-141-2/+36
| | | | | | | | | | | | | | | | | | | | The protocol to submit a job request to SMU is to wait for AMD_PMC_REGISTER_RESPONSE to return 1,meaning SMU is ready to take requests. PMC driver has to make sure that the response code is always AMD_PMC_RESULT_OK before making any command submissions. When we submit a message to SMU, we have to wait until it processes the request. Adding a read_poll_timeout() check as this was missing in the existing code. Also, add a mutex to protect amd_pmc_send_cmd() calls to SMU. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Acked-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210629084803.248498-2-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: put device on error pathsPan Bian2021-02-021-3/+11
| | | | | | | | | | Put the PCI device rdev on error paths to fix potential reference count leaks. Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210121045005.73342-1-bianpan2016@163.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Fix CONFIG_DEBUG_FS checkShyam Sundar S K2021-01-041-1/+1
| | | | | | | | | | | lkp reported that CONFIG_DEBUG_FS was not defined because of wrong usage if macro, correcting it now. Fixes: 156ec4731cb2 ("platform/x86: amd-pmc: Add AMD platform support for S2Idle") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20201230081028.2615217-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* platform/x86: amd-pmc: Add AMD platform support for S2IdleShyam Sundar S K2020-11-091-0/+286
AMD Power Management Controller driver a.k.a. amd-pmc driver is the controller which is meant for the final S2Idle transaction that goes to the PMFW running on the AMD SMU (System Management Unit) responsible for tuning of the VDD. Once all the monitored list or the idle constraints are met, this driver would go and set the OS_HINT (meaning all the devices have reached to their lowest state possible) via the SMU mailboxes. This driver would also provide some debug capabilities via debugfs. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20201105140531.2955555-1-Shyam-sundar.S-k@amd.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-25 05:17:58 +0000