From: Dong Aisheng
[ Upstream commit ba5f9fa0ca85a6137fa35efd3a1256d8bb6bc5ff ]
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when M
From: Vidya Sagar
[ Upstream commit 782b6b69847f34dda330530493ea62b7de3fd06a ]
Use noirq suspend/resume callbacks as other drivers which implement
noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
configure the signals used by their respective devices in the noirq phase
From: Vidya Sagar
[ Upstream commit 782b6b69847f34dda330530493ea62b7de3fd06a ]
Use noirq suspend/resume callbacks as other drivers which implement
noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
configure the signals used by their respective devices in the noirq phase
> On Mon, Jun 22, 2020 at 4:53 PM Lorenzo Bianconi
> wrote:
> > > On Sun, Jun 21, 2020 at 10:54 PM Lorenzo Bianconi
> > > wrote:
> > > > > > +static int __maybe_unused
> > > > > > +mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
> > > > > > +{
> > > > > > + struct mt76_dev *mdev =
On Mon, Jun 22, 2020 at 4:53 PM Lorenzo Bianconi
wrote:
> > On Sun, Jun 21, 2020 at 10:54 PM Lorenzo Bianconi
> > wrote:
> > > > > +static int __maybe_unused
> > > > > +mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
> > > > > +{
> > > > > + struct mt76_dev *mdev =
> Hello, Lorenzo.
>
> On Sun, Jun 21, 2020 at 10:54 PM Lorenzo Bianconi wrote:
> > > > +static int __maybe_unused
> > > > +mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
> > > > +{
> > > > + struct mt76_dev *mdev = pci_get_drvdata(pdev);
> > > > + struct mt76x02_dev *dev =
Hello, Lorenzo.
On Sun, Jun 21, 2020 at 10:54 PM Lorenzo Bianconi wrote:
> > > +static int __maybe_unused
> > > +mt76x2e_suspend(struct pci_dev *pdev, pm_message_t state)
> > > +{
> > > + struct mt76_dev *mdev = pci_get_drvdata(pdev);
> > > + struct mt76x02_dev *dev = container_of(mdev,
ule(>tx_napi);
> > +
> > + return 0;
> > +}
> > +
> > MODULE_DEVICE_TABLE(pci, mt76pci_device_table);
> > MODULE_FIRMWARE(MT7662_FIRMWARE);
> > MODULE_FIRMWARE(MT7662_ROM_PATCH);
> > @@ -113,6 +167,10 @@ static struct pci_driver mt76pci_driver = {
&
;
> +
> + return 0;
> +}
> +
> MODULE_DEVICE_TABLE(pci, mt76pci_device_table);
> MODULE_FIRMWARE(MT7662_FIRMWARE);
> MODULE_FIRMWARE(MT7662_ROM_PATCH);
> @@ -113,6 +167,10 @@ static struct pci_driver mt76pci_driver = {
> .id_table = mt76pci_device_table,
> .pro
From: Zijun Hu
[ Upstream commit feac90d756c03b03b83fabe83571bd88ecc96b78 ]
@dev parameter of qca_suspend()/qca_resume() represents
serdev_device, but it is mistook for hci_dev and causes
succedent unexpected memory access.
Fix by taking @dev as serdev_device.
Fixes: 41d5b25fed0 ("Bluetooth:
> Hello, Lorenzo et al.
Hi Oleksandr,
>
> I'm using MT7612 mini-PCIE cards as both AP in a home server and as a client
> in
> a laptop. The AP works perfectly (after some fixing from your side; thanks for
> that!), and so does the client modulo it has issues during system resume.
>
[...]
>
Hello, Lorenzo et al.
I'm using MT7612 mini-PCIE cards as both AP in a home server and as a client in
a laptop. The AP works perfectly (after some fixing from your side; thanks for
that!), and so does the client modulo it has issues during system resume.
So, the card is installed in my aging
message.
Fortunately this cannot happen yet, as the suspend/resume code is used
on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not
use PSCI. Still, it is better to fix this, to avoid this becoming a
problem in the future.
Distinguish between STBCRs and MSTPCRs where needed
From: Dong Aisheng
[ Upstream commit ba5f9fa0ca85a6137fa35efd3a1256d8bb6bc5ff ]
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when M
message.
Fortunately this cannot happen yet, as the suspend/resume code is used
on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not
use PSCI. Still, it is better to fix this, to avoid this becoming a
problem in the future.
Distinguish between STBCRs and MSTPCRs where needed
On 17/06/2020 09:04, Tomi Valkeinen wrote:
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of
On 16/06/2020 19:56, Grygorii Strashko wrote:
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls at
On 16/06/2020 18:30, Tony Lindgren wrote:
* Tomi Valkeinen [200616 13:02]:
On 11/06/2020 17:00, Grygorii Strashko wrote:
I think, suspend might be fixed if all devices, which are now child of ti-sysc,
will do
pm_runtime_force_xxx() calls at noirq suspend stage by adding:
* Tomi Valkeinen [200616 13:02]:
> On 11/06/2020 17:00, Grygorii Strashko wrote:
> > I think, suspend might be fixed if all devices, which are now child of
> > ti-sysc, will do
> > pm_runtime_force_xxx() calls at noirq suspend stage by adding:
> >
> >
Hi Jisheng,
On 6/16/2020 1:03 PM, Jisheng Zhang wrote:
> Hi,
>
> After reading current dwc2 code, I got an impression that resume from suspend
> to ram isn't supported for DWC2_POWER_DOWN_PARAM_NONE case, right? In fact
'ram' Do you mean on suspend save registers in RAM?
If yes, then in case
On 11/06/2020 17:00, Grygorii Strashko wrote:
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
Hi,
After reading current dwc2 code, I got an impression that resume from suspend
to ram isn't supported for DWC2_POWER_DOWN_PARAM_NONE case, right? In fact
we do see usb device can't resume properly with DWC2_POWER_DOWN_PARAM_NONE case.
If the impression is true, what's the proper technical
* Grygorii Strashko [200611 13:59]:
> I think, suspend might be fixed if all devices, which are now child of
> ti-sysc, will do
> pm_runtime_force_xxx() calls at noirq suspend stage by adding:
>
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>
On 09/06/2020 18:26, Tomi Valkeinen wrote:
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
* Tomi Valkeinen [200610 11:48]:
> On 09/06/2020 20:10, Tony Lindgren wrote:
>
> > > On beagle-x15 I see these errors after modprobe:
> > >
> > > DSS: OMAP DSS rev 6.1
> > > omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops
> > > [omapdss])
> > > omapdss_dss 5800.dss:
On 09/06/2020 20:10, Tony Lindgren wrote:
On beagle-x15 I see these errors after modprobe:
DSS: OMAP DSS rev 6.1
omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops
[omapdss])
omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops
[omapdss])
[drm]
On Thu, Jun 4, 2020 at 7:49 PM Vidya Sagar wrote:
> Use noirq suspend/resume callbacks as other drivers which implement
> noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
> configure the signals used by their respective devices in the noirq phase.
>
> Signe
From: Mark Bloch
[ Upstream commit 8fc3e29be9248048f449793502c15af329f35c6e ]
Currently a Linux system with the mlx5 NIC always crashes upon
hibernation - suspend/resume.
Add basic callbacks so the NIC could be suspended and resumed.
Fixes: 9603b61de1ee ("mlx5: Move pci device handling
From: Mark Bloch
[ Upstream commit 8fc3e29be9248048f449793502c15af329f35c6e ]
Currently a Linux system with the mlx5 NIC always crashes upon
hibernation - suspend/resume.
Add basic callbacks so the NIC could be suspended and resumed.
Fixes: 9603b61de1ee ("mlx5: Move pci device handling
* Tony Lindgren [200609 17:11]:
> I'm also seeing the rmmod omapdrm issue on am437x-sk-evm:
Oops sorry this is a user error. I've forgotten I need
to unbind the fb vtcon first :) thanks for hinting that
Tomi!
I can rmmod omapdrm just fine after doing:
# echo 0 >
* Tony Lindgren [200609 16:53]:
> * Tomi Valkeinen [200609 15:27]:
> > On 09/06/2020 18:19, Tony Lindgren wrote:
> > > Currently I'm only able to rmmod -f omapdrm, not sure if these issues
> > > might
> > > be related.
> >
> > Hmm, I always use modules, and can unload omapdrm and drm fine. But
* Tomi Valkeinen [200609 15:27]:
> On 09/06/2020 18:19, Tony Lindgren wrote:
> > Currently I'm only able to rmmod -f omapdrm, not sure if these issues might
> > be related.
>
> Hmm, I always use modules, and can unload omapdrm and drm fine. But there's
> a sequence that must be followed.
On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
Hmm no idea about that. My guess is that there
; dispc_runtime_put (and other runtime_puts) to be called, which result in
> > > dispc_runtime_suspend (and other runtime PM suspends).
> >
> > OK thanks for explaining, I missed that part.
> >
> > > So... For some reason that's no longer happening? I nee
to find a
board with which suspend/resume works (without DSS)...
Yes it seems something has changed. When diffing the dmesg debug output
on suspend and resume, context save and restore functions are no longer
called as the PM runtime suspend and resume functions are no longer
called on suspend
From: Thierry Reding
commit 0534d40160cb9505073b0ecf5e7210daee319a66 upstream.
When the XUDC device is idle (i.e. powergated), care must be taken not
to access any registers because that would lead to a crash.
Move the call to tegra_xudc_device_mode_off() into the same conditional
as the
From: Zijun Hu
[ Upstream commit feac90d756c03b03b83fabe83571bd88ecc96b78 ]
@dev parameter of qca_suspend()/qca_resume() represents
serdev_device, but it is mistook for hci_dev and causes
succedent unexpected memory access.
Fix by taking @dev as serdev_device.
Fixes: 41d5b25fed0 ("Bluetooth:
From: Vitaly Kuznetsov
[ Upstream commit 38dce4195f0daefb566279fd9fd51e1fbd62ae1b ]
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs
From: Mark Bloch
[ Upstream commit 8fc3e29be9248048f449793502c15af329f35c6e ]
Currently a Linux system with the mlx5 NIC always crashes upon
hibernation - suspend/resume.
Add basic callbacks so the NIC could be suspended and resumed.
Fixes: 9603b61de1ee ("mlx5: Move pci device handling
From: Mark Bloch
[ Upstream commit 8fc3e29be9248048f449793502c15af329f35c6e ]
Currently a Linux system with the mlx5 NIC always crashes upon
hibernation - suspend/resume.
Add basic callbacks so the NIC could be suspended and resumed.
Fixes: 9603b61de1ee ("mlx5: Move pci device handling
On Fri, Jun 5, 2020 at 12:12 PM Thomas Gleixner wrote:
>
> Paolo Bonzini writes:
> > On 04/06/20 21:28, Miklos Szeredi wrote:
> >> time(2) returns good time, while clock_gettime(2) returns bad time.
> >> Here's an example:
> >>
> >> time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582
Paolo Bonzini writes:
> On 04/06/20 21:28, Miklos Szeredi wrote:
>> time(2) returns good time, while clock_gettime(2) returns bad time.
>> Here's an example:
>>
>> time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582
>> time=1591298726 RT=1591300383 MONO=39582 MONO_RAW=39582
On 05/06/20 09:35, Miklos Szeredi wrote:
>> time(2) instead should actually be gettimeofday(2), which just returns
>> tk->xtime_sec. So the problem is the nanosecond part which is off by
>> 2199*10^9 nanoseconds, and that is suspiciously close to 2^31...
> Yep: looking at the nanosecond values as
On Thu, Jun 4, 2020 at 10:14 PM Paolo Bonzini wrote:
>
> On 04/06/20 21:28, Miklos Szeredi wrote:
> > time(2) returns good time, while clock_gettime(2) returns bad time.
> > Here's an example:
> >
> > time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582
> > time=1591298726
On 04/06/20 21:28, Miklos Szeredi wrote:
> time(2) returns good time, while clock_gettime(2) returns bad time.
> Here's an example:
>
> time=1591298725 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582
> time=1591298726 RT=1591300383 MONO=39582 MONO_RAW=39582 BOOT=39582
> time=1591298727
On Thu, Jun 4, 2020 at 7:30 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Thomas Gleixner writes:
> >> Of course this does not reproduce here. What kind of host is this
> >> running on? Can you provide a full demsg of the host please from boot to
> >> post resume?
> >
> > Plus /proc/cpuinfo please
04.06.2020 20:49, Vidya Sagar пишет:
> Use noirq suspend/resume callbacks as other drivers which implement
> noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
> configure the signals used by their respective devices in the noirq phase.
>
> Signed-off-
Use noirq suspend/resume callbacks as other drivers which implement
noirq suspend/resume callbacks (Ex:- PCIe) depend on pinctrl driver to
configure the signals used by their respective devices in the noirq phase.
Signed-off-by: Vidya Sagar
---
drivers/pinctrl/tegra/pinctrl-tegra.c | 4 ++--
1
Miklos,
Thomas Gleixner writes:
>> Of course this does not reproduce here. What kind of host is this
>> running on? Can you provide a full demsg of the host please from boot to
>> post resume?
>
> Plus /proc/cpuinfo please (one CPU is sufficient)
thanks for providing the data. Unfortunately not
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be
Thomas Gleixner writes:
> Miklos Szeredi writes:
>> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>>
>>> > Can you please describe the setup of this test?
>>> >
>>> > - Host kernel version
>>
>> 5.5.16-100.fc30.x86_64
>>
>>> > - Guest kernel version
>>
>> 75caf310d16c ("Merge branch
Miklos Szeredi writes:
> On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
>
>> > Can you please describe the setup of this test?
>> >
>> > - Host kernel version
>
> 5.5.16-100.fc30.x86_64
>
>> > - Guest kernel version
>
> 75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
>
>> >
ause
> dispc_runtime_put (and other runtime_puts) to be called, which result in
> dispc_runtime_suspend (and other runtime PM suspends).
OK thanks for explaining, I missed that part.
> So... For some reason that's no longer happening? I need to try to find a
> board with which suspen
) to be called, which result in dispc_runtime_suspend (and other runtime PM suspends).
So... For some reason that's no longer happening? I need to try to find a board with which
suspend/resume works (without DSS)...
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business
From: Dong Aisheng
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost
; interrupt chip specific quirks, e.g. IRQCHIP_MASK_ON_SUSPEND.
>
> Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> it the core interrupt suspend/resume paths.
>
> Signed-off-by: Anchal Agarwal
> Signed-off--by: Thomas Gleixner
Since
From: Dong Aisheng
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by switching over to use UNIVERSAL_DEV_PM_OPS as it
will call
cific quirks, e.g. IRQCHIP_MASK_ON_SUSPEND.
>
> Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> it the core interrupt suspend/resume paths.
>
> Signed-off-by: Anchal Agarwal
> Signed-off--by: Thomas Gleixner
Since Thomas wrote this patch I think it should also have "From: " him.
-boris
On Wed, May 27, 2020 at 8:55 PM Anson Huang wrote:
>
> Gentle ping...
>
>
> > Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
> > suspend/resume
> >
> >
> >
> > > Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
&
On Fri, May 29, 2020 at 2:31 PM Miklos Szeredi wrote:
> > Can you please describe the setup of this test?
> >
> > - Host kernel version
5.5.16-100.fc30.x86_64
> > - Guest kernel version
75caf310d16c ("Merge branch 'akpm' (patches from Andrew)")
> > - Is the revert done on the host or
On Fri, May 29, 2020 at 2:21 PM Thomas Gleixner wrote:
>
> Miklos,
>
> Miklos Szeredi writes:
> > On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
> >> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner
> >> wrote:
> >> >
> >> > Miklos Szeredi writes:
> >> > > Bisected it to:
> >> > >
>
Miklos,
Miklos Szeredi writes:
> On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
>> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
>> >
>> > Miklos Szeredi writes:
>> > > Bisected it to:
>> > >
>> > > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
>> > >
>> > >
Hi Zijun,
> @dev parameter of qca_suspend()/qca_resume() represents
> serdev_device, but it is mistook for hci_dev and causes
> succedent unexpected memory access.
>
> Fix by taking @dev as serdev_device.
>
> Fixes: 41d5b25fed0 ("Bluetooth: hci_qca: add PM support")
> Signed-off-by: Zijun Hu
>
On Fri, May 29, 2020 at 11:51 AM Miklos Szeredi wrote:
>
> On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
> >
> > Miklos Szeredi writes:
> > > Bisected it to:
> > >
> > > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
> > >
> > > The effect observed is that after the
On Thu, May 28, 2020 at 10:43 PM Thomas Gleixner wrote:
>
> Miklos Szeredi writes:
> > Bisected it to:
> >
> > b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
> >
> > The effect observed is that after the host is resumed, the clock in
> > the guest is somewhat in the future and is
Miklos Szeredi writes:
> Bisected it to:
>
> b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
>
> The effect observed is that after the host is resumed, the clock in
> the guest is somewhat in the future and is stopped. I.e. repeated
> date(1) invocations show the same time.
TBH,
On Fri, May 29, 2020 at 04:31:07AM +0800, Zijun Hu wrote:
> @dev parameter of qca_suspend()/qca_resume() represents
> serdev_device, but it is mistook for hci_dev and causes
> succedent unexpected memory access.
>
> Fix by taking @dev as serdev_device.
>
> Fixes: 41d5b25fed0 ("Bluetooth:
@dev parameter of qca_suspend()/qca_resume() represents
serdev_device, but it is mistook for hci_dev and causes
succedent unexpected memory access.
Fix by taking @dev as serdev_device.
Fixes: 41d5b25fed0 ("Bluetooth: hci_qca: add PM support")
Signed-off-by: Zijun Hu
---
Changes in v2:
- remove
Bisected it to:
b95a8a27c300 ("x86/vdso: Use generic VDSO clock mode storage")
The effect observed is that after the host is resumed, the clock in
the guest is somewhat in the future and is stopped. I.e. repeated
date(1) invocations show the same time.
Attaching the .config
Thanks,
Miklos
Hi Zijun,
On Thu, May 28, 2020 at 06:38:22PM +0800, Zijun Hu wrote:
> @dev parameter of qca_suspend()/qca_resume() represents
> serdev_device, but it is mistook for hci_dev and causes
> succedent unexpected memory access.
>
> Fix by taking @dev as serdev_device.
>
> Signed-off-by: Zijun Hu
From: Vitaly Kuznetsov
[ Upstream commit 38dce4195f0daefb566279fd9fd51e1fbd62ae1b ]
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs
@dev parameter of qca_suspend()/qca_resume() represents
serdev_device, but it is mistook for hci_dev and causes
succedent unexpected memory access.
Fix by taking @dev as serdev_device.
Signed-off-by: Zijun Hu
---
drivers/bluetooth/hci_qca.c | 12
1 file changed, 8 insertions(+), 4
Gentle ping...
> Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
> suspend/resume
>
>
>
> > Subject: RE: [PATCH] mailbox: imx: Add context save/restore for
> > suspend/resume
> >
> > > From: Anson Huang
> > > Sent: Friday
On Fri, 22 May 2020 17:57:24 +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume function
> to run
g the
>>> i2c_client.
>> Just one more comment. The devices without i2c_client structure are the
>> i2c 'devices' associated with the respective i2c bus. They are visible
>> in /sys:
>>
>> ls -l /sys/bus/i2c/devices/i2c-*
>>
>> I wonder if this pa
Just one more comment. The devices without i2c_client structure are the
> i2c 'devices' associated with the respective i2c bus. They are visible
> in /sys:
>
> ls -l /sys/bus/i2c/devices/i2c-*
>
> I wonder if this patch has been ever tested with system suspend/resume,
> as those
On Mon, May 25, 2020 at 10:18:16AM +0200, Nicolas Ferre wrote:
> On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> > On 06/05/2020 at 22:18, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > On Wed, 6 May 2020
On 07/05/2020 at 12:03, Nicolas Ferre wrote:
On 06/05/2020 at 22:18, Jakub Kicinski wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
On Wed, 6 May 2020 13:37:37 +0200 nicolas.fe...@microchip.com wrote:
From: Nicolas Ferre
Use the proper
On Mon, May 25, 2020 at 02:11:18PM +0800, Shengjiu Wang wrote:
> > > @@ -1135,6 +1137,24 @@ static int fsl_asrc_runtime_resume(struct device
> > > *dev)
> > > goto disable_asrck_clk;
> > > }
> > >
> > > + /* Stop all pairs provisionally */
> > > +
On Fri, May 22, 2020 at 05:57:24PM +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume
e restored in pm runtime resume. So we can merge suspend/resume function
> > to runtime_suspend/resume function and enable regcache only in end of
> > probe.
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/fsl_asrc.c | 70 --
On Fri, May 22, 2020 at 05:57:24PM +0800, Shengjiu Wang wrote:
> With dedicated power domain for asrc, power can be disabled after
> probe and pm runtime suspend, then the value of all registers need to
> be restored in pm runtime resume. So we can merge suspend/resume
On 08/04/2020 11:05, Michael Kao wrote:
> From: Louis Yu
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
> Signed-off-by: L
st one more comment. The devices without i2c_client structure are the
> i2c 'devices' associated with the respective i2c bus. They are visible
> in /sys:
>
> ls -l /sys/bus/i2c/devices/i2c-*
>
> I wonder if this patch has been ever tested with system suspend/resume,
> as those devi
isible
in /sys:
ls -l /sys/bus/i2c/devices/i2c-*
I wonder if this patch has been ever tested with system suspend/resume,
as those devices are always available in the system...
> ...
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
apter")
Signed-off-by: Marek Szyprowski
---
This fixes suspend/resume issue observed on various board with linux-next
from 20200521.
---
drivers/i2c/i2c-core-base.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/driv
With dedicated power domain for asrc, power can be disabled after
probe and pm runtime suspend, then the value of all registers need to
be restored in pm runtime resume. So we can merge suspend/resume function
to runtime_suspend/resume function and enable regcache only in end of
probe.
Signed-off
Thanks. Looks like send an old one without fix. Did resend the patch again.
On Tue, 2020-05-19 at 23:26 +, Anchal Agarwal wrote:
> Signed-off--by: Thomas Gleixner
The Signed-off-by line needs to be fixed (hint: you have --)
Balbir Singh
On Tue, 2020-05-19 at 23:26 +, Anchal Agarwal wrote:
> Signed-off--by: Thomas Gleixner
The Signed-off-by line needs to be fixed (hint: you have --)
Balbir Singh
interrupts connected
to it are handled this way. This is pretty much in line with the other
interrupt chip specific quirks, e.g. IRQCHIP_MASK_ON_SUSPEND.
Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
it the core interrupt suspend/resume paths.
Signed-off-by: Anchal Agarwal
Signed
From: Thierry Reding
commit 0534d40160cb9505073b0ecf5e7210daee319a66 upstream.
When the XUDC device is idle (i.e. powergated), care must be taken not
to access any registers because that would lead to a crash.
Move the call to tegra_xudc_device_mode_off() into the same conditional
as the
From: Alex Elder
Date: Fri, 15 May 2020 15:07:29 -0500
> This series permits suspend/resume to work for the IPA driver
> on the Qualcomm SC7180 SoC. The IPA version on this SoC requires
> interrupts to be enabled when the suspend and resume callbacks are
> made, and the first patc
This series permits suspend/resume to work for the IPA driver
on the Qualcomm SC7180 SoC. The IPA version on this SoC requires
interrupts to be enabled when the suspend and resume callbacks are
made, and the first patch moves away from using the noirq variants.
The second patch fixes a problem
Use the suspend and resume callbacks rather than suspend_noirq and
resume_noirq. With IPA v4.2, we use the CHANNEL_STOP command to
implement a suspend, and without interrupts enabled, that command
won't complete.
Signed-off-by: Alex Elder
---
drivers/net/ipa/ipa_main.c | 4 ++--
1 file
On Fri, 15 May 2020 at 08:19, Jisheng Zhang wrote:
>
> Add dwcmshc specific system-level suspend and resume support.
>
> Signed-off-by: Jisheng Zhang
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
> 1 file changed,
Add dwcmshc specific system-level suspend and resume support.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index
Add suspend and resume callback function for
Realtek DHC SoC pinctrl driver.
Signed-off-by: TY Chang
---
drivers/pinctrl/realtek/pinctrl-rtd.c | 39 +
drivers/pinctrl/realtek/pinctrl-rtd1195.h | 33 +++
drivers/pinctrl/realtek/pinctrl-rtd1295.h | 67
On Wed, 2020-04-08 at 17:05 +0800, Michael Kao (高振翔) wrote:
> From: Louis Yu
>
> Add suspend/resume callback to disable/enable Mediatek thermal sensor
> respectively. Since thermal power domain is off in suspend, thermal driver
> needs re-initialization during resume.
>
>
On Tue, May 12, 2020 at 06:01:53PM +0200, Vitaly Kuznetsov wrote:
> Errors during hibernation with reenlightenment notifications enabled were
> reported:
>
> [ 51.730435] PM: hibernation entry
> [ 51.737435] PM: Syncing filesystems ...
> ...
> [ 54.102216] Disabling non-boot CPUs ...
>
301 - 400 of 7895 matches
Mail list logo
