With virtio-mem, primarily hibernation is problematic: as the machine shuts
down, the virtio-mem device loses its state. Powering the machine back up
is like losing a bunch of DIMMs. While there would be ways to add limited
support, suspend+resume is more commonly used for VMs and "e
On 2/13/2024 9:58 AM, Eugenio Perez Martin wrote:
> On Tue, Feb 13, 2024 at 3:26 PM Steve Sistare
> wrote:
>>
>> If a vdpa device is not in state DRIVER_OK, then there is no driver state
>> to preserve, so no need to call the suspend and resume driver ops.
>>
>> Suggested-by: Eugenio Perez
On Tue, Feb 13, 2024 at 3:26 PM Steve Sistare wrote:
>
> If a vdpa device is not in state DRIVER_OK, then there is no driver state
> to preserve, so no need to call the suspend and resume driver ops.
>
> Suggested-by: Eugenio Perez Martin "
> Signed-off-by: Steve Sistare
Reviewed-by: Eugenio
If a vdpa device is not in state DRIVER_OK, then there is no driver state
to preserve, so no need to call the suspend and resume driver ops.
Suggested-by: Eugenio Perez Martin "
Signed-off-by: Steve Sistare
---
drivers/vhost/vdpa.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Reviewed-by: Gal Pressman
On Wed, Dec 20, 2023 at 2:10 AM Dragos Tatulea wrote:
>
> Instead of tearing down and setting up vq resources, use vq
> suspend/resume during .set_map to speed things up a bit.
>
> The vq mr is updated with the new mapping while the vqs are suspended.
>
> If the device does
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Reviewed-by: Gal Pressman
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Reviewed-by: Gal Pressman
On Tue, Dec 5, 2023 at 11:47 AM Dragos Tatulea wrote:
>
> Instead of tearing down and setting up vq resources, use vq
> suspend/resume during .set_map to speed things up a bit.
>
> The vq mr is updated with the new mapping while the vqs are suspended.
>
> If the device does
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Signed-off-by: Dragos
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Signed-off-by: Dragos
I'm experiencing a regression with regard
> >> to USB ports behaviour after a suspend/resume cycle.
> >>
> >> If a USB port is empty before suspending, after resuming the machine
> >> the port doesn't work. After a device insertion there's no reaction in
> >
+Cc workflows
On 11/24/23 12:43, Greg Kroah-Hartman wrote:
> On Thu, Nov 23, 2023 at 07:20:46PM +0100, Oleksandr Natalenko wrote:
>> Hello.
>>
>> Since v6.6.2 kernel release I'm experiencing a regression with regard
>> to USB ports behaviour after a suspend/resume
Hi Guenter,
On 2021-03-11 01:53, Guenter Roeck wrote:
On Thu, Mar 11, 2021 at 01:50:04AM +0530, Sai Prakash Ranjan wrote:
During suspend/resume usecases and tests, it is common to see issues
such as lockups either in suspend path or resume path because of the
bugs in the corresponding device
From: Yongxin Liu
commit debb9df311582c83fe369baa35fa4b92e8a9c58a upstream.
pci_disable_device() called in __ixgbe_shutdown() decreases
dev->enable_cnt by 1. pci_enable_device_mem() which increases
dev->enable_cnt by 1, was removed from ixgbe_resume() in commit
6f82b2558735 ("ixgbe: use generic
From: Yongxin Liu
commit debb9df311582c83fe369baa35fa4b92e8a9c58a upstream.
pci_disable_device() called in __ixgbe_shutdown() decreases
dev->enable_cnt by 1. pci_enable_device_mem() which increases
dev->enable_cnt by 1, was removed from ixgbe_resume() in commit
6f82b2558735 ("ixgbe: use generic
From: Quanyang Wang
After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.
And we
From: Quanyang Wang
After calling platform_set_drvdata(pdev, xqspi) in probe, the return
value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but
not struct spi_controller. A wrong structure type passing to the
functions spi_controller_suspend/resume will hang the system.
And we
From: Eli Cohen
commit bc04d93ea30a0a8eb2a2648b848cef35d1f6f798 upstream.
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can
From: Eli Cohen
commit bc04d93ea30a0a8eb2a2648b848cef35d1f6f798 upstream.
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can
Return error number if encounter errors during suspend and resume.
Signed-off-by: Chunfeng Yun
---
v2: no changes
---
drivers/usb/host/xhci-mtk.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c
Jesse ; intel-
>wired-...@lists.osuosl.org; k...@kernel.org
>Subject: [PATCH net] ixgbe: fix unbalanced device enable/disable in
>suspend/resume
>
>pci_disable_device() called in __ixgbe_shutdown() decreases
>dev->enable_cnt by 1. pci_enable_device_mem() which increases enable_cnt
>dev->
Hi Hilda,
> RTL8822C devices support BT wakeup Host. Add a quirk for these specific
> devices did not power off during suspend and resume.
> By this change, if the Host support that received BT device signal then
> it can be wakeup.
>
> Signed-off-by: hildawu
> ---
> Changes in v2:
> - Add
On 4/8/2021 1:45 PM, Artur Petrosyan wrote:
> Earlier "dwc2_port_suspend()" and "dwc2_port_resume()" functions
> were implemented without proper description and host or device mode
> difference.
>
> - Added "dwc2_port_suspend" and "dwc2_port_resume" functions to
>"core.h" header file.
>
> -
Earlier "dwc2_port_suspend()" and "dwc2_port_resume()" functions
were implemented without proper description and host or device mode
difference.
- Added "dwc2_port_suspend" and "dwc2_port_resume" functions to
"core.h" header file.
- Updated function description in documentation.
Return error number if encounter errors during suspend and resume.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
suspending to non backup modes. Since the clear of the
1st word in securam will be done in a subsequent commit the current commit
will not broke the current behavior since up to this moment the
suspend/resume were executed for all AT91 PM modes. The difference now
is that the suspend/resume for clocks
these clocks needs to be re-configured.
The initial PMC suspend/resume code was designed with SAMA5D2's PMC
in mind. SAMA7G's PMC is different (few new functionalities, different
registers offsets, different offsets in registers for each
functionalities). To address both SAMA5D2 and SAMA7G5 PMC add
sources and are not disabling the clocks in this
scenario, when suspending. Since backup mode cuts the power for
peripherals, in resume part these clocks needs to be re-configured.
The initial PMC suspend/resume code was designed with SAMA5D2's PMC
in mind. SAMA7G's PMC is different (few new
cting as wakeup sources and are not disabling the clocks in this
>> scenario, when suspending. Since backup mode cuts the power for
>> peripherals, in resume part these clocks needs to be re-configured.
>>
>> The initial PMC suspend/resume code was designed with SAMA5D2's PMC
>
the power for
peripherals, in resume part these clocks needs to be re-configured.
The initial PMC suspend/resume code was designed with SAMA5D2's PMC
in mind. SAMA7G's PMC is different (few new functionalities, different
registers offsets, different offsets in registers for each
functionalities
for keep power in
suspend/resume
From: hildawu
RTL8822C devices support BT wakeup Host. Add a quirk for these specific devices
did not power off during suspend and resume.
By this change, if the Host support that received BT device signal then it can
be wakeup.
Signed-off-by: hildawu
---
Changes
From: Fabio Estevam
[ Upstream commit a9748134ea4aad989e52a6a91479e0acfd306e5b ]
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
From: Fabio Estevam
[ Upstream commit a9748134ea4aad989e52a6a91479e0acfd306e5b ]
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
suspending to non backup modes. Since the clear of the
1st word in securam will be done in a subsequent commit the current commit
will not broke the current behavior since up to this moment the
suspend/resume were executed for all AT91 PM modes. The difference now
is that the suspend/resume for clocks
these clocks needs to be re-configured.
The initial PMC suspend/resume code was designed with SAMA5D2's PMC
in mind. SAMA7G's PMC is different (few new functionalities, different
registers offsets, different offsets in registers for each
functionalities). To address both SAMA5D2 and SAMA7G5 PMC add
pci_disable_device() called in __ixgbe_shutdown() decreases
dev->enable_cnt by 1. pci_enable_device_mem() which increases
dev->enable_cnt by 1, was removed from ixgbe_resume() in commit
6f82b2558735 ("ixgbe: use generic power management"). This caused
unbalanced increase/decrease. So add
On Tue, 16 Mar 2021, Srinivas Pandruvada wrote:
> From: Ye Xiang
>
> The individual sensor drivers implemented in the ISH firmware needs
> capability to take special actions when there is a change in the system
> standby state. The ISH core firmware passes this notification to
> individual
From: Ye Xiang
The individual sensor drivers implemented in the ISH firmware needs
capability to take special actions when there is a change in the system
standby state. The ISH core firmware passes this notification to
individual sensor drivers in response to the OS request via connected
From: hildawu
RTL8822C devices support BT wakeup Host. Add a quirk for these specific
devices did not power off during suspend and resume.
By this change, if the Host support that received BT device signal then
it can be wakeup.
Signed-off-by: hildawu
---
Changes in v2:
- Add missing struct
.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/hildawu-realtek-com/Bluetooth-hci_h5-btrtl-Add-quirk-for-keep-power-during-suspend-resume-for-specific-devices/20210315-170101
base:
https
From: Greg Kroah-Hartman
From: Joakim Zhang
commit c511819d138de38e1637eedb645c207e09680d0f upstream.
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer
From: Greg Kroah-Hartman
From: Joakim Zhang
commit c511819d138de38e1637eedb645c207e09680d0f upstream.
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer
From: Greg Kroah-Hartman
From: Joakim Zhang
commit c511819d138de38e1637eedb645c207e09680d0f upstream.
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer
From: Greg Kroah-Hartman
From: Joakim Zhang
commit c511819d138de38e1637eedb645c207e09680d0f upstream.
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer
From: hildawu
RTL8822C devices support BT wakeup Host. Add a quirk for these specific
devices did not power off during suspend and resume.
By this change, if the Host support that received BT device signal then
it can be wakeup.
Signed-off-by: hildawu
---
drivers/bluetooth/btrtl.c | 36
Tegra30 AHUB driver always syncs hardware state on a runtime PM resume,
hence there is no needed to re-sync the state on system resume. Replace
the suspend-resume callbacks with a generic helpers which ensure that
AHUB is suspended using RPM callbacks across system suspend-resume.
Signed-off
Add system level suspend-resume callbacks in order to ensure that I2S
is gated before system is suspended. This puts Tegra20 I2S driver on
par with the Tegra30 I2S driver.
Signed-off-by: Dmitry Osipenko
---
sound/soc/tegra/tegra20_i2s.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi,
On Wed, Mar 10, 2021 at 12:20 PM Sai Prakash Ranjan
wrote:
>
> During suspend/resume usecases and tests, it is common to see issues
> such as lockups either in suspend path or resume path because of the
> bugs in the corresponding device driver pm handling code. I
On Thu, Mar 11, 2021 at 01:50:04AM +0530, Sai Prakash Ranjan wrote:
> During suspend/resume usecases and tests, it is common to see issues
> such as lockups either in suspend path or resume path because of the
> bugs in the corresponding device driver pm handling code. In s
During suspend/resume usecases and tests, it is common to see issues
such as lockups either in suspend path or resume path because of the
bugs in the corresponding device driver pm handling code. In such cases,
it is important that watchdog is active to make sure that we either
receive a watchdog
Hi Srinivas
Thanks for the review.
On Tue, Mar 09, 2021 at 08:08:36AM -0800, Srinivas Pandruvada wrote:
> On Tue, 2021-03-09 at 11:47 +0800, Ye, Xiang wrote:
> > Hi Srinivas, Jiri
> >
> > On Mon, Mar 08, 2021 at 08:00:41AM -0800, Srinivas Pandruvada wrote:
> > > On Mon, 2021-03-08 at 11:26
On Tue, 2021-03-09 at 11:47 +0800, Ye, Xiang wrote:
> Hi Srinivas, Jiri
>
> On Mon, Mar 08, 2021 at 08:00:41AM -0800, Srinivas Pandruvada wrote:
> > On Mon, 2021-03-08 at 11:26 +0100, Jiri Kosina wrote:
> > > On Wed, 3 Mar 2021, Ye Xiang wrote:
> > >
> > > > ISH firmware uses connected standby
Hi Srinivas, Jiri
On Mon, Mar 08, 2021 at 08:00:41AM -0800, Srinivas Pandruvada wrote:
> On Mon, 2021-03-08 at 11:26 +0100, Jiri Kosina wrote:
> > On Wed, 3 Mar 2021, Ye Xiang wrote:
> >
> > > ISH firmware uses connected standby state bit
> > > (CONNECTED_STANDBY_STATE_BIT bit 1)
> > > to notify
On Mon, 2021-03-08 at 11:26 +0100, Jiri Kosina wrote:
> On Wed, 3 Mar 2021, Ye Xiang wrote:
>
> > ISH firmware uses connected standby state bit
> > (CONNECTED_STANDBY_STATE_BIT bit 1)
> > to notify current power state to sensors instead of suspend state
> > bit (bit 0).
> > So send both
On Wed, 3 Mar 2021, Ye Xiang wrote:
> ISH firmware uses connected standby state bit (CONNECTED_STANDBY_STATE_BIT
> bit 1)
> to notify current power state to sensors instead of suspend state bit (bit 0).
> So send both SUSPEND_STATE_BIT and CONNECTED_STANDBY_STATE_BIT to firmware
> to be
>
> Runtime and system suspend/resume can only come after hba probe invokes
> platform_set_drvdata(pdev, hba), meaning hba cannot be NULL in these PM
> callbacks, so remove the checks of !hba.
>
> Signed-off-by: Can Guo
Reviewed-by: Avri Altman
> ---
> driver
ISH firmware uses connected standby state bit (CONNECTED_STANDBY_STATE_BIT bit
1)
to notify current power state to sensors instead of suspend state bit (bit 0).
So send both SUSPEND_STATE_BIT and CONNECTED_STANDBY_STATE_BIT to firmware
to be compatible with the previous version.
Signed-off-by:
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 56 +++
sound/virtio/virtio_pcm.h | 3 ++
sound/virtio/virtio_pcm_ops.c | 33 -
3
ops->prepare() is called, the
substream is in SUSPENDED state or not? If not then we need to track
this in some additional field (and it will make logic a little bit
clumsy, since that field is needed to be carefully handled in other
places).
Yes, you'd need to have a suspend/resume PM callba
.
> >> I can refactor code to only send requests from trigger(RESUME) path and
> >> not to call ops itself. It should make code more straitforward. What do
> >> you say?
> >
> > How about calling hw_params(NULL) conditionally in the prepare?
>
> Then the question is
On 02.03.2021 07:48, Takashi Iwai wrote:
On Tue, 02 Mar 2021 07:29:20 +0100,
Anton Yakovlev wrote:
On 28.02.2021 13:05, Takashi Iwai wrote:
On Sat, 27 Feb 2021 09:59:56 +0100,
Anton Yakovlev wrote:
[snip]
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -109,6 +109,7
On Tue, 02 Mar 2021 07:29:20 +0100,
Anton Yakovlev wrote:
>
> On 28.02.2021 13:05, Takashi Iwai wrote:
> > On Sat, 27 Feb 2021 09:59:56 +0100,
> > Anton Yakovlev wrote:
> >>
>
> [snip]
>
> >> --- a/sound/virtio/virtio_pcm.c
> >> +++ b/sound/virtio/virtio_pcm.c
> >> @@ -109,6 +109,7 @@ static
On 28.02.2021 13:05, Takashi Iwai wrote:
On Sat, 27 Feb 2021 09:59:56 +0100,
Anton Yakovlev wrote:
[snip]
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -109,6 +109,7 @@ static int virtsnd_pcm_build_hw(struct virtio_pcm_substream
*vss,
On 01.03.2021 14:38, Takashi Iwai wrote:
On Mon, 01 Mar 2021 11:03:04 +0100,
Anton Yakovlev wrote:
On 28.02.2021 13:05, Takashi Iwai wrote:
On Sat, 27 Feb 2021 09:59:56 +0100,
Anton Yakovlev wrote:
All running PCM substreams are stopped on device suspend and restarted
on device resume.
on the
DPM list, trying to create dependencies between them, etc. I gave
up and instead added UML specific cross-driver API that lets the
virt-pci code enable not suspending/resuming VQs for its devices.
This then allows the PCI bus suspend_noirq to still talk to the
device, and suspend/resume
On Mon, 01 Mar 2021 11:03:04 +0100,
Anton Yakovlev wrote:
>
> On 28.02.2021 13:05, Takashi Iwai wrote:
> > On Sat, 27 Feb 2021 09:59:56 +0100,
> > Anton Yakovlev wrote:
> >>
> >> All running PCM substreams are stopped on device suspend and restarted
> >> on device resume.
> >>
> >> Signed-off-by:
On 28.02.2021 13:05, Takashi Iwai wrote:
On Sat, 27 Feb 2021 09:59:56 +0100,
Anton Yakovlev wrote:
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 56
On Sat, 27 Feb 2021 09:59:56 +0100,
Anton Yakovlev wrote:
>
> All running PCM substreams are stopped on device suspend and restarted
> on device resume.
>
> Signed-off-by: Anton Yakovlev
> ---
> sound/virtio/virtio_card.c| 56 +++
> sound/virtio/virtio_pcm.c
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 56 +++
sound/virtio/virtio_pcm.c | 1 +
sound/virtio/virtio_pcm_ops.c | 41 -
Runtime and system suspend/resume can only come after hba probe invokes
platform_set_drvdata(pdev, hba), meaning hba cannot be NULL in these PM
callbacks, so remove the checks of !hba.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 21 -
1 file changed, 21 deletions
on the
DPM list, trying to create dependencies between them, etc. I gave
up and instead added UML specific cross-driver API that lets the
virt-pci code enable not suspending/resuming VQs for its devices.
This then allows the PCI bus suspend_noirq to still talk to the
device, and suspend/resume
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 57 +++
sound/virtio/virtio_pcm.c | 1 +
sound/virtio/virtio_pcm_ops.c | 44 ---
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 57 +++
sound/virtio/virtio_pcm.c | 1 +
sound/virtio/virtio_pcm_ops.c | 44 ---
On 2/17/2021 11:42 AM, Si-Wei Liu wrote:
On 2/16/2021 8:20 AM, Eli Cohen wrote:
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can avoid this function alltogether since qemu will clear them if
required, e.g.
On Wed, Feb 17, 2021 at 04:20:14PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 17, 2021 at 11:42:48AM -0800, Si-Wei Liu wrote:
> >
> >
> > On 2/16/2021 8:20 AM, Eli Cohen wrote:
> > > When we suspend the VM, the VDPA interface will be reset. When the VM is
> > > resumed again,
el Vetter
> ; open list:DRM DRIVERS de...@lists.freedesktop.org>; open list
> Subject: Re: [PATCH v4] drm/i915/gen9bc: Handle TGP PCH during
> suspend/resume
>
> On Wed, 2021-02-17 at 23:18 +0200, Imre Deak wrote:
> > On Wed, Feb 17, 2021 at 01:00:16PM
On 2/17/2021 1:20 PM, Michael S. Tsirkin wrote:
On Wed, Feb 17, 2021 at 11:42:48AM -0800, Si-Wei Liu wrote:
On 2/16/2021 8:20 AM, Eli Cohen wrote:
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
On Wed, Feb 17, 2021 at 11:42:48AM -0800, Si-Wei Liu wrote:
>
>
> On 2/16/2021 8:20 AM, Eli Cohen wrote:
> > When we suspend the VM, the VDPA interface will be reset. When the VM is
> > resumed again, clear_virtqueues() will clear the available and used
> > indices resulting in hardware
On Wed, 2021-02-17 at 23:18 +0200, Imre Deak wrote:
> On Wed, Feb 17, 2021 at 01:00:16PM -0500, Lyude Paul wrote:
> > From: Tejas Upadhyay
> >
> > For Legacy S3 suspend/resume GEN9 BC needs to enable and
> > setup TGP PCH.
> >
> > v2:
> > * Move Wa_
On Wed, Feb 17, 2021 at 01:00:16PM -0500, Lyude Paul wrote:
> From: Tejas Upadhyay
>
> For Legacy S3 suspend/resume GEN9 BC needs to enable and
> setup TGP PCH.
>
> v2:
> * Move Wa_14010685332 into it's own function - vsyrjala
> * Add TODO comment about fig
On 2/16/2021 8:20 AM, Eli Cohen wrote:
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can avoid this function alltogether
From: Tejas Upadhyay
For Legacy S3 suspend/resume GEN9 BC needs to enable and
setup TGP PCH.
v2:
* Move Wa_14010685332 into it's own function - vsyrjala
* Add TODO comment about figuring out if we can move this workaround - imre
v3:
* Rename cnp_irq_post_reset() to cnp_display_clock_wa()
* Add
On Tue, Feb 16, 2021 at 09:53:36PM -0500, Lyude Paul wrote:
> From: Tejas Upadhyay
>
> For Legacy S3 suspend/resume GEN9 BC needs to enable and
> setup TGP PCH.
>
> v2:
> * Move Wa_14010685332 into it's own function - vsyrjala
> * Add TODO comment about fig
wrote:
> > > From: Tejas Upadhyay
> > >
> > > For Legacy S3 suspend/resume GEN9 BC needs to enable and
> > > setup TGP PCH.
> > >
> > > v2:
> > > * Move Wa_14010685332 into it's own function - vsyrjala
> > > * Add TODO comment abou
From: Tejas Upadhyay
For Legacy S3 suspend/resume GEN9 BC needs to enable and
setup TGP PCH.
v2:
* Move Wa_14010685332 into it's own function - vsyrjala
* Add TODO comment about figuring out if we can move this workaround - imre
v3:
* Rename cnp_irq_post_reset() to cnp_display_clock_wa()
* Add
wrote:
> > > From: Tejas Upadhyay
> > >
> > > For Legacy S3 suspend/resume GEN9 BC needs to enable and
> > > setup TGP PCH.
> > >
> > > v2:
> > > * Move Wa_14010685332 into it's own function - vsyrjala
> > > * Add TODO comment about figurin
On Tue, 2021-02-16 at 20:08 +0200, Imre Deak wrote:
> Hi,
>
> thanks for respinning this patchset, some comments below.
>
> On Fri, Feb 12, 2021 at 01:50:53PM -0500, Lyude Paul wrote:
> > From: Tejas Upadhyay
> >
> > For Legacy S3 suspend/resume GEN9 BC need
Hi,
thanks for respinning this patchset, some comments below.
On Fri, Feb 12, 2021 at 01:50:53PM -0500, Lyude Paul wrote:
> From: Tejas Upadhyay
>
> For Legacy S3 suspend/resume GEN9 BC needs to enable and
> setup TGP PCH.
>
> v2:
> * Move Wa_14010685332 into it's ow
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can avoid this function alltogether since qemu will clear them if
required, e.g.
From: Tejas Upadhyay
For Legacy S3 suspend/resume GEN9 BC needs to enable and
setup TGP PCH.
v2:
* Move Wa_14010685332 into it's own function - vsyrjala
* Add TODO comment about figuring out if we can move this workaround - imre
Cc: Matt Roper
Signed-off-by: Tejas Upadhyay
Signed-off
The "pdata" local variable is not used in suspend/resume handlers since
commit 7776bcd241e0 ("power: supply: s3c-adc-battery: Convert to GPIO
descriptors"):
drivers/power/supply/s3c_adc_battery.c: In function ‘s3c_adc_bat_suspend’:
drivers/power/supply/s3c_adc_batte
Committer: Daniel Lezcano
CommitterDate: Wed, 03 Feb 2021 09:36:50 +01:00
clocksource/drivers/timer-microchip-pit64b: Add clocksource suspend/resume
Add suspend/resume support for clocksource timer.
Signed-off-by: Claudiu Beznea
Signed-off-by: Daniel Lezcano
Link:
https://lore.kernel.org/r
All running PCM substreams are stopped on device suspend and restarted
on device resume.
Signed-off-by: Anton Yakovlev
---
sound/virtio/virtio_card.c| 57 +++
sound/virtio/virtio_pcm.c | 1 +
sound/virtio/virtio_pcm_ops.c | 44 ---
On 19/01/2021 13:59, Claudiu Beznea wrote:
> Add suspend/resume support for clocksource timer.
>
> Signed-off-by: Claudiu Beznea
Applied, thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/page
From: Bjorn Helgaas
This reverts commit 4257f7e008ea394fcecc050f1569c3503b8bcc15.
Kenneth reported that after 4257f7e008ea, he sees a torrent of disk I/O
errors on his NVMe device, and possibly other devices, until a reboot.
Link:
disabling "tlp" doesn't fix the issue; I'd tested this and if IIRC,
if I don't use tlp it doesn't prevent this from happening, it just shifts it
from breaking on hibernate cycles to suspend/resume cycles instead.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
6
From: Kenneth R. Crudup
To: vid...@nvidia.com
Cc: bhelg...@google.com
Subject: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for
suspend/resume") causing hibernate resume
failures
I've been running Linus' master branch on my laptop (Dell XPS 13 2-in-1). With
this commit
en fixed but this still remains.
I haven't seen anything yet and haven't had a chance to look into it
more myself.
We're at v5.11-rc5 already, so I guess we'll have to think about
reverting 4257f7e008ea ("PCI/ASPM: Save/restore L1SS Capability for
suspend/resume") before v5.11-final unless
1 - 100 of 7887 matches
Mail list logo
