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>
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: b0c07116c8 ("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>
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>
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>
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: 8d89835b04 ("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>
commit 59348401eb ("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 8d89835b04 ("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: 8d89835b04 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Fixes: 23f62d7ab2 ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions")
Fixes: 59348401eb ("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>
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>
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>
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>
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: f6045de1f5 ("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>
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 055162645a ("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>
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: b9a4fa6978 ("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>
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>
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>
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: 156ec4731c ("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>
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: 156ec4731c ("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>
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>
