: Alex Deucher
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* No changes
v4:
* Add A-b tag for Alex
*
https://lore.kernel.org/linux-pci/20250616175019.3471583-1-supe...@kernel.org/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers
On 9/10/25 10:18 AM, Bjorn Helgaas wrote:
On Tue, Sep 09, 2025 at 02:16:18PM -0500, Mario Limonciello (AMD) wrote:
When the system is powered off the kernel will call device_shutdown()
which will issue callbacks into PCI core to wake up a device and call
it's shutdown() callback. This
On 9/18/2025 1:05 PM, Lizhi Hou wrote:
On 9/18/25 10:43, Mario Limonciello wrote:
On 9/18/2025 12:41 PM, Lizhi Hou wrote:
On 9/18/25 10:31, Mario Limonciello wrote:
On 9/18/2025 12:24 PM, Lizhi Hou wrote:
Currently, pm_runtime_resume_and_get() is invoked in the driver's
On 9/18/2025 12:41 PM, Lizhi Hou wrote:
On 9/18/25 10:31, Mario Limonciello wrote:
On 9/18/2025 12:24 PM, Lizhi Hou wrote:
Currently, pm_runtime_resume_and_get() is invoked in the driver's open
callback, and pm_runtime_put_autosuspend() is called in the close
callback. As a result
On 9/18/2025 12:24 PM, Lizhi Hou wrote:
Currently, pm_runtime_resume_and_get() is invoked in the driver's open
callback, and pm_runtime_put_autosuspend() is called in the close
callback. As a result, the device remains active whenever an application
opens it, even if no I/O is performed, leadi
On 9/8/2025 4:34 PM, Bjorn Helgaas wrote:
In subject, s|PCI: PM:|PCI/PM:| to follow previous practice.
👍
On Sun, Aug 17, 2025 at 09:00:55PM -0500, Mario Limonciello (AMD) wrote:
PCI devices can be programmed as a wakeup source from low power states
by sysfs. However when using the S4
— unless bus-level power management is
skipped — will transition the bridge into D3hot or D3cold as appropriate.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v7:
* reword commit text
v6
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No intended functional changes.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v7:
* Reword title
v5
o debug a shutdown hang
* Adjust commit messages per feedback from Bjorn
Mario Limonciello (AMD) (12):
PM: Introduce new PMSG_POWEROFF event
scsi: Add PM_EVENT_POWEROFF into suspend callbacks
usb: sl811-hcd: Add PM_EVENT_POWEROFF into suspend callbacks
USB: Pass PMSG_POWEROFF event to susp
c: Kai-Heng Feng
Cc: Mark Pearson
Cc: Merthan Karakaş
Tested-by: Eric Naim
Tested-by: Denis Benato
Link:
https://lore.kernel.org/linux-pci/20231213182656.6165-1-mario.limoncie...@amd.com/
Link:
https://lore.kernel.org/linux-pci/20250506041934.1409302-1-supe...@kernel.org/
Signed-off-by: Mario Limo
On 9/10/25 9:46 AM, Bjorn Helgaas wrote:
On Tue, Sep 09, 2025 at 02:16:13PM -0500, Mario Limonciello (AMD) wrote:
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No
On 9/8/2025 4:50 PM, Bjorn Helgaas wrote:
On Sun, Aug 17, 2025 at 09:00:59PM -0500, Mario Limonciello (AMD) wrote:
For the suspend flow PCIe bridges that have downstream devices are put into
the appropriate low power state (D3hot or D3cold depending upon specific
devices). For the hibernate
press
or a Remote Start."
This implies that wakeups from PCI devices should not be relied upon
in these states. To align with this expectation and avoid unintended
wakeups, disable device wakeup capability during these transitions.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AM
If powering off the system USB wakeup sources should be ignored.
Add a new callback hcd_pci_poweroff() which will differentiate whether
target state is halt or power off and pass PMSG_POWEROFF as the
message so that suspend_common() will avoid doing wakeups.
Signed-off-by: Mario Limonciello (AMD
On 9/10/25 12:11 PM, Bjorn Helgaas wrote:
On Wed, Sep 10, 2025 at 11:52:00AM -0500, Mario Limonciello wrote:
On 9/10/25 10:06 AM, Bjorn Helgaas wrote:
On Tue, Sep 09, 2025 at 02:16:12PM -0500, Mario Limonciello (AMD) wrote:
PCI devices can be configured as wakeup sources from low power states
On 9/10/25 8:58 AM, Rafael J. Wysocki wrote:
On Tue, Sep 9, 2025 at 9:16 PM Mario Limonciello (AMD)
wrote:
PMSG_POWEROFF will be used for the PM core to allow differentiating between
a hibernation or shutdown sequence when re-using callbacks.
This event should not have wakeups enabled
Why
On 9/10/25 1:11 PM, Rafael J. Wysocki wrote:
Hi Mario,
On Tue, Sep 9, 2025 at 9:16 PM Mario Limonciello (AMD)
wrote:
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered off
On 9/10/25 10:06 AM, Bjorn Helgaas wrote:
On Tue, Sep 09, 2025 at 02:16:12PM -0500, Mario Limonciello (AMD) wrote:
PCI devices can be configured as wakeup sources from low power states.
However, when the system is halting or powering off such wakeups are
not expected and may lead to spurious
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
* Add tags
v4:
*
https://lore.kernel.org
On 9/8/25 4:19 AM, Greg Kroah-Hartman wrote:
On Sat, Sep 06, 2025 at 09:36:31AM -0500, Mario Limonciello (AMD) wrote:
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered off
Devices with no subordinate should be put into D3 during hibernate, but
devices that have bridge_d3 set should also be put to sleep during
hibernate. Adjust the check in pci_pm_poweroff_noirq() to use
pci_power_manageable() to cover those as well.
Tested-by: Eric Naim
Signed-off-by: Mario
PMSG_POWEROFF will be used for the PM core to allow differentiating between
a hibernation or shutdown sequence when re-using callbacks.
This event should not have wakeups enabled so update PMSG_NO_WAKEUP() to
match it as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v7
works.
Signed-off-by: Mario Limonciello (AMD)
---
v7:
* New patch
---
Documentation/power/index.rst | 1 +
Documentation/power/shutdown-debugging.rst | 55 ++
2 files changed, 56 insertions(+)
create mode 100644 Documentation/power/shutdown-debugging.rst
diff
Suspend resume actions will check the state of the device and whether
bus PM should be skipped. These same actions make sense during hibernation
image restore. Apply them there as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v7:
* Reword title
v5:
* Split out patch
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
v4:
*
https://lore.kernel.org/linux-pci
: Alex Deucher
Signed-off-by: Mario Limonciello (AMD)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 01d234cf81564..9b7f9e9c06404 100644
--- a
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No intended functional changes.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers/pci/pci-driver.c
Suspend resume actions will check the state of the device and whether
bus PM should be skipped. These same actions make sense during hibernation
image restore. Apply them there as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers/pci/pci-driver.c | 5 +
1 file
PMSG_POWEROFF will be used for the PM core to allow differentiating between
an S4 or S5 shutdown sequence when re-using callbacks.
This event should not have wakeups enabled so update PMSG_NO_WAKEUP() to
match it as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers
c: Kai-Heng Feng
Cc: Mark Pearson
Cc: Merthan Karakaş
Tested-by: Eric Naim
Tested-by: Denis Benato
Link:
https://lore.kernel.org/linux-pci/20231213182656.6165-1-mario.limoncie...@amd.com/
Link:
https://lore.kernel.org/linux-pci/20250506041934.1409302-1-supe...@kernel.org/
Signed-off-by: Mario Lim
If powering off the system with the S4 flow USB wakeup sources should
be ignored. Add a new callback hcd_pci_poweroff() which will differentiate
whether target state is S5 and pass PMSG_POWEROFF as the message so that
suspend_common() will avoid doing wakeups.
Signed-off-by: Mario Limonciello
Karakaş
Cc: Eric Naim
---
v6 RESEND:
* Resent because Greg said he was ignoring it and would like the whole
series to be able to review.
v5->v6:
* Fix for LKP robot issue
* Some commit message changes
* Rebase on 6.17-rc2
Mario Limonciello (AMD) (11):
PM: Introduce new PMSG_POWEROFF ev
device into an unknown state.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers/pci/pci-driver.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a
PCI devices can be programmed as a wakeup source from low power states
by sysfs. However when using the S4 flow to go into S5 these wakeup
sources should be disabled to avoid what users would perceive as
spurious wakeup events.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers/usb/host/sl811-hcd.c | 1 +
1 file changed, 1
Devices with no subordinate should be put into D3 during hibernate, but
devices that have bridge_d3 set should also be put to sleep during
hibernate. Adjust the check in pci_pm_poweroff_noirq() to use
pci_power_manageable() to cover those as well.
Tested-by: Eric Naim
Signed-off-by: Mario
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
drivers/scsi/mesh.c | 1 +
drivers/scsi/stex.c | 1 +
2
On 8/11/2025 11:26 AM, Mario Limonciello (AMD) wrote:
Systems with more than one GPU userspace doesn't know which one to be
used to treat as primary. The concept of primary is important to be
able to decide which GPU is used for display and which is used for
rendering. If it's gue
On 9/3/25 10:03 AM, Deucher, Alexander wrote:
[Public]
-Original Message-
From: Mario Limonciello
Sent: Wednesday, September 3, 2025 12:53 AM
To: Antheas Kapenekakis ; amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
ph...@manjaro.org
On 8/17/2025 9:00 PM, Mario Limonciello (AMD) wrote:
A variety of issues both in function and in power consumption have been
raised as a result of devices not being put into a low power state when
the system is powered off.
There have been some localized changes[1] to PCI core to help these
applied.
Suggested-by: Mario Limonciello
Signed-off-by: Antheas Kapenekakis
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display
On 8/11/2025 11:26 AM, Mario Limonciello (AMD) wrote:
Systems with more than one GPU userspace doesn't know which one to be
used to treat as primary. The concept of primary is important to be
able to decide which GPU is used for display and which is used for
rendering. If it's gue
,
Revision A1 Processors
https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip
-.. [4] Linux Kernel Selftests,
- https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
+.. [4] Documentation/dev-tools/kselftest.rst
Acked-by: Mario Limonciello (AMD)
type. After the ioctl completes, the
actual number of entries and entry size are returned.
Signed-off-by: Lizhi Hou
Link: https://lore.kernel.org/r/20250827203031.1512508-1-lizhi@amd.com
Reviewed-by: Mario Limonciello (AMD)
One nit below, if no other feedback feel free to just incorporate
ommit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
The series looks fine to me.
Reviewed-by: Mario Limonciello
I have two small nits though:
1) Because this is "effectively" going to limit the amount of brightness
values available I think there should be a message when a the brightness
mask quirk is
On 8/27/2025 11:41 AM, Lizhi Hou wrote:
On 8/26/25 17:31, Mario Limonciello wrote:
On 8/26/2025 1:10 PM, Lizhi Hou wrote:
On 8/26/25 10:58, Mario Limonciello wrote:
On 8/26/2025 12:55 PM, Lizhi Hou wrote:
On 8/26/25 10:18, Mario Limonciello wrote:
On 8/25/2025 11:48 PM, Lizhi Hou wrote
On 8/26/2025 1:10 PM, Lizhi Hou wrote:
On 8/26/25 10:58, Mario Limonciello wrote:
On 8/26/2025 12:55 PM, Lizhi Hou wrote:
On 8/26/25 10:18, Mario Limonciello wrote:
On 8/25/2025 11:48 PM, Lizhi Hou wrote:
On 8/25/25 14:28, Mario Limonciello wrote:
On 8/22/2025 12:23 PM, Lizhi Hou wrote
On 8/26/2025 8:41 AM, Alex Deucher wrote:
On Tue, Aug 26, 2025 at 3:49 AM Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 03:38, Mario Limonciello wrote:
On 8/24/25 3:46 PM, Antheas Kapenekakis wrote:
On Sun, 24 Aug 2025 at 22:16, Mario Limonciello wrote:
On 8/24/25 3:53 AM
On 8/26/2025 11:03 AM, Lizhi Hou wrote:
drivers/accel/amdxdna/aie2_pci.c:794:13: sparse: sparse: incorrect type in
assignment (different address spaces)
Fixes: c8cea4371e5e ("accel/amdxdna: Add a function to walk hardware contexts")
Reported-by: kernel test robot
Closes:
https://lore.kernel.o
On 8/26/2025 12:55 PM, Lizhi Hou wrote:
On 8/26/25 10:18, Mario Limonciello wrote:
On 8/25/2025 11:48 PM, Lizhi Hou wrote:
On 8/25/25 14:28, Mario Limonciello wrote:
On 8/22/2025 12:23 PM, Lizhi Hou wrote:
Add interface for applications to get information array. The
application
provides a
es:
https://lore.kernel.org/oe-kbuild-all/202508230855.0b9effl6-...@intel.com/
Signed-off-by: Lizhi Hou
Reviewed-by: Mario Limonciello
---
drivers/accel/amdxdna/aie2_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/accel/amdxdna/aie2_pci.c b/drivers/accel/amdxdna/aie2_p
On 8/25/2025 11:48 PM, Lizhi Hou wrote:
On 8/25/25 14:28, Mario Limonciello wrote:
On 8/22/2025 12:23 PM, Lizhi Hou wrote:
Add interface for applications to get information array. The application
provides a buffer pointer along with information type, maximum number of
entries and maximum size
On 8/22/2025 12:23 PM, Lizhi Hou wrote:
Add interface for applications to get information array. The application
provides a buffer pointer along with information type, maximum number of
entries and maximum size of each entry. The buffer may also contain match
conditions based on the information t
On 8/25/2025 4:17 PM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 20:02, Mario Limonciello
wrote:
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first
On 8/25/2025 4:02 PM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 18:47, Mario Limonciello
wrote:
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
Certain OLED devices malfunction on specific brightness levels.
Specifically, when DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again.
Below are som
On 8/24/2025 3:01 PM, Antheas Kapenekakis wrote:
Currently, the brightness quirk is limited to minimum brightness only.
Refactor it to a structure, so that more quirks can be added in the
future. Reserve 0 value for "no quirk", and use u16 to allow minimum
brightness up to 255.
Signed-off-by: An
On 8/24/2025 3:02 PM, Antheas Kapenekakis wrote:
On the SteamOS kernel, Valve universally makes minimum brightness 0
for all devices. SteamOS is (was?) meant for the Steam Deck, so
enabling it universally is reasonable. However, it causes issues in
certain devices. Therefore, introduce it just fo
On 8/24/2025 3:01 PM, Antheas Kapenekakis wrote:
This is an alternative to [1], since Phil found out there are still invalid
values. I made this series before the one I sent today, and I have to say
I tested it much less. Because I did not think it was very viable to
upstream.
I'll look throug
On 8/25/2025 9:01 AM, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 15:33, Antheas Kapenekakis wrote:
On Mon, 25 Aug 2025 at 15:20, Alex Deucher wrote:
On Mon, Aug 25, 2025 at 3:13 AM Antheas Kapenekakis wrote:
On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
On 8/24/25 3:46 PM, Antheas Kapenekakis wrote:
On Sun, 24 Aug 2025 at 22:16, Mario Limonciello wrote:
On 8/24/25 3:53 AM, Antheas Kapenekakis wrote:
On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
suspend resumes result in a soft lock around 1 second after the
On 8/24/25 3:53 AM, Antheas Kapenekakis wrote:
On the Asus Z13 2025, which uses a Strix Halo platform, around 8% of the
suspend resumes result in a soft lock around 1 second after the screen
turns on (it freezes). This happens due to power gating VPE when it is
not used, which happens 1 second
On 8/18/25 5:50 AM, Oliver Neukum wrote:
On 8/18/25 04:00, Mario Limonciello (AMD) wrote:
If powering off the system with the S4 flow USB wakeup sources should
be ignored. Add a new callback hcd_pci_poweroff() which will
differentiate
whether target state is S5 and pass PMSG_POWEROFF as the
c: Kai-Heng Feng
Cc: Mark Pearson
Cc: Merthan Karakaş
Tested-by: Eric Naim
Tested-by: Denis Benato
Link:
https://lore.kernel.org/linux-pci/20231213182656.6165-1-mario.limoncie...@amd.com/
Link:
https://lore.kernel.org/linux-pci/20250506041934.1409302-1-supe...@kernel.org/
Signed-off-by: Mario Limo
: Alex Deucher
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* No changes
v4:
* Add A-b tag for Alex
*
https://lore.kernel.org/linux-pci/20250616175019.3471583-1-supe...@kernel.org/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers
device into an unknown state.
Cc: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v6:
* s/port/bridge/
v5:
* Split out into more patches
* Rewrite commit
* Add tag
v4:
* Use helper even
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No intended functional changes.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split from earlier
Devices with no subordinate should be put into D3 during hibernate, but
devices that have bridge_d3 set should also be put to sleep during
hibernate. Adjust the check in pci_pm_poweroff_noirq() to use
pci_power_manageable() to cover those as well.
Tested-by: Eric Naim
Signed-off-by: Mario
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
v4:
*
https://lore.kernel.org/linux-pci
Suspend resume actions will check the state of the device and whether
bus PM should be skipped. These same actions make sense during hibernation
image restore. Apply them there as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split out patch
---
drivers/pci/pci
If powering off the system with the S4 flow USB wakeup sources should
be ignored. Add a new callback hcd_pci_poweroff() which will differentiate
whether target state is S5 and pass PMSG_POWEROFF as the message so that
suspend_common() will avoid doing wakeups.
Signed-off-by: Mario Limonciello
PCI devices can be programmed as a wakeup source from low power states
by sysfs. However when using the S4 flow to go into S5 these wakeup
sources should be disabled to avoid what users would perceive as
spurious wakeup events.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
* Add tags
v4:
*
https://lore.kernel.org
PMSG_POWEROFF will be used for the PM core to allow differentiating between
an S4 or S5 shutdown sequence when re-using callbacks.
This event should not have wakeups enabled so update PMSG_NO_WAKEUP() to
match it as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5
Karakaş
Cc: Eric Naim
---
v5->v6:
* Fix for LKP robot issue
* Some commit message changes
* Rebase on 6.17-rc2
Mario Limonciello (AMD) (11):
PM: Introduce new PMSG_POWEROFF event
scsi: Add PM_EVENT_POWEROFF into suspend callbacks
usb: sl811-hcd: Add PM_EVENT_POWEROFF into suspend callba
: Alex Deucher
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* No changes
v4:
* Add A-b tag for Alex
*
https://lore.kernel.org/linux-pci/20250616175019.3471583-1-supe...@kernel.org/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers
: AceLan Kao
Cc: Kai-Heng Feng
Cc: Mark Pearson
Cc: Denis Benato
Cc: Merthan Karakaş
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split out into more patches
* Rewrite commit
* Add tag
v4:
* Use helper even when CONFIG_SUSPEND not set (LKP robot)
*
https
c: Kai-Heng Feng
Cc: Mark Pearson
Cc: Merthan Karakaş
Tested-by: Eric Naim
Tested-by: Denis Benato
Link:
https://lore.kernel.org/linux-pci/20231213182656.6165-1-mario.limoncie...@amd.com/
Link:
https://lore.kernel.org/linux-pci/20250506041934.1409302-1-supe...@kernel.org/
Signed-off-by: Mario Limo
Suspend resume actions will check the state of the device and whether
bus PM should be skipped. These same actions make sense during hibernation
image restore. Apply them there as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split out patch
---
drivers/pci/pci
Devices with no subordinate should be put into D3 during hibernate, but
devices that have bridge_d3 set should also be put to sleep during
hibernate. Adjust the check in pci_pm_poweroff_noirq() to use
pci_power_manageable() to cover those as well.
Tested-by: Eric Naim
Signed-off-by: Mario
In order to unify suspend and hibernate codepaths without code duplication
the common code should be in common helpers. Move it from
pci_pm_suspend_noirq() into a helper. No intended functional changes.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Split from earlier
PCI devices can be programmed as a wakeup source from low power states
by sysfs. However when using the S4 flow to go into S5 these wakeup
sources should be disabled to avoid what users would perceive as
spurious wakeup events.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5
If powering off the system with the S4 flow USB wakeup sources should
be ignored. Add a new callback hcd_pci_poweroff() which will differentiate
whether target state is S5 and pass PMSG_POWEROFF as the message so that
suspend_common() will avoid doing wakeups.
Signed-off-by: Mario Limonciello
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
* Add tags
v4:
*
https://lore.kernel.org
When the ACPI core uses hibernation callbacks for shutdown drivers
will receive PM_EVENT_POWEROFF and should handle it the same as
PM_EVENT_HIBERNATE would have been used.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5:
* Re-order
v4:
*
https://lore.kernel.org/linux-pci
Karakaş
Cc: Eric Naim
---
v4->v5:
* Rebase on v6.17-rc1
* Re-order series to be more bisectable for issues
* Add tags where relevant
* Split up PCI patches into more easily reviewable "chunks".
Mario Limonciello (AMD) (11):
PM: Introduce new PMSG_POWEROFF event
scsi: Add PM_EVENT_
PMSG_POWEROFF will be used for the PM core to allow differentiating between
an S4 or S5 shutdown sequence when re-using callbacks.
This event should not have wakeups enabled so update PMSG_NO_WAKEUP() to
match it as well.
Tested-by: Eric Naim
Signed-off-by: Mario Limonciello (AMD)
---
v5
rmann
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello (AMD)
---
v10:
* Rebase on 6.17-rc1
* Squash 'fbcon: Stop using screen_info_pci_dev()'
---
arch/x86/video/video-common.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a
bpciaccess/-/issues/23
Signed-off-by: Mario Limonciello (AMD)
---
v10:
* Rebase on 6.17-rc1
* Drop Thomas' tag, as this is now in a totally different subsystem
(although same code)
* Squash "Adjust visibility of boot_display attribute instead of creation"
* Squash "PCI:
Signed-off-by: Mario Limonciello (AMD)
---
v10:
* Rebase on 6.17-rc1
---
drivers/pci/vgaarb.c | 31 +--
1 file changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index 78748e8d2dbae..b58f94ee48916 100644
--- a/drivers/pci
CONFIG_VIDEO.
Acked-by: Thomas Zimmermann
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202506221312.49fy1ana-...@intel.com/
Signed-off-by: Mario Limonciello (AMD)
---
v10:
* Rebase on 6.17-rc1
v5:
* add tag
v4:
* new patch
---
arch/parisc/include/asm/video.h | 2
symbols are in 6.17-rc1 this can merge through
drm-misc-next.
Link:
https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/37#note_2938602
[1]
---
v10:
* Add patches that didn't merge to v6.17-rc1 in
* Move sysfs file to drm ownership
Mario Limonciello (AMD) (4):
Fix ac
On 8/8/25 6:47 AM, Christian Zigotzky wrote:
On 08 August 2025 um 01:23 pm, Mario Limonciello wrote:
On 8/8/25 2:36 AM, Christian Zigotzky wrote:
On 07 August 2025 at 04:21 pm, Limonciello, Mario
wrote:
Does applying
https://github.com/torvalds/linux/commit
On 8/8/25 2:36 AM, Christian Zigotzky wrote:
On 07 August 2025 at 04:21 pm, Limonciello, Mario
wrote:
Does applying
https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
help?
- - -
Hello Mario,
Thanks a lot for your patch.
I tested it today but unfortunatel
transmission mistake, sorry if this is recieved twice by
anyone.)
Reviewed-by: Mario Limonciello (AMD)
---
drivers/accel/amdxdna/aie2_ctx.c| 59 ++--
drivers/accel/amdxdna/aie2_pci.c| 37 +++--
drivers/accel/amdxdna/aie2_pci.h| 5 +-
drivers
On 8/3/25 2:14 PM, Lizhi Hou wrote:
The suspend and resume callbacks for pm and runtime pm should be same.
During suspending, it needs to stop all hardware contexts first. And
the hardware contexts will be restarted after the device is resumed.
Signed-off-by: Lizhi Hou
Reviewed-by: Mario
On 7/31/2025 10:05 PM, Lizhi Hou wrote:
The suspend and resume callbacks for pm and runtime pm should be same.
During suspending, it needs to stop all hardware contexts first. And
the hardware contexts will be restarted after the device is resumed.
Signed-off-by: Lizhi Hou
---
drivers/accel/a
On 7/31/25 10:37 AM, Linus Torvalds wrote:
On Wed, 30 Jul 2025 at 21:58, Linus Torvalds
wrote:
d7b618bc41ee3d44c070212dff93949702ede997 is the first bad commit
drm/amd/display: Refactor DSC cap calculations
Let me go see how painful it is to just revert it from top-of-tree.
So with
On 7/24/2025 1:36 PM, Bjorn Helgaas wrote:
On Thu, Jul 17, 2025 at 03:56:58PM -0500, Bjorn Helgaas wrote:
On Thu, Jul 17, 2025 at 12:38:03PM -0500, Mario Limonciello wrote:
From: Mario Limonciello
Systems with more than one GPU userspace doesn't know which one to be
used to treat as pr
On 7/22/25 10:33 AM, Bjorn Helgaas wrote:
On Tue, Jul 22, 2025 at 09:45:28AM -0500, Mario Limonciello wrote:
On 7/22/25 9:38 AM, Bjorn Helgaas wrote:
On Thu, Jul 17, 2025 at 12:38:11PM -0500, Mario Limonciello wrote:
From: Mario Limonciello
On systems with non VGA GPUs fbcon can't fin
1 - 100 of 781 matches
Mail list logo
