3.16.61-rc1 review patch. If anyone has any objections, please let me know.
--
From: Hans de Goede
commit 1d375b58c12f08d8570b30b865def4734517f04f upstream.
On some devices the contents of the ctrl register get lost over a
suspend/resume and the PWM comes back up disabled
During noirq suspend/resume phase, GPIO irq could arrive
and its registers like IMR will be changed by irq handle
process, to make the GPIO registers exactly when it is
powered ON after resume, move the GPIO noirq suspend/resume
callback to syscore suspend/resume phase, local irq is
disabled
During noirq suspend/resume phase, GPIO irq could arrive
and its registers like IMR will be changed by irq handle
process, to make the GPIO registers exactly when it is
powered ON after resume, move the GPIO noirq suspend/resume
callback to syscore suspend/resume phase, local irq is
disabled
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume
On Thu, 2018-11-01 at 11:02 +0100, Philipp Zabel wrote:
> Hi Leonard,
>
> On Wed, 2018-10-31 at 11:02 +, Leonard Crestez wrote:
> > On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> > > Enable PCI suspend/resume support on imx6sx socs. This is similar to
> >
On Thu, 2018-11-01 at 11:02 +0100, Philipp Zabel wrote:
> Hi Leonard,
>
> On Wed, 2018-10-31 at 11:02 +, Leonard Crestez wrote:
> > On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> > > Enable PCI suspend/resume support on imx6sx socs. This is similar to
> >
Hi Leonard,
On Wed, 2018-10-31 at 11:02 +, Leonard Crestez wrote:
> On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> > Enable PCI suspend/resume support on imx6sx socs. This is similar to
> > imx7d with a few differences:
> >
> > * The PM_Turn_Off bit is exposed thr
Hi Leonard,
On Wed, 2018-10-31 at 11:02 +, Leonard Crestez wrote:
> On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> > Enable PCI suspend/resume support on imx6sx socs. This is similar to
> > imx7d with a few differences:
> >
> > * The PM_Turn_Off bit is exposed thr
On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> Enable PCI suspend/resume support on imx6sx socs. This is similar to
> imx7d with a few differences:
>
> * The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
> pcie control bits on 6sx.
> * The pcie_inbound_axi clk
On 10/8/2018 8:38 PM, Leonard Crestez wrote:
> Enable PCI suspend/resume support on imx6sx socs. This is similar to
> imx7d with a few differences:
>
> * The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
> pcie control bits on 6sx.
> * The pcie_inbound_axi clk
From: Thierry Reding
Upon resuming from a system sleep state, the interrupts for all active
shared mailboxes need to be reenabled, otherwise they will not work.
Signed-off-by: Thierry Reding
---
drivers/mailbox/tegra-hsp.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
From: Thierry Reding
Upon resuming from a system sleep state, the interrupts for all active
shared mailboxes need to be reenabled, otherwise they will not work.
Signed-off-by: Thierry Reding
---
drivers/mailbox/tegra-hsp.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
be wakeup was getting disabled,
>> but seems it is working fine now. Patch is good to me if you're going to
>> propose it for backporting, but you should test that it works properly with
>> all of stable kernels.
>
> Indeed, I have been setting up some automated testing
be wakeup was getting disabled,
>> but seems it is working fine now. Patch is good to me if you're going to
>> propose it for backporting, but you should test that it works properly with
>> all of stable kernels.
>
> Indeed, I have been setting up some automated testing
esting of various stable
branches (mainly 4.x LTS releases) and I am seeing this problem there.
Furthermore, I am using this to validate the change as well.
> I just found this [0], seems your patch need to address the same review
> comment.
>
> [0] https://lkml.org/lkml/2011/3/29/18
Thanks will do.
I know we don't support low power modes (ie. LP0), however, I do wonder
if we should have some sort of i2c suspend/resume handler for Tegra?
Eventually we will need this.
Cheers
Jon
--
nvpublic
esting of various stable
branches (mainly 4.x LTS releases) and I am seeing this problem there.
Furthermore, I am using this to validate the change as well.
> I just found this [0], seems your patch need to address the same review
> comment.
>
> [0] https://lkml.org/lkml/2011/3/29/18
Thanks will do.
I know we don't support low power modes (ie. LP0), however, I do wonder
if we should have some sort of i2c suspend/resume handler for Tegra?
Eventually we will need this.
Cheers
Jon
--
nvpublic
On 10/17/18 4:59 PM, Jon Hunter wrote:
>
> On 13/05/2018 22:13, Dmitry Osipenko wrote:
>> Nothing prevents I2C clients to access I2C while Tegra's driver is being
>> suspended, this results in -EBUSY error returned to the clients and that
>> may have unfortunate consequences. In particular this
On 10/17/18 4:59 PM, Jon Hunter wrote:
>
> On 13/05/2018 22:13, Dmitry Osipenko wrote:
>> Nothing prevents I2C clients to access I2C while Tegra's driver is being
>> suspended, this results in -EBUSY error returned to the clients and that
>> may have unfortunate consequences. In particular this
On 13/05/2018 22:13, Dmitry Osipenko wrote:
> Nothing prevents I2C clients to access I2C while Tegra's driver is being
> suspended, this results in -EBUSY error returned to the clients and that
> may have unfortunate consequences. In particular this causes problems
> for the TPS6586x MFD driver
On 13/05/2018 22:13, Dmitry Osipenko wrote:
> Nothing prevents I2C clients to access I2C while Tegra's driver is being
> suspended, this results in -EBUSY error returned to the clients and that
> may have unfortunate consequences. In particular this causes problems
> for the TPS6586x MFD driver
On 8/30/18 10:04 PM, Dmitry Osipenko wrote:
> Hello,
>
> This patch-series fixes CPU hanging after suspend-resume / LP2 cpuidle
> on Tegra30. The bug really appears during stress-testing, like frequent
> suspending under variable load + the upcoming Tegra30 CPUFREQ driver.
>
&g
On 8/30/18 10:04 PM, Dmitry Osipenko wrote:
> Hello,
>
> This patch-series fixes CPU hanging after suspend-resume / LP2 cpuidle
> on Tegra30. The bug really appears during stress-testing, like frequent
> suspending under variable load + the upcoming Tegra30 CPUFREQ driver.
>
&g
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume
Enable PCI suspend/resume support on imx6sx socs. This is similar to
imx7d with a few differences:
* The PM_Turn_Off bit is exposed through an IOMUX GPR, like all other
pcie control bits on 6sx.
* The pcie_inbound_axi clk needs to be turned off in suspend. On resume
it is restored via resume
This change adds support for devfreq suspend/resume
to be called on each system suspend/resume, runtime
suspend/resume, power restore.
Signed-off-by: Talel Shenhar
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/core.c | 112
This change adds support for devfreq suspend/resume
to be called on each system suspend/resume, runtime
suspend/resume, power restore.
Signed-off-by: Talel Shenhar
Signed-off-by: Subhash Jadavani
Signed-off-by: Sayali Lokhande
---
drivers/mmc/core/core.c | 112
On Mon, 2018-09-17 at 17:52 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 17, 2018 at 04:01:21PM +, Leonard Crestez wrote:
> > On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
> > > > V4 adds 4 more patches with
On Mon, 2018-09-17 at 17:52 +0100, Lorenzo Pieralisi wrote:
> On Mon, Sep 17, 2018 at 04:01:21PM +, Leonard Crestez wrote:
> > On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> > > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
> > > > V4 adds 4 more patches with
On Mon, Sep 17, 2018 at 04:01:21PM +, Leonard Crestez wrote:
> On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
>
> > > V4 adds 4 more patches with PME_Turn_Off support on top, using a new
> > > reset bit. I
On Mon, Sep 17, 2018 at 04:01:21PM +, Leonard Crestez wrote:
> On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> > On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
>
> > > V4 adds 4 more patches with PME_Turn_Off support on top, using a new
> > > reset bit. I
On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
> > V4 adds 4 more patches with PME_Turn_Off support on top, using a new
> > reset bit. I generally try to keep series short but in this case some
> > planning might be
On Mon, 2018-09-17 at 16:09 +0100, Lorenzo Pieralisi wrote:
> On Tue, Aug 14, 2018 at 07:50:14PM +0300, Leonard Crestez wrote:
> > V4 adds 4 more patches with PME_Turn_Off support on top, using a new
> > reset bit. I generally try to keep series short but in this case some
> > planning might be
currently only enabled for imx7d but the suspend/resume sequence also
> applies to other socs.
>
> V3 of this series was reviewed by Lucas but stalled because the merge
> window opened.
>
> There was also some confusion about how to deal with the dependence on
> commit 26
currently only enabled for imx7d but the suspend/resume sequence also
> applies to other socs.
>
> V3 of this series was reviewed by Lucas but stalled because the merge
> window opened.
>
> There was also some confusion about how to deal with the dependence on
> commit 26
541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before
initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system susp
541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before
initializing phys")
broke this.
The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system susp
On Wed, 05 Sep 2018, Marek Szyprowski wrote:
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
> also used in ot
On Wed, 05 Sep 2018, Marek Szyprowski wrote:
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
> also used in ot
On Wed, Sep 05, 2018 at 04:36:06PM +0200, Marek Szyprowski wrote:
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
&g
On Wed, Sep 05, 2018 at 04:36:06PM +0200, Marek Szyprowski wrote:
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
&g
Disable IRQs during suspend/resume cycle to ensure handling of wakeup
interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
be properly handled when I2C bus is finally available. This pattern is
also used in other MAX PMIC MFD drivers.
Signed-off-by: Marek Szyprowski
Disable IRQs during suspend/resume cycle to ensure handling of wakeup
interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
be properly handled when I2C bus is finally available. This pattern is
also used in other MAX PMIC MFD drivers.
Signed-off-by: Marek Szyprowski
On Wed, 5 Sep 2018 at 14:32, Marek Szyprowski wrote:
>
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
> als
On Wed, 5 Sep 2018 at 14:32, Marek Szyprowski wrote:
>
> Disable IRQs during suspend/resume cycle to ensure handling of wakeup
> interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
> be properly handled when I2C bus is finally available. This pattern is
> als
Disable IRQs during suspend/resume cycle to ensure handling of wakeup
interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
be properly handled when I2C bus is finally available. This pattern is
also used in other MAX PMIC MFD drivers.
Signed-off-by: Marek Szyprowski
Disable IRQs during suspend/resume cycle to ensure handling of wakeup
interrupts (i.e. RTC wake alarm) after max8997_resume(). This way it can
be properly handled when I2C bus is finally available. This pattern is
also used in other MAX PMIC MFD drivers.
Signed-off-by: Marek Szyprowski
Hi Mark,
On 2018-09-03 17:09, Mark Brown wrote:
> On Mon, Sep 03, 2018 at 04:49:36PM +0200, Marek Szyprowski wrote:
>> regulator_pm_ops with regulator_suspend and regulator_resume functions are
>> assigned to every regulator device registered in the system, so there is no
>> need to iterate over
Hi Mark,
On 2018-09-03 17:09, Mark Brown wrote:
> On Mon, Sep 03, 2018 at 04:49:36PM +0200, Marek Szyprowski wrote:
>> regulator_pm_ops with regulator_suspend and regulator_resume functions are
>> assigned to every regulator device registered in the system, so there is no
>> need to iterate over
the logic in arch_set_page_states(), which is used by
the suspend/resume code. set_page_stable(page, order) was changed to
set_page_stable_dat(page, 0). After this, only the first page of higher order
pages will be set to stable, and a write to one of the unstable pages will
result in an addressing excep
the logic in arch_set_page_states(), which is used by
the suspend/resume code. set_page_stable(page, order) was changed to
set_page_stable_dat(page, 0). After this, only the first page of higher order
pages will be set to stable, and a write to one of the unstable pages will
result in an addressing excep
the logic in arch_set_page_states(), which is used by
the suspend/resume code. set_page_stable(page, order) was changed to
set_page_stable_dat(page, 0). After this, only the first page of higher order
pages will be set to stable, and a write to one of the unstable pages will
result in an addressing excep
the logic in arch_set_page_states(), which is used by
the suspend/resume code. set_page_stable(page, order) was changed to
set_page_stable_dat(page, 0). After this, only the first page of higher order
pages will be set to stable, and a write to one of the unstable pages will
result in an addressing excep
The patch
regulator: Fix useless O^2 complexity in suspend/resume
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
The patch
regulator: Fix useless O^2 complexity in suspend/resume
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
On Mon, Sep 03, 2018 at 04:49:35PM +0200, Marek Szyprowski wrote:
> I've been really surprised that no-one noticed those issues for almost
> 4 kernel releases. Please review my fixes and apply to v4.19-rcX if
> possible.
I suspect this is down to relatively few systems having devices with
On Mon, Sep 03, 2018 at 04:49:35PM +0200, Marek Szyprowski wrote:
> I've been really surprised that no-one noticed those issues for almost
> 4 kernel releases. Please review my fixes and apply to v4.19-rcX if
> possible.
I suspect this is down to relatively few systems having devices with
On Mon, Sep 03, 2018 at 04:49:36PM +0200, Marek Szyprowski wrote:
> regulator_pm_ops with regulator_suspend and regulator_resume functions are
> assigned to every regulator device registered in the system, so there is no
> need to iterate over all again in them. Replace class_for_each_device()
>
On Mon, Sep 03, 2018 at 04:49:36PM +0200, Marek Szyprowski wrote:
> regulator_pm_ops with regulator_suspend and regulator_resume functions are
> assigned to every regulator device registered in the system, so there is no
> need to iterate over all again in them. Replace class_for_each_device()
>
Hi All,
While working on suspend/resume support for Samsung Exynos5433-based TM2
board (arch/arm64/boot/dts/exynos/exynos5433-tm2.dts), I've noticed that
v4.16 kernel release introduced some serious problems with regulator
configuration in system suspend state. Further investigation revealed
Hi All,
While working on suspend/resume support for Samsung Exynos5433-based TM2
board (arch/arm64/boot/dts/exynos/exynos5433-tm2.dts), I've noticed that
v4.16 kernel release introduced some serious problems with regulator
configuration in system suspend state. Further investigation revealed
regulator_pm_ops with regulator_suspend and regulator_resume functions are
assigned to every regulator device registered in the system, so there is no
need to iterate over all again in them. Replace class_for_each_device()
construction with direct operation on the rdev embedded in the given
regulator_pm_ops with regulator_suspend and regulator_resume functions are
assigned to every regulator device registered in the system, so there is no
need to iterate over all again in them. Replace class_for_each_device()
construction with direct operation on the rdev embedded in the given
Hello,
This patch-series fixes CPU hanging after suspend-resume / LP2 cpuidle
on Tegra30. The bug really appears during stress-testing, like frequent
suspending under variable load + the upcoming Tegra30 CPUFREQ driver.
Dmitry Osipenko (2):
ARM: tegra: Switch CPU to PLLP before powergating
Hello,
This patch-series fixes CPU hanging after suspend-resume / LP2 cpuidle
on Tegra30. The bug really appears during stress-testing, like frequent
suspending under variable load + the upcoming Tegra30 CPUFREQ driver.
Dmitry Osipenko (2):
ARM: tegra: Switch CPU to PLLP before powergating
In order to resume CPU from suspend via trusted Foundations firmware,
the LP1/LP2 boot vectors shall be specified using the firmware calls.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 7 ++
arch/arm/mach-tegra/reset-handler.S | 33 +++--
In order to resume CPU from suspend via trusted Foundations firmware,
the LP1/LP2 boot vectors shall be specified using the firmware calls.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 7 ++
arch/arm/mach-tegra/reset-handler.S | 33 +++--
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Mack
[ Upstream commit 0c1049dcb4ceec640d8bd797335bcbebdcab44d2 ]
PXA3xx platforms have 56 interrupts that are stored in two ICMR
registers. The code in pxa_irq_suspend() and
On Tue, 21 Aug 2018 08:50:36 +0200
"Rafael J. Wysocki" wrote:
> On Mon, Aug 20, 2018 at 6:29 PM Michal Suchánek
> wrote:
> >
> > Hello,
> >
> > after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > clearing ACPI IRQs during susp
On Tue, 21 Aug 2018 08:50:36 +0200
"Rafael J. Wysocki" wrote:
> On Mon, Aug 20, 2018 at 6:29 PM Michal Suchánek
> wrote:
> >
> > Hello,
> >
> > after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > clearing ACPI IRQs during susp
On Mon, Aug 20, 2018 at 6:29 PM Michal Suchánek wrote:
>
> Hello,
>
> after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") I am no longer able to
> resume from suspend.
>
> Reported in bugzilla https://b
On Mon, Aug 20, 2018 at 6:29 PM Michal Suchánek wrote:
>
> Hello,
>
> after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> clearing ACPI IRQs during suspend/resume") I am no longer able to
> resume from suspend.
>
> Reported in bugzilla https://b
Hello,
after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
clearing ACPI IRQs during suspend/resume") I am no longer able to
resume from suspend.
Reported in bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=200841
Reverting this on top of 4.18 fixes the issue. acpid
Hello,
after commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
clearing ACPI IRQs during suspend/resume") I am no longer able to
resume from suspend.
Reported in bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=200841
Reverting this on top of 4.18 fixes the issue. acpid
On 16/08/18 11:51, Mark Brown wrote:
> On Wed, Aug 15, 2018 at 07:48:47PM +0100, Jon Hunter wrote:
>
>> So then I made the following change to avoid scheduling the function
>> calls unnecessarily (which I think should be fine) ...
>
>> Please note that I am just using ktime_get() to log the
On 16/08/18 11:51, Mark Brown wrote:
> On Wed, Aug 15, 2018 at 07:48:47PM +0100, Jon Hunter wrote:
>
>> So then I made the following change to avoid scheduling the function
>> calls unnecessarily (which I think should be fine) ...
>
>> Please note that I am just using ktime_get() to log the
On Wed, Aug 15, 2018 at 07:48:47PM +0100, Jon Hunter wrote:
> So then I made the following change to avoid scheduling the function
> calls unnecessarily (which I think should be fine) ...
> Please note that I am just using ktime_get() to log the time on entry
> and exit from dapm_power_widgets()
On Wed, Aug 15, 2018 at 07:48:47PM +0100, Jon Hunter wrote:
> So then I made the following change to avoid scheduling the function
> calls unnecessarily (which I think should be fine) ...
> Please note that I am just using ktime_get() to log the time on entry
> and exit from dapm_power_widgets()
On 14/08/18 15:40, Mark Brown wrote:
> On Mon, Aug 13, 2018 at 07:19:16PM +0100, Jon Hunter wrote:
>>
>> I had taken some ftrace graphs but there was not one thing that really
>> stood out. Looking again it seems that each call to
>> async_schedule_domain() can take tens of uS and so it there
On 14/08/18 15:40, Mark Brown wrote:
> On Mon, Aug 13, 2018 at 07:19:16PM +0100, Jon Hunter wrote:
>>
>> I had taken some ftrace graphs but there was not one thing that really
>> stood out. Looking again it seems that each call to
>> async_schedule_domain() can take tens of uS and so it there
+Cc: Jarkko
On Fri, Jul 27, 2018 at 1:55 AM, Derek Basehore wrote:
> This enables the async suspend property for i2c devices. This reduces
> the suspend/resume time considerably on platforms with multiple i2c
> devices (such as a trackpad or touchscreen).
>
> Signed-off-by:
+Cc: Jarkko
On Fri, Jul 27, 2018 at 1:55 AM, Derek Basehore wrote:
> This enables the async suspend property for i2c devices. This reduces
> the suspend/resume time considerably on platforms with multiple i2c
> devices (such as a trackpad or touchscreen).
>
> Signed-off-by:
On imx7d the pcie-phy power domain is turned off in suspend and this can
make the system hang on resume when attempting any read from PCI.
Fix this by adding PM_SLEEP support to the imx6 pci driver. This is
currently only enabled for imx7d but the suspend/resume sequence also
applies to other
On imx7d the pcie-phy power domain is turned off in suspend and this can
make the system hang on resume when attempting any read from PCI.
Fix this by adding PM_SLEEP support to the imx6 pci driver. This is
currently only enabled for imx7d but the suspend/resume sequence also
applies to other
On Mon, Aug 13, 2018 at 07:19:16PM +0100, Jon Hunter wrote:
>
> I had taken some ftrace graphs but there was not one thing that really
> stood out. Looking again it seems that each call to
> async_schedule_domain() can take tens of uS and so it there are a lot of
> DAPM widgets (100+) this can
On Mon, Aug 13, 2018 at 07:19:16PM +0100, Jon Hunter wrote:
>
> I had taken some ftrace graphs but there was not one thing that really
> stood out. Looking again it seems that each call to
> async_schedule_domain() can take tens of uS and so it there are a lot of
> DAPM widgets (100+) this can
he time is largely spent executing
>> dapm_power_widgets() for each for the DAI links that need to be
>> suspended. Given that dapm_power_widgets() is called again after
>> suspending/resuming the DAI links, one way to optimise the
>> suspend/resume time is to avoid c
he time is largely spent executing
>> dapm_power_widgets() for each for the DAI links that need to be
>> suspended. Given that dapm_power_widgets() is called again after
>> suspending/resuming the DAI links, one way to optimise the
>> suspend/resume time is to avoid c
: 2446254915a7 ("net: dsa: allow switch drivers to implement
suspend/resume hooks")
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/dsa/slave.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/dsa/sla
: 2446254915a7 ("net: dsa: allow switch drivers to implement
suspend/resume hooks")
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/dsa/slave.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/dsa/sla
: 2446254915a7 ("net: dsa: allow switch drivers to implement
suspend/resume hooks")
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/dsa/slave.c |6 ++
1 file changed, 6 insertions(+)
--- a/net/dsa/slave.c
901 - 1000 of 7895 matches
Mail list logo
