The idle mask is dumped during the "prepare" and "restore" stage
right now, which helps to demonstrate issues only related to the
first s2idle entry.

If the system has entered s2idle once, but was woken up never
breaking the s2idle loop but also never went back to sleep we
might still have another issue to deal with however.

Move the dynamic debugging message here so that we'll catch it on
each iteration.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216516Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220929215042.745-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Since linux/debugfs.h already has the stubs for the used debugfs
functions when debugfs is not enabled, remove the #ifdef CONFIG_DEBUG_FS
checks.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220922175608.630046-1-Shyam-sundar.S-k@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Without CONFIG_DEBUG_FS, the following build error occurs:

  drivers/platform/x86/amd/pmc.c:984:17: error: use of undeclared identifier 'pmc_groups'; did you mean 'set_groups'?
                  .dev_groups = pmc_groups,
                                ^~~~~~~~~~
                                set_groups
  ./include/linux/cred.h:65:13: note: 'set_groups' declared here
  extern void set_groups(struct cred *, struct group_info *);
              ^
  drivers/platform/x86/amd/pmc.c:984:17: error: incompatible pointer types initializing 'const struct attribute_group **' with an expression of type 'void (struct cred *, struct group_info *)' [-Werror,-Wincompatible-pointer-types]
                  .dev_groups = pmc_groups,
                                ^~~~~~~~~~
  2 errors generated.

pmc_groups was only defined inside a CONFIG_DEBUG_FS block but
commit 7f1ea75d ("platform/x86/amd: pmc: Add sysfs files for SMU")
intended for these sysfs files to be available outside of debugfs.
Shuffle the necessary functions out of the CONFIG_DEBUG_FS block so that
the file always builds.

Fixes: 7f1ea75d ("platform/x86/amd: pmc: Add sysfs files for SMU")
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220922153100.324922-1-nathan@kernel.orgReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The CPU/APU SMU FW version and program is currently discoverable by
turning on dynamic debugging or examining debugfs for the amdgpu
driver. To make this more discoverable, create a dedicated sysfs
file for it that userspace can parse without debugging enabled.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220914141850.259-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The `check` callback is run right before the cores are put into HLT.
This will allow checking synchronization problems with other software
that writes into the STB.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-5-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The kernel parameter `enable_stb` currently gates the access to the STB
from debugfs and also controls whether the kernel writes events to the
STB.

Even if not accessing STB data from the kernel it's useful to have this
data stored to review the STB. So in suspend/resume always write it.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-4-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently `amd-pmc` has two events, but just adds one to the first to
distinguish the second.  Add a clear definition what these events mean.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220829162953.5947-3-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

PMC driver can be supported on a new upcoming platform.
Add this information to the support list.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220630050324.3780654-2-Shyam-sundar.S-k@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

New version of PMC controller will have a separate ACPI id, add that
to the support list.
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220630050324.3780654-1-Shyam-sundar.S-k@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Currently, AMD supported platform drivers are grouped under generic "x86"
folder structure. Move the current drivers (amd-pmc and amd_hsmp) to a
separate directory. This would also mean the newer driver submissions to
pdx86 subsystem in the future will also land in AMD specific directory.
Reviewed-by: NNaveen Krishna Chatradhi <NaveenKrishna.Chatradhi@amd.com>
Tested-by: NSuma Hegde <suma.hegde@amd.com>
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20220608193212.2827257-1-Shyam-sundar.S-k@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NRen Zhijie <renzhijie2@huawei.com>
Link: https://lore.kernel.org/r/20220505121958.138905-1-renzhijie2@huawei.comSigned-off-by: NHans 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: b0c07116 ("platform/x86: amd-pmc: Avoid reading SMU version at probe time")
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220418213800.21257-1-nathan@kernel.orgSigned-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220411143820.13971-3-mario.limonciello@amd.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220411143820.13971-2-mario.limonciello@amd.comSigned-off-by: NHans 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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220411143820.13971-1-mario.limonciello@amd.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

Since commit b1f66033 ("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 b1f66033 ("platform/x86: amd-pmc: Move to later in the suspend process")
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220402231122.3877-1-mario.limonciello@amd.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220317190301.6818-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans 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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220317141445.6498-4-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220317141445.6498-3-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans 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: 8d89835b ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220317141445.6498-2-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220310150920.560583-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The "size" variable can be uninitialized if amd_pmc_send_cmd() fails.

Fixes: 3d7d407d ("platform/x86: amd-pmc: Add support for AMD Spill to DRAM STB feature")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220307141832.GA19660@kiliSigned-off-by: NHans de Goede <hdegoede@redhat.com>

commit 59348401 ("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 8d89835b ("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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/linux-acpi/BL1PR12MB51570F5BD05980A0DCA1F3F4E23A9@BL1PR12MB5157.namprd12.prod.outlook.com/T/#mee35f39c41a04b624700ab2621c795367f19c90e
Fixes: 8d89835b ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Fixes: 23f62d7a ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions")
Fixes: 59348401 ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup")
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

commit 59348401 ("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 8d89835b ("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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/linux-acpi/BL1PR12MB51570F5BD05980A0DCA1F3F4E23A9@BL1PR12MB5157.namprd12.prod.outlook.com/T/#mee35f39c41a04b624700ab2621c795367f19c90e
Fixes: 8d89835b ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
Fixes: 23f62d7a ("PM: sleep: Pause cpuidle later and resume it earlier during system transitions")
Fixes: 59348401 ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup"
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220223175237.6209-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220204122527.3873552-1-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20220120174439.12770-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: Nkernel test robot <lkp@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220117112644.260168-1-hdegoede@redhat.com

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211210143529.10594-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211210143529.10594-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans 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: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Link: https://lore.kernel.org/r/20211130112318.92850-3-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com>
Link: https://lore.kernel.org/r/20211130112318.92850-2-Sanket.Goswami@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans 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: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NFabrizio Bertocci <fabriziobertocci@gmail.com>
Link: https://lore.kernel.org/r/CADtzkx7TdfbwtaVEXUdD6YXPey52E-nZVQNs+Z41DTx7gqMqtw@mail.gmail.comSigned-off-by: NHans 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: NShyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: NFabrizio Bertocci <fabriziobertocci@gmail.com>
Link: https://lore.kernel.org/r/CADtzkx7TdfbwtaVEXUdD6YXPey52E-nZVQNs+Z41DTx7gqMqtw@mail.gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>

This is already checked when calling rtc_read_alarm.
Suggested-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-3-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-2-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NHans de Goede <hdegoede@redhat.com>
Fixes: 59348401 ("platform/x86: amd-pmc: Add special handling for timer based S0i3 wakeup")
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211026171443.289-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans 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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211020162946.10537-2-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211020162946.10537-1-mario.limonciello@amd.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

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: NSachi King <nakato@nakato.io>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.ioSigned-off-by: NHans de Goede <hdegoede@redhat.com>

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: NSachi King <nakato@nakato.io>
Reviewed-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20211002041840.2058647-1-nakato@nakato.ioSigned-off-by: NHans de Goede <hdegoede@redhat.com>