Make genpd to take the wakeup_path_in_band status flag into account during
system suspend/resume. More precisely, in case the flag has been set by the
PM core, let's leave the device in full power state and prevent the PM
domain from being powered off.
Signed-off-by: Ulf Hansson
Review
Let's make the code a bit more readable by moving some of the code, which
deals with adjustments for parent devices in __device_suspend(), into its
own function.
Signed-off-by: Ulf Hansson
Reviewed-by: Geert Uytterhoeven
---
Changes in v2:
- Added Geert's Reviewed-by tag.
--
configure WakeOnLAN, for some ethernet
devices/drivers, which are used together with genpd. My intent is that this
series enables a solution for those problems.
[1]
https://www.spinics.net/lists/linux-renesas-soc/msg19319.html
Changes in v2:
- See change logs for each patch.
Ulf Hansson
g by using a status flag in the struct dev_pm_info for the
parent. This also makes it consistent with how the existing "wakeup_path"
status flag is being assigned.
Signed-off-by: Ulf Hansson
---
Changes in v2:
- Fixed comments from Rafael:
- Rename fl
On 13 November 2017 at 16:46, Ulf Hansson wrote:
> The generic problem this series is trying to solve, is that for some bus types
> and PM domains, it's not sufficient to only check the return value from
> device_may_wakeup(), to fully understand how to treat the device during sy
On 14 November 2017 at 23:55, Wolfram Sang
wrote:
> Documentation/timers/timers-howto.txt recommends to use usleep_range for
> delays 1-20ms. Let's adhere to it. No need for messing with HZ and still
> do busy looping these days.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Here is a more detailed t
On 16 November 2017 at 08:59, Shawn Lin wrote:
> Hi,
>
> On 2017/11/16 15:47, Ulf Hansson wrote:
>>
>> On 14 November 2017 at 23:55, Wolfram Sang
>> wrote:
>>>
>>> Documentation/timers/timers-howto.txt recommends to use usleep_range for
>>>
On 14 November 2017 at 23:51, Wolfram Sang
wrote:
> There are a few udelay() left which are in a range that they should be
> usleep_range() these days.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind regards
Uffe
> ---
>
> Works fine for me on Lager (R-Car H2) and Salvator-X (R-
On 14 November 2017 at 23:55, Wolfram Sang
wrote:
> Documentation/timers/timers-howto.txt recommends to use usleep_range for
> delays 1-20ms. Let's adhere to it. No need for messing with HZ and still
> do busy looping these days.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind re
On 15 November 2017 at 16:25, Ulrich Hecht
wrote:
> Adds bindings for the R-Car D3 SoC's SDHI IP.
>
> Signed-off-by: Ulrich Hecht
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Doc
On 28 November 2017 at 13:48, Yoshihiro Shimoda
wrote:
> Hi Geert-san,
>
>> From: Geert Uytterhoeven, Sent: Tuesday, November 28, 2017 7:58 PM
>>
>> Hi Rafael, Shimoda-san,
>>
>> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki
>> wrote:
>> > From: Rafael J. Wysocki
>> >
>> > The check for "a
On 29 November 2017 at 09:21, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>
>> On 28 November 2017 at 13:48, Yoshihiro Shimoda
>> wrote:
>> > Hi Geert-san,
>> >
>> >> From:
On 29 November 2017 at 10:43, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson wrote:
>> On 29 November 2017 at 09:21, Yoshihiro Shimoda
>> wrote:
>>>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM
>>>
On 29 November 2017 at 17:06, Ulrich Hecht
wrote:
> Whitelists for internal DMAC implementation.
>
> Signed-off-by: Ulrich Hecht
> Reviewed-by: Geert Uytterhoeven
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
> 1 file changed, 1 inse
On 1 December 2017 at 09:20, Simon Horman wrote:
> On Wed, Nov 29, 2017 at 05:06:44PM +0100, Ulrich Hecht wrote:
>> Hi!
>>
>> This integrates the SDHI hardware on R-Car D3 and enables the Draak board's
>> eMMC drive.
>>
>> This revision dumps the two patches that have been applied already, fixes
>
+ Kishon
On 30 November 2017 at 13:51, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM
>>
>> On 29 November 2017 at 10:43, Geert Uytterhoeven
>> wrote:
>> > Hi Ulf,
>
>> Okay, so the problem
On 1 December 2017 at 12:03, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM
>>
>> + Kishon
>>
>> On 30 November 2017 at 13:51, Yoshihiro Shimoda
>> wrote:
>> > Hi,
>> >
>>
On 5 December 2017 at 04:23, Yoshihiro Shimoda
wrote:
> Hi,
>
>> From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM
>>
>> On 1 December 2017 at 12:03, Yoshihiro Shimoda
>> wrote:
>
>> > Sure! I tested your patch, and then the following message
On 30 November 2017 at 15:49, Wolfram Sang
wrote:
> When the latest version of parsing the new eMMC bindings was moved from
> core.c to mmc.c, it was overlooked that drv_type could be used
> uninitialized. Fix it!
>
> Fixes: 6186d06c519e21 ("mmc: parse new binding for eMMC fixed driver type")
> Re
On 10 December 2017 at 03:30, Rafael J. Wysocki wrote:
> On Monday, November 13, 2017 4:46:42 PM CET Ulf Hansson wrote:
>> For some bus types and PM domains, it's not sufficient to only check the
>> return value from device_may_wakeup(), to fully understand how to configure
&g
On 10 December 2017 at 11:16, Geert Uytterhoeven wrote:
> Hi Rafael, Ulf,
>
> On Sun, Dec 10, 2017 at 3:30 AM, Rafael J. Wysocki wrote:
>> On Monday, November 13, 2017 4:46:42 PM CET Ulf Hansson wrote:
>>> For some bus types and PM domains, it's not sufficient to on
On 11 December 2017 at 11:48, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Mon, Dec 11, 2017 at 11:24 AM, Ulf Hansson wrote:
>> On 10 December 2017 at 11:16, Geert Uytterhoeven
>> wrote:
>>> On Sun, Dec 10, 2017 at 3:30 AM, Rafael J. Wysocki
>>> wrote:
&g
On 12 December 2017 at 09:16, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson wrote:
>> That together with an option of allowing "consumed resource-devices"
>> (irqchip) to be included in the wakeup path. I am thinking, pe
s configured as wakeup sources.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> v2:
> - Integrate "clk: renesas: mstp: Use GENPD_FLAG_ACTIVE_WAKEUP",
> ---
> drivers/clk/renesas/clk-mstp.c | 2 +-
> 1 file changed, 1
s configured as wakeup sources.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> v2:
> - Integrate "clk: renesas: cpg-mssr: Use GENPD_FLAG_ACTIVE_WAKEUP",
> ---
> drivers/clk/renesas/renesas-cpg-mssr.c | 2 +-
> 1 file
; Note that this will only affect devices configured as wakeup sources.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> v2:
> - Integrate "soc: renesas: rcar-sysc: Use GENPD_FLAG_ACTIVE_WAKEUP",
> ---
> drivers/soc/renesas/
On 14 December 2017 at 11:52, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson wrote:
>> On 11 December 2017 at 11:48, Geert Uytterhoeven
>> wrote:
>>> On Mon, Dec 11, 2017 at 11:24 AM, Ulf Hansson
>>> wrote:
&
On 24 November 2017 at 17:24, Masahiro Yamada
wrote:
>
> I am working on this IP for Socionext SoCs.
>
> I was hit by several issues, and noticed various
> clean-up candidates.
>
> - Fix and clean-up Kconfig
> - Fix various card detection problems
> - Move Renesas private data out of TMIO core
On 13 December 2017 at 03:33, Yoshihiro Shimoda
wrote:
> From: Masaharu Hayakawa
>
> The following error occurs when loading renesas_sdhi_core.c module,
> so add MODULE_LICENSE("GPL v2").
>
> renesas_sdhi_core: module license 'unspecified' taints kernel.
>
> Signed-off-by: Masaharu Hayakawa
> F
On 15 December 2017 at 12:12, Wolfram Sang wrote:
>
>> After 2, COMPILE_TEST will work correctly.
>>
>> Then, Wolfram mentioned we would need to include from tmio_mmc.h
>>
>> https://patchwork.kernel.org/patch/10074333/
>>
>>
>> I was waiting for a patch from him.
>
> Yes, I am sorry. I am curren
s.net/lists/linux-renesas-soc/msg20122.html
[2]
https://www.spinics.net/lists/linux-renesas-soc/msg19947.html
Ulf Hansson (3):
PM / core: Assign the wakeup_path status flag in __device_prepare()
PM / core: Add WAKEUP_PATH driver flag
PM / Domains: Take WAKEUP_PATH driver flag into account in g
icitly, in
case it has been set after the ->suspend() callback has been invoked for
the device.
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 3 ++-
include/linux/pm.h| 7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/driv
let's move the assignment of the wakeup_path status flag
to the __device_suspend() phase and more precisely, after the ->suspend()
callback has been invoked.
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
In case the WAKEUP_PATH flag has been set in a later phase than from the
->suspend() callback, the PM core want set the ->power.wakeup_path status
flag for the device. Therefore, let's be safe and check it explicitly.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 8
On 15 December 2017 at 16:56, Ulf Hansson wrote:
> In case the WAKEUP_PATH flag has been set in a later phase than from the
> ->suspend() callback, the PM core want set the ->power.wakeup_path status
/s/want/don't
If another version is needed I fix, else perhaps you can jus
On 15 December 2017 at 17:30, Wolfram Sang wrote:
>
>> > Ulf, this patch then in deed should ideally be applied before 1-8 here.
>>
>> Okay, once you post it to linux-mmc I will pick it up, and put it in front.
>
> Bad news, that patch didn't help. The problem is that sparc64 doesn't
> include 'as
On 18 December 2017 at 01:00, Wolfram Sang
wrote:
> Not all archs define reads* and writes*. Switch to ioread*_rep and
> friends which is defined everywhere, so we can enable COMPILE_TEST after
> that.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
I put the patch in front of Yamada-
On 19 December 2017 at 04:56, Masahiro Yamada
wrote:
> Hi Ulf,
>
>
> 2017-12-15 18:18 GMT+09:00 Ulf Hansson :
>> On 24 November 2017 at 17:24, Masahiro Yamada
>> wrote:
>>>
>>> I am working on this IP for Socionext SoCs.
>>>
>>> I
is prevented in the system suspend phases. However, by
avoiding to enable runtime PM, this problem goes away.
Signed-off-by: Ulf Hansson
---
drivers/phy/phy-core.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/phy/phy-core.c b/dr
. For additional
background, please have look at the link below.
https://patchwork.kernel.org/patch/10086651/
Ulf Hansson (3):
phy: core: Move runtime PM reference counting to the parent device
phy: core: Drop unused runtime PM APIs
phy: core: Update the runtime PM section in the docs to
avoid to enabled runtime PM for
the phy child device, the APIs becomes NOOP. Therefore, let's remove them
altogether.
Signed-off-by: Ulf Hansson
---
drivers/phy/phy-core.c | 66 -
include/linux/phy/phy.h | 45 -
2
Let's update and clarify he phy documentation, to reflect the latest
changes around the runtime PM deployment in the phy core.
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
Documentation/phy.txt | 28 +++-
1 file changed, 15 inser
On 20 December 2017 at 07:42, Kishon Vijay Abraham I wrote:
> Hi Ulf,
>
> On Wednesday 20 December 2017 02:52 AM, Ulf Hansson wrote:
>> The runtime PM deployment in the phy core is a bit unnecessary complicated
>> and the main reason is because it operates on the phy device
On 20 December 2017 at 10:02, Kishon Vijay Abraham I wrote:
> Hi Ulf,
>
> On Wednesday 20 December 2017 02:05 PM, Ulf Hansson wrote:
>> On 20 December 2017 at 07:42, Kishon Vijay Abraham I wrote:
>>> Hi Ulf,
>>>
>>> On Wednesday 20 December 2017 02:52
On 20 December 2017 at 13:08, Ulf Hansson wrote:
> On 20 December 2017 at 10:02, Kishon Vijay Abraham I wrote:
>> Hi Ulf,
>>
>> On Wednesday 20 December 2017 02:05 PM, Ulf Hansson wrote:
>>> On 20 December 2017 at 07:42, Kishon Vijay Abraham I wrote:
>>
dundant to enable runtime PM for the
phy core device, so let's avoid doing that.
Signed-off-by: Ulf Hansson
---
drivers/phy/phy-core.c | 33 +++--
include/linux/phy/phy.h | 1 +
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/phy/phy-core.
Let's update and clarify he phy documentation, to reflect the latest
changes around the runtime PM deployment in the phy core.
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
Documentation/phy.txt | 29 -
1 file change
/10086651/
Ulf Hansson (3):
phy: core: Move runtime PM reference counting to the parent device
phy: core: Drop unused runtime PM APIs
phy: core: Update the runtime PM section in the docs to reflect
changes
Documentation/phy.txt | 29 --
drivers/phy/phy-core.c
The phy core already deploys runtime PM support, so there seems to be no
obvious reason for having dedicated APIs to control runtime PM for phys.
Therefore, let's remove the APIs altogether and instead convert internal
needed functions to be static.
Signed-off-by: Ulf Hansson
---
driver
On 21 December 2017 at 02:43, Rafael J. Wysocki wrote:
> On Fri, Dec 15, 2017 at 4:56 PM, Ulf Hansson wrote:
>> The PM core in the device_prepare() phase, resets the wakeup_path status
>> flag to the value of device_may_wakeup(). This means if a ->prepare() or a
>> ->
On 21 December 2017 at 02:39, Rafael J. Wysocki wrote:
> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson wrote:
>> The runtime PM deployment in the phy core is deployed using the phy core
>> device, which is created by the phy core and assigned as a child device of
>> th
On 21 December 2017 at 11:33, Yoshihiro Shimoda
wrote:
> Hi Ulf-san,
>
>> -Original Message-----
>> From: Ulf Hansson, Sent: Wednesday, December 20, 2017 11:09 PM
>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index b4298a1..050b620
On 19 December 2017 at 14:34, Wolfram Sang
wrote:
> Because we started using io*_rep accessors previously because they are
> more widely defined across architectures, let's be consistent and use
> this family for all accessor wrappers.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
K
On 21 December 2017 at 13:24, Yoshihiro Shimoda
wrote:
>
>> From: Ulf Hansson, Sent: Thursday, December 21, 2017 7:58 PM
>>
>> On 21 December 2017 at 11:33, Yoshihiro Shimoda
>> wrote:
>> > Hi Ulf-san,
>> >
>> >> -Original Message--
On 22 December 2017 at 20:12, Rafael J. Wysocki wrote:
> On Thursday, December 21, 2017 11:13:57 AM CET Ulf Hansson wrote:
>> On 21 December 2017 at 02:43, Rafael J. Wysocki wrote:
>> > On Fri, Dec 15, 2017 at 4:56 PM, Ulf Hansson
>> > wrote:
>> >> Th
On 23 December 2017 at 02:35, Rafael J. Wysocki wrote:
> On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson wrote:
>> On 21 December 2017 at 02:39, Rafael J. Wysocki wrote:
>>> On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson wrote:
>>>> The runtime PM deployment in the
[...]
>
> So IMO the changes you are proposing make sense regardless of the
> genpd issue, because they generally simplify the phy code, but the
> additional use_runtime_pm field in struct phy represents redundant
> information (manipulating reference counters shouldn't matter if
> runtime PM is d
[...]
How many drivers actually do call device_set_wakeup_enable() during
suspend?
>>>
>>> There are some ethernet/wifi drivers, although it hard to say how many
>>> without a more thorough investigation.
>>>
>>> Besides those I found these more obvious ones:
>>> drivers/ssb/pcihost_wra
s behaviour.
These legacy cases should be corrected, however until that is done, let's
address the issue from the PM core, by moving the assignment of the
wakeup_path status flag to the __device_suspend() phase and after the
->suspend() callback has been invoked.
Signed-off-by: Ulf Hanss
series. That leads to a tree-wise-dependency, so perhaps Rafael can host
an immutable branch the Renesas tree can pull in. Let's see.
[1]
https://www.spinics.net/lists/linux-renesas-soc/msg20122.html
[2]
https://www.spinics.net/lists/linux-renesas-soc/msg19947.html
Ulf Hansson (4):
PM / core:
In case the WAKEUP_PATH flag has been set in a later phase than from the
->suspend() callback, the PM core don't set the ->power.wakeup_path status
flag for the device. Therefore, let's be safe and check it explicitly.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c
icitly, in
case it has been set after the ->suspend() callback has been invoked for
the device.
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 3 ++-
include/linux/pm.h| 7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/driv
p users to properly manage wakeup settings,
let's print a warning in cases someone calls device_wakeup_enable() during
system sleep.
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 4
drivers/base/power/wakeup.c | 4
include/linux/pm.h | 1 +
3 files change
: Geert Uytterhoeven
[Ulf: Converted to use the WAKEUP_PATH driver PM flag]
Signed-off-by: Ulf Hansson
---
drivers/irqchip/irq-renesas-irqc.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/irqchip/irq-renesas-irqc.c
b/drivers/irqchi
27;s do that as well.
Signed-off-by: Geert Uytterhoeven
[Ulf: Converted to use the WAKEUP_PATH driver PM flag]
Signed-off-by: Ulf Hansson
---
drivers/gpio/gpio-rcar.c | 40 +++-
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/gpio/gpio-r
27;s do that as well.
Signed-off-by: Geert Uytterhoeven
[Ulf: Converted to use the WAKEUP_PATH driver PM flag]
Signed-off-by: Ulf Hansson
---
drivers/irqchip/irq-renesas-intc-irqpin.c | 42 +++
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/irqc
From: Geert Uytterhoeven
Changes in v2: [By Ulf Hansson]
- I have picked up the series from Geert [1] and converted it into use
the WAKEUP_PATH driver PM flag. This includes some minor changes to each
patch and updates to the changelogs.
- An important note, the
On 30 December 2017 at 01:44, Rafael J. Wysocki wrote:
> On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson wrote:
>> The PM core in the device_prepare() phase, resets the wakeup_path status
>> flag to the value of device_may_wakeup(). This means if a ->prepare() or a
>> ->
On 30 December 2017 at 01:47, Rafael J. Wysocki wrote:
> On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson wrote:
>> In case the WAKEUP_PATH flag has been set in a later phase than from the
>> ->suspend() callback, the PM core don't set the ->power.wakeup_path sta
On 30 December 2017 at 01:58, Rafael J. Wysocki wrote:
> On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson wrote:
>> In general, wakeup settings are not supposed to be changed during any of
>> the system wide PM phases. The reason is simply that it would break
>> guarantees pr
On 2 January 2018 at 11:48, Rafael J. Wysocki wrote:
> On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven
> wrote:
>> Hi Rafael,
>>
>> On Tue, Jan 2, 2018 at 11:32 AM, Rafael J. Wysocki wrote:
>>> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wro
>>> Signed-off-by: Geert Uytterhoeven
>>> [Ulf: Converted to use the WAKEUP_PATH driver PM flag]
>
> Ulf: + killing the DEV_PM_OPS define, increasing kernel size if PM_SUSPEND=n?
Oh, yes - correct!
The code looks nicer, with the penalty of one static struct declared
and not used, in case CONFIG_
On 2 January 2018 at 12:43, Rafael J. Wysocki wrote:
> On Tuesday, January 2, 2018 12:36:55 PM CET Ulf Hansson wrote:
>> On 30 December 2017 at 01:44, Rafael J. Wysocki wrote:
>> > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson
>> > wrote:
>> >> The PM cor
On 24 December 2017 at 13:00, Rafael J. Wysocki wrote:
> On Saturday, December 23, 2017 4:09:33 PM CET Ulf Hansson wrote:
>> [...]
>>
>> >
>> > So IMO the changes you are proposing make sense regardless of the
>> > genpd issue, because they generally simp
On 2 January 2018 at 14:53, Geert Uytterhoeven wrote:
> On Tue, Jan 2, 2018 at 1:53 PM, Ulf Hansson wrote:
>> On 2 January 2018 at 11:48, Rafael J. Wysocki wrote:
>>> On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven
>>> wrote:
>>>> On Tue, Jan
akeup_path().
Typically a driver that manages a resource needed in the wakeup path,
should call device_set_wakeup_path() from its ->suspend() or
->suspend_late() callback.
Signed-off-by: Ulf Hansson
---
include/linux/pm_wakeup.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/inc
s behaviour.
These legacy cases should be corrected, however until that is done, let's
address the issue from the PM core, by moving the assignment of the
wakeup_path status flag to the __device_suspend() phase and after the
->suspend() callback has been invoked.
Signed-off-by: Ulf Hanss
p users to properly manage wakeup settings,
let's print a warning in cases someone calls device_wakeup_enable() during
system sleep.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Ulf Hansson
---
drivers/base/power/wakeup.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base
rom a ->suspend_late() callback, its value doesn't get propagated to the
parent by the PM core. Let's address this limitation, by also propagating
the flag at __device_suspend_late().
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 33 +
1
ately needed
to fix the problems for the Renesas SoCs.
Ulf Hansson (4):
PM / core: Assign the wakeup_path status flag in __device_prepare()
PM / core: Propagate wakeup_path status flag in
__device_suspend_late()
PM / wakeup: Add device_set_wakeup_path() helper to control wakeup
path
On 5 January 2018 at 13:57, Rafael J. Wysocki wrote:
> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson wrote:
>> Currently the wakeup_path status flag becomes propagated from a child
>> device to its parent device at __device_suspend(). This allows a driver
>> dealing with a pa
On 6 January 2018 at 00:57, Rafael J. Wysocki wrote:
> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson wrote:
>> In general, wakeup settings are not supposed to be changed during any of
>> the system wide PM phases. The reason is simply that it would break
>> guarantees provid
p users to properly manage wakeup settings,
let's print a warning in cases someone calls device_wakeup_enable() during
system sleep.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Ulf Hansson
---
Changes in v4:
- Send this as a separate change.
- Changed from dev_wa
Changes in v4:
- Dropped the changes that already been applied.
- Patch 1 is new, should not introduce any functional changes, but only
structural code changes, as requested by Rafael.
- Patch 2, re-based on top of new patch.
Ulf Hansson (2):
PM / core: Re
rom a ->suspend_late() callback, its value doesn't get propagated to the
parent by the PM core. Let's address this limitation, by also propagating
the flag at __device_suspend_late().
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 31 ---
1
s, to make them self-explanatory. Like this:
dpm_clear_suppliers_direct_complete -> dpm_clear_superiors_direct_complete
dpm_propagate_to_parent -> dpm_propagate_wakeup_to_parent
Signed-off-by: Ulf Hansson
---
drivers/base/power/main.c | 15 ++-
1 file changed, 10 insertions(+),
oduce a helper function, device_set_no_inband_wakeup(),
which drivers shall use to set/clear the ->dev.power.no_inband_wakeup flag.
Signed-off-by: Ulf Hansson
---
To get some additional background, one may look at earlier discussions from
various threads. The most recent is in and RFD [1] from Rafael and from an mmc
s
On 9 January 2018 at 14:37, Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> One of the limitations of pm_runtime_force_suspend/resume() is that
>> if a parent driver wants to use these functions, all of its chi
On 9 January 2018 at 17:28, Rafael J. Wysocki wrote:
> On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote:
>> On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven
>> wrote:
>> > Hi Rafael,
>> >
>> > CC usb
>> >
>> > On Tue, Jan 9, 2018 at 4:00 PM, Rafael J. Wysocki
>> > wrote:
>>
[...]
>>> Index: linux-pm/drivers/base/power/domain.c
>>> ===
>>> --- linux-pm.orig/drivers/base/power/domain.c
>>> +++ linux-pm/drivers/base/power/domain.c
>>> @@ -1048,8 +1048,9 @@ static int genpd_finish_suspend(struct d
>>>
On 24 November 2017 at 17:24, Masahiro Yamada
wrote:
> To use a GPIO line for card detection, TMIO_MMC_USE_GPIO_CD is set
> by a legacy board (arch/sh/boards/mach-ecovec24).
>
> For DT platforms, the "cd-gpios" property is a legitimate way for that
> in case the IP-builtin card detection can not b
On 15 January 2018 at 14:22, Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Mon, Jan 15, 2018 at 9:16 AM, Geert Uytterhoeven
> wrote:
>> On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki wrote:
>>> On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
>>> wrote:
On Sat, Jan 13, 2018 at 1:38
resume on R-Car Gen3.
>
> Make this explicit by using pm_runtime_force_{suspend,resume}() as the
> system sleep callbacks instead. Use SET_LATE_SYSTEM_SLEEP_PM_OPS() as
> DMA engines must be initialized before all DMA slave devices.
>
> Suggested-by: Ulf Hansson
> Signed-off-
On 17 January 2018 at 17:28, Masahiro Yamada
wrote:
>
> In the previous batch (https://lkml.org/lkml/2017/11/24/428)
> I sent 22 patches for TMIO MMC.
>
> 14 patches were applied, the rest is under discussion.
>
> This series consists of 16 patches.
>
> Patch 1-4: repost from v2.
> (W
On 30 January 2018 at 14:24, Geert Uytterhoeven wrote:
> If NO_DMA=y:
>
> ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko]
> undefined!
> ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_internal_dmac.ko]
> undefined!
>
> Add dependencies on HAS_DMA to fix this.
>
> Fi
path i.s.o. explicit clock handling
> gpio: rcar: Use wakeup_path i.s.o. explicit clock handling
>
> drivers/gpio/gpio-rcar.c | 38 +
> drivers/irqchip/irq-renesas-intc-irqpin.c | 40
> +------
> drivers/
On 7 February 2018 at 20:11, Wolfram Sang wrote:
>
>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>> rc9, let's aim for 4.17 for the rest.
>
> I can't find the branch where you picked these patches? I wanted to use
> it to apply the rest of the patches. They don't seem t
On 14 February 2018 at 10:43, Masahiro Yamada
wrote:
> Hi Ulf,
>
>
> 2018-02-14 18:36 GMT+09:00 Ulf Hansson :
>> On 7 February 2018 at 20:11, Wolfram Sang wrote:
>>>
>>>> I picked patch5 and patch6, as those seemed trivial. Unless there is a
>>>&
On 5 February 2018 at 14:28, Wolfram Sang
wrote:
> The TODO section from 2010 is obsolete. We have DMA and PM meanwhile and
> we always want to handle errors better, if possible. Also DRIVER_VERSION
> is not used anymore these days.
>
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind
On 14 February 2018 at 11:23, Wolfram Sang wrote:
>
>> You need to check again. :-)
>
> Seems like it. Sorry for the noise.
>
>> I am eager to apply those patches you already have reviewed (to
>> patch14), as those mostly seemed rather trivial and should be nice
>> cleanups.
>>
>> Do you mind me g
1 - 100 of 367 matches
Mail list logo
