This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
From: Grygorii Strashko
[ Upstream commit 5760d9acbe9514eec68eb70821d6fa5764f57042 ]
Add missed suspend/resume callbacks to properly restore networking after
suspend/resume cycle.
Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver
part 1 - dual-emac")
return connection status base on hpd realtime state status
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 13 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 58 -
drivers/gpu/drm/msm/dp/dp_reg.h |
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
Some people may wish to wake their system from sleep, so this
patch enables a suspend and resume function which enables
and disables IRQ wake functions.
Signed-off-by: Adam Ford
diff --git a/drivers/input/touchscreen/ili210x.c
b/drivers/input/touchscreen/ili210x.c
index
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
This patch adds code to handle the system suspension during interleave
scan. The interleave scan will be canceled when the system is going to
sleep, and will be restarted after waking up.
Signed-off-by: Howard Chung
Reviewed-by: Alain Michaud
Reviewed-by: Manish Mandlik
Reviewed-by: Abhishek
Hi Abhishek,
> This series adds the suspend/resume events suggested in
> https://patchwork.kernel.org/patch/11771001/.
>
> I have tested it with some userspace changes that monitors the
> controller resumed event to trigger audio device reconnection and
> verified that the ev
From: Grygorii Strashko
Date: Thu, 10 Sep 2020 23:52:29 +0300
> Add missed suspend/resume callbacks to properly restore networking after
> suspend/resume cycle.
>
> Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based
> driver part 1 - dual-emac")
Hi Marcel,
This series adds the suspend/resume events suggested in
https://patchwork.kernel.org/patch/11771001/.
I have tested it with some userspace changes that monitors the
controller resumed event to trigger audio device reconnection and
verified that the events are correctly emitted
Hi Marcel,
This series adds the suspend/resume events suggested in
https://patchwork.kernel.org/patch/11771001/.
I have tested it with some userspace changes that monitors the
controller resumed event to trigger audio device reconnection and
verified that the events are correctly emitted
Hi Abhishek,
> This series adds the suspend/resume events suggested in
> https://patchwork.kernel.org/patch/11663455/.
>
> I have tested it with some userspace changes that monitors the
> controller resumed event to trigger audio device reconnection and
> verified that the ev
Add missed suspend/resume callbacks to properly restore networking after
suspend/resume cycle.
Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based driver
part 1 - dual-emac")
Signed-off-by: Grygorii Strashko
---
drivers/net/ethernet/ti/cpsw_
This commit adds sleepwalk/wake and suspend/resume interfaces
to Tegra XUSB PHY driver.
Tegra XUSB host controller driver makes use of sleepwalk functions
to enable/disable sleepwalk circuit which is in always-on partition
and can respond to USB resume signals when controller is not powered
sleepwalk/wake and suspend/resume interfaces
>> to Tegra XUSB PHY driver.
>>
>> Tegra XUSB host controller driver makes use of sleepwalk functions
>> to enable/disable sleepwalk circuit which is in always-on partition
>> can respond to USB resume signals when con
From: Rob Clark
Signed-off-by: Rob Clark
---
I'm not sure if there is a better way to do no-arg tracepoints? The
trace framework seems to go out of it's way to make this difficult.
Or maybe there is a more obvious thing that I'm not seeing.
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
Again, use a capital letter to start the subject after the prefix.
On Mon, Aug 31, 2020 at 12:40:36PM +0800, JC Kuo wrote:
> This commit adds sleepwalk/wake and suspend/resume interfaces
> to Tegra XUSB PHY driver.
>
> Tegra XUSB host controller driver makes use of sleepwa
This commit adds sleepwalk/wake and suspend/resume interfaces
to Tegra XUSB PHY driver.
Tegra XUSB host controller driver makes use of sleepwalk functions
to enable/disable sleepwalk circuit which is in always-on partition
can respond to USB resume signals when controller is not powered
This commit adds sleepwalk/wake and suspend/resume interfaces
to Tegra XUSB PHY driver.
Tegra XUSB host controller driver makes use of sleepwalk functions
to enable/disable sleepwalk circuit which is in always-on partition
can respond to USB resume signals when controller is not powered
On Tue, Aug 25 2020 at 14:20, Christoph Hellwig wrote:
> On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote:
>> From: Thomas Gleixner
>>
>> followed by an empty new line before the actual changelog text
>> starts. That way the attribution of the patch when applying it will be
>>
On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> followed by an empty new line before the actual changelog text
> starts. That way the attribution of the patch when applying it will be
> correct.
The way he sent it attribution will be correct as he
2:27, Thomas Gleixner wrote:
> > Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> > it the core interrupt suspend/resume paths.
> >
> > Changelog:
> > v1->v2: Corrected the author's name to tglx@
>
> Can you please move that Changelog pa
From: Amelie Delaunay
[ Upstream commit db96bf976a4fc65439be0b4524c0d41427d98814 ]
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
From: Amelie Delaunay
[ Upstream commit db96bf976a4fc65439be0b4524c0d41427d98814 ]
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
From: Amelie Delaunay
[ Upstream commit db96bf976a4fc65439be0b4524c0d41427d98814 ]
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
On Fri, Aug 21 2020 at 22:27, Thomas Gleixner wrote:
> Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> it the core interrupt suspend/resume paths.
>
> Changelog:
> v1->v2: Corrected the author's name to tglx@
Can you please move that Changelog part below
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.
Changelog:
v1->v2: Correc
Hi Marcel,
Please review this patch. A newer series for how the controller resume
event will be used is available at
https://patchwork.kernel.org/project/bluetooth/list/?series=334811
Besides usage in bluez, these events will also make debugging and
testing suspend/resume for Bluez easier (i.e
r.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
Thanks!
[1/1] regulator: Avoid grabbing regulator lock during suspend/resume
commit: 0955f5be4337c0ada82e49389249eb99199f8db2
All being well this means that it will be integrated into the
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
ans through which
> >> aoss determines whether to wait for
> >> modem before proceeding to sleep. So
> >> looks like updating the flag with
> >> GENPD_FLAG_ACTIVE_WAKEUP is the way
> >> to go. But introducing another flag
> >> that doesn't touch genpd's
On Thu, Aug 06, 2020 at 01:06:15AM +0530, Vaibhav Gupta wrote:
> The driver calls pci_enable_wake(, false) in pch_i2c_suspend() as well
> as pch_i2c_resume(). Either it should enable-wake the device in .suspend()
> or should not invoke pci_enable_wake() at all.
>
> Concluding that this driver
From: Amelie Delaunay
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
---
v2: identical to v1
drivers/spi/spi-stm32.c | 27
From: Amelie Delaunay
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support")
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
---
drivers/spi/spi-stm32.c | 27
The debug messages about what syscore suspend/resume hooks are called
are only present if you have initcall debugging enabled. Let's move
these messages to pm_pr_dbg() so that the syscore PM messages are
included along with all the other PM debugging info that can be seen
during suspend/resume
d for modem
is the primary means through which
aoss determines whether to wait for
modem before proceeding to sleep. So
looks like updating the flag with
GENPD_FLAG_ACTIVE_WAKEUP is the way
to go. But introducing another flag
that doesn't touch genpd's during
suspend/resume should also work.
Did
>> GENPD_FLAG_ACTIVE_WAKEUP does), then we'd have to pass
>> GENPD_FLAG_ALWAYS_ON as a flag and then add suspend hooks to make the
>> decision for us.
Doug/Stephen,
Yes this is a bug, we wouldn't want
to disable aoss_qmp genpd for modem
during suspend (when the modem is
runni
ng it's a bug today, we should mark the "modem" as
> >> GENPD_FLAG_ALWAYS_ON.
> >>
> >> c) If there are genpds that sometimes should be left on in suspend but
> >> sometimes not (and that doesn't match up with what
> >> GENPD_FLAG_ACTIV
+Sibi who wrote the code
Quoting Doug Anderson (2020-08-05 13:24:06)
>
> On Wed, Aug 5, 2020 at 10:36 AM Stephen Boyd wrote:
> >
> > Why is the genpd being powered off at all? It looks like the driver is
> > written in a way that it doesn't expect this to happen. See where
> >
Hi,
On Wed, Aug 5, 2020 at 10:36 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-08-05 09:16:10)
> > Running suspend/resume tests on a sc7180-based board with a modem I
> > found that both system suspend and system resume would hang for 1
> > second. These
The driver calls pci_enable_wake(, false) in pch_i2c_suspend() as well
as pch_i2c_resume(). Either it should enable-wake the device in .suspend()
or should not invoke pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev,
Quoting Douglas Anderson (2020-08-05 09:16:10)
> Running suspend/resume tests on a sc7180-based board with a modem I
> found that both system suspend and system resume would hang for 1
> second. These messages indicate where:
>
> genpd genpd:0:408.remoteproc: calling genp
Running suspend/resume tests on a sc7180-based board with a modem I
found that both system suspend and system resume would hang for 1
second. These messages indicate where:
genpd genpd:0:408.remoteproc: calling genpd_suspend_noirq+0x0/0x2c @
18659, parent: none
genpd genpd:0:408
From: Amelie Delaunay
This patch adds pinctrl power management, and reconfigure spi controller
in case of resume.
Signed-off-by: Amelie Delaunay
Signed-off-by: Alain Volmat
---
drivers/spi/spi-stm32.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff
Hi,
On Tue, Aug 4, 2020 at 12:08 AM Stephen Boyd wrote:
>
> I see it takes about 5us per regulator to grab the lock, check that this
> regulator isn't going to do anything for suspend, and then release the
> lock. When that is combined with PMICs that have dozens of regulators we
> get into a
Hi Marcel,
>
> This series adds the suspend/resume events suggested in
> https://patchwork.kernel.org/patch/11663455/.
>
> I have tested it with some userspace changes that monitors the
> controller resumed event to trigger audio device reconnection and
> verified that the events are corr
I see it takes about 5us per regulator to grab the lock, check that this
regulator isn't going to do anything for suspend, and then release the
lock. When that is combined with PMICs that have dozens of regulators we
get into a state where we spend a few miliseconds doing a bunch of
locking
Hello,
On Tue, 2020-07-28 at 18:06 -0500, Bjorn Helgaas wrote:
>
> I tried to deduce the problem from the code in aspm.c, but I didn't
> see the problem. If you have the ability to build a kernel with a
> debug patch, can you boot with the patch below and collect the dmesg
> log?
I've built
Hi Marcel,
This series adds the suspend/resume events suggested in
https://patchwork.kernel.org/patch/11663455/.
I have tested it with some userspace changes that monitors the
controller resumed event to trigger audio device reconnection and
verified that the events are correctly emitted
On Tue, Jul 28, 2020 at 09:57:55PM +0100, James Ettle wrote:
> On Mon, 2020-07-27 at 16:47 -0500, Bjorn Helgaas wrote:
> >
> > I don't see anything in rtsx that enables L0s. Can you collect
> > the dmesg log when booting with "pci=earlydump"? That will show
> > whether the BIOS left it this
On Mon, 2020-07-27 at 16:47 -0500, Bjorn Helgaas wrote:
>
> I don't see anything in rtsx that enables L0s. Can you collect the
> dmesg log when booting with "pci=earlydump"? That will show whether
> the BIOS left it this way. The PCI core isn't supposed to do this,
> so
> if it did, we need to
t; > > verify
> > > that if we don't have any outside influences on the ASPM
> > > configuration
> > > (eg, no manual changes and no udev rules), it stays the same across
> > > suspend/resume.
> >
> > Basically this started from me observing
> that if we don't have any outside influences on the ASPM
> > configuration
> > (eg, no manual changes and no udev rules), it stays the same across
> > suspend/resume.
>
> Basically this started from me observing deep package C-states weren't
> being used, until I went
gt; (eg, no manual changes and no udev rules), it stays the same across
> suspend/resume.
Basically this started from me observing deep package C-states weren't
being used, until I went and fiddled with the ASPM state of the
rtsx_pci card reader under sysfs -- so phenomenological poking on my
p
gt; > configuration stay the same across suspend/resume?
>
> Yes, it stays the same. Explicitly:
>
> With the udev rule disabled, immediately following clean boot from
> power-off (and no additional tinkering), ASPM is OFF to the best of my
> knowledge:
>
> - link/l
This is to prepare WOL support with phy. Compared with WOL
implementation which relies on the MAC's PMT features, in phy
supported WOL case, device_may_wakeup() may also be true, but we
should not call mac's pmt() function if HW doesn't enable PMT.
And during resume, we should call
On Fri, 2020-07-24 at 18:13 -0500, Bjorn Helgaas wrote:
>
> Maybe we should simplify this a little bit more. James, if you don't
> touch ASPM config at all, either manually or via udev, does the ASPM
> configuration stay the same across suspend/resume?
>
Yes, it stays the s
cates things a little. The sysfs link/l1_aspm functionality
he's using is new and could well be buggy.
Maybe we should simplify this a little bit more. James, if you don't
touch ASPM config at all, either manually or via udev, does the ASPM
configuration stay the same across suspend/r
g Kroah-Hartman; James Ettle; Len Brown; Puranjay
> Mohan; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jacopo De
> Simoi
> Subject: Re: rtsx_pci not restoring ASPM state after suspend/resume
>
> [+cc Jacopo]
>
> On Thu, Jul 23, 2020 at 11:56:22AM -0500, Bjorn Helgaas
[+cc Jacopo]
On Thu, Jul 23, 2020 at 11:56:22AM -0500, Bjorn Helgaas wrote:
> James reported this issue with rtsx_pci; can you guys please take a
> look at it? https://bugzilla.kernel.org/show_bug.cgi?id=208117
>
> There's a lot of good info in the bugzilla already.
Likely duplicate:
James reported this issue with rtsx_pci; can you guys please take a
look at it? https://bugzilla.kernel.org/show_bug.cgi?id=208117
There's a lot of good info in the bugzilla already.
Bjorn
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
From: Nicolas Ferre
[ Upstream commit 6c8f85cac98a4c6b767c4c4f6af7283724c32b47 ]
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906
From: Nicolas Ferre
[ Upstream commit 515a10a701d570e26dfbe6ee373f77c8bf11053f ]
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
>dev->dev.parent.
It's preventing the trigger of a
From: Nicolas Ferre
[ Upstream commit 515a10a701d570e26dfbe6ee373f77c8bf11053f ]
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
>dev->dev.parent.
It's preventing the trigger of a
From: Nicolas Ferre
[ Upstream commit 6c8f85cac98a4c6b767c4c4f6af7283724c32b47 ]
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906
> From: Vincenzo Frascino
> Sent: Monday, July 6, 2020 11:00 PM
>
> imx_mu_suspend_noirq()/imx_mu_resume_noirq() are currently used only
> when CONFIG_PM_SLEEP configuration options is enabled. Having it disabled
> triggers the following warning at compile time:
>
>
e other series you pulled in
takes care of Geert's issue.
But deferred probe can still break suspend/resume ordering (example
mentioned in the commit text). So I think we should fix that (version
X of this patch).
Rafael was concerned about some of the extra work v1 will cause for
cases that work fine
; > > > > > > On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > > > > > > > wrote:
> > > > > > > > > Note that deferred probing gets in the way here and so the
> > > > > > > > > problem is
> > > > > > > &
From: Nicolas Ferre
The calls to pm_runtime_force_suspend/resume() functions are only
relevant if the device is not configured to act as a WoL wakeup source.
Add the device_may_wakeup() test before calling them.
Fixes: 3e2a5e153906 ("net: macb: add wake-on-lan support via magic packet")
Cc:
From: Nicolas Ferre
Use the proper struct device pointer to check if the wakeup flag
and wakeup source are positioned.
Use the one passed by function call which is equivalent to
>dev->dev.parent.
It's preventing the trigger of a spurious interrupt in case the
Wake-on-Lan feature is used.
On Thu, 2020-05-14 at 16:46 +0800, Michael Kao wrote:
> 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
On 06.07.2020 18:00, Vincenzo Frascino wrote:
imx_mu_suspend_noirq()/imx_mu_resume_noirq() are currently used only
when CONFIG_PM_SLEEP configuration options is enabled. Having it
disabled triggers the following warning at compile time:
drivers/mailbox/imx-mailbox.c:611:12: warning:
imx_mu_suspend_noirq()/imx_mu_resume_noirq() are currently used only
when CONFIG_PM_SLEEP configuration options is enabled. Having it
disabled triggers the following warning at compile time:
drivers/mailbox/imx-mailbox.c:611:12: warning: ‘imx_mu_resume_noirq’
defined but not used
be marked that all 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.
Changelog
> > > > > wrote:
> > > > > > > On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > > > > > > wrote:
> > > > > > > > Note that deferred probing gets in the way here and so the
> > > > > > > &
, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > > > > > > > wrote:
> > > > > > > > > Note that deferred probing gets in the way here and so the
> > > > > > > > > problem is
> > > > > > >
Note that deferred probing gets in the way here and so the
> > > > > > > > problem is
> > > > > > > > related to it.
> > > > > > >
> > > > > > > I mean, we officially support deferred probing. Shouldn't we fix
> > >
; On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > > > > > wrote:
> > > > > > > Note that deferred probing gets in the way here and so the
> > > > > > > problem is
> > > > > > > related to it.
> > > &g
rred probing gets in the way here and so the problem
> > > > > > is
> > > > > > related to it.
> > > > >
> > > > > I mean, we officially support deferred probing. Shouldn't we fix it so
> > > > > that it doesn't break
wrote:
> > > > On Thu, Jun 25, 2020 at 10:47 AM Rafael J. Wysocki
> > > > wrote:
> > > > > Note that deferred probing gets in the way here and so the problem is
> > > > > related to it.
> > > >
> > > > I mean, we officia
Hi Mark,
> From: Mark Brown, Sent: Monday, June 29, 2020 9:58 PM
>
> On Mon, Jun 29, 2020 at 02:42:26AM +, Yoshihiro Shimoda wrote:
> > > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
>
> Copying in Sudeep for the feedback on firmware interfaces.
Thank you very much for the
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 29, 2020 at 02:42:26AM +, Yoshihiro Shimoda wrote:
> > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
Copying in Sudeep for the feedback on firmware interfaces.
> > According to the changelog this is all about reflecting changes in the
> > system state done by firmware
On Mon, Jun 29, 2020 at 04:07:28PM +0100, Sudeep Holla wrote:
> On Mon, Jun 29, 2020 at 04:15:39PM +0200, Geert Uytterhoeven wrote:
> > This is all about how to know what exactly PSCI is powering down during
> > SYSTEM_SUSPEND. In this specific case, it is about knowing if the eMMC
> > is
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 29, 2020 at 01:57:56PM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2020 at 02:42:26AM +, Yoshihiro Shimoda wrote:
> > > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
>
> Copying in Sudeep for the feedback on firmware interfaces.
>
Thanks Mark.
> > > According to the
On Mon, Jun 29, 2020 at 05:14:50PM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2020 at 04:07:28PM +0100, Sudeep Holla wrote:
> > On Mon, Jun 29, 2020 at 04:15:39PM +0200, Geert Uytterhoeven wrote:
>
> > > This is all about how to know what exactly PSCI is powering down during
> > > SYSTEM_SUSPEND.
Hi Sudeep,
On Mon, Jun 29, 2020 at 3:40 PM Sudeep Holla wrote:
> On Mon, Jun 29, 2020 at 01:57:56PM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 02:42:26AM +, Yoshihiro Shimoda wrote:
> > > > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
> > > > According to the changelog
On Mon, Jun 29, 2020 at 06:26:51PM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2020 at 05:42:07PM +0100, Sudeep Holla wrote:
> > On Mon, Jun 29, 2020 at 05:14:50PM +0100, Mark Brown wrote:
> > > On Mon, Jun 29, 2020 at 04:07:28PM +0100, Sudeep Holla wrote:
> > >
> > > > The specification states
On Mon, Jun 29, 2020 at 04:15:39PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Mon, Jun 29, 2020 at 3:40 PM Sudeep Holla wrote:
> > On Mon, Jun 29, 2020 at 01:57:56PM +0100, Mark Brown wrote:
> > > On Mon, Jun 29, 2020 at 02:42:26AM +, Yoshihiro Shimoda wrote:
> > > > > From: Mark
On Mon, Jun 29, 2020 at 05:42:07PM +0100, Sudeep Holla wrote:
> On Mon, Jun 29, 2020 at 05:14:50PM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 04:07:28PM +0100, Sudeep Holla wrote:
> >
> > > The specification states clearly:
> > > "... all devices in the system must be in a state that is
Hi Mark,
> From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
>
> On Fri, Jun 26, 2020 at 06:32:20PM +0900, Yoshihiro Shimoda wrote:
>
> > +static int reg_is_enabled(struct regulator_dev *rdev)
> > +{
> > + struct fixed_voltage_data *priv = rdev_get_drvdata(rdev);
> > +
> > + return
wrote:
> > > > Note that deferred probing gets in the way here and so the problem is
> > > > related to it.
> > >
> > > I mean, we officially support deferred probing. Shouldn't we fix it so
> > > that it doesn't break suspend/resume?
> >
>
y here and so the problem is
> > > related to it.
> >
> > I mean, we officially support deferred probing. Shouldn't we fix it so
> > that it doesn't break suspend/resume?
>
> Yes, we should fix deferred probing.
>
> > Also, it's pretty easy to have
> > cases whe
On Fri, Jun 26, 2020 at 06:32:20PM +0900, Yoshihiro Shimoda wrote:
> +static int reg_is_enabled(struct regulator_dev *rdev)
> +{
> + struct fixed_voltage_data *priv = rdev_get_drvdata(rdev);
> +
> + return !priv->disabled_in_suspend;
> +}
This is broken, the state of the regualtor during
> > 7. driver-B is loaded and probes device-B.
> > > > > > > > > 8. dpm_list stays as [device-B, device-A].
> > > > > > > > >
> > > > > > > > > Suspend (which goes in the reverse order of dpm_list) fails
> > > > > > > > >
The regulator-fixed driver is possible to be off by firmware
like PSCI while the system is suspended. If a consumer could get
such a condition from regulator_is_enabled(), it's useful by
consumers.
So, add some regulator_ops members for it. And then, if
regulator-fixed nodes have suitable
201 - 300 of 7908 matches
Mail list logo
