[PATCH v2 3/4] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

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 <ulf.hans...@linaro.org> --- driver

[PATCH v2 2/4] PM / core: Add WAKEUP_PATH driver flag

itly, in case it has been set after the ->suspend() callback has been invoked for the device. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 3 ++- include/linux/pm.h| 7 +++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drive

[PATCH v2 4/4] PM / core: Print warn if device gets enabled as wakeup source during sleep

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 <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 4 drivers/base/power/wakeup.c | 4 include/linux/pm.h | 1 + 3

[PATCH v2 0/4] PM / core: Extend behaviour for wakeup paths

o 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: Assign the wakeup_pat

[PATCH v2 1/4] PM / core: Assign the wakeup_path status flag in __device_prepare()

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 Hansson <ulf.hans..

Re: [PATCH 1/3] PM / core: Assign the wakeup_path status flag in __device_prepare()

[...] 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: >>>

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

[...] > > 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

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On 23 December 2017 at 02:35, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Thu, Dec 21, 2017 at 11:50 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 21 December 2017 at 02:39, Rafael J. Wysocki <raf...@kernel.org> wrote: >>> On Wed, Dec 20, 20

Re: [PATCH 1/3] PM / core: Assign the wakeup_path status flag in __device_prepare()

On 22 December 2017 at 20:12, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Thursday, December 21, 2017 11:13:57 AM CET Ulf Hansson wrote: >> On 21 December 2017 at 02:43, Rafael J. Wysocki <raf...@kernel.org> wrote: >> > On Fri, Dec 15, 2017 at 4:56 PM, Ulf H

Re: [PATCH v2 2/3] phy: core: Drop unused runtime PM APIs

On 21 December 2017 at 13:24, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > >> From: Ulf Hansson, Sent: Thursday, December 21, 2017 7:58 PM >> >> On 21 December 2017 at 11:33, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com> wrote: &g

Re: [PATCH] mmc: tmio: use io* accessors consistently

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

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On 21 December 2017 at 02:39, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Wed, Dec 20, 2017 at 3:09 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> The runtime PM deployment in the phy core is deployed using the phy core >> device, which is created by the phy c

Re: [PATCH 1/3] PM / core: Assign the wakeup_path status flag in __device_prepare()

On 21 December 2017 at 02:43, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 15, 2017 at 4:56 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> The PM core in the device_prepare() phase, resets the wakeup_path status >> flag to the value of devi

[PATCH v2 0/3] phy: core: Re-work runtime PM deployment and fix an issue

/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

[PATCH v2 2/3] phy: core: Drop unused runtime PM APIs

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 <ulf.h

[PATCH v2 3/3] phy: core: Update the runtime PM section in the docs to reflect changes

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 <cor...@lwn.net> Cc: linux-...@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- Documentation/

[PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

to enable runtime PM for the phy core device, so let's avoid doing that. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/phy/phy-core.c | 33 +++-- include/linux/phy/phy.h | 1 + 2 files changed, 16 insertions(+), 18 deletions(-) diff --git a/drive

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

On 20 December 2017 at 13:08, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 20 December 2017 at 10:02, Kishon Vijay Abraham I <kis...@ti.com> wrote: >> Hi Ulf, >> >> On Wednesday 20 December 2017 02:05 PM, Ulf Hansson wrote: >>> On 20 December

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

On 20 December 2017 at 10:02, Kishon Vijay Abraham I <kis...@ti.com> 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 <kis...@ti.com> wrote: >>> Hi Ulf, >>> &g

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

On 20 December 2017 at 07:42, Kishon Vijay Abraham I <kis...@ti.com> 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 operat

[PATCH 0/3] phy: core: Re-work runtime PM deployment and fix an issue

. 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

[PATCH 2/3] phy: core: Drop unused runtime PM APIs

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 <ulf.hans...@linaro.org> --- drivers/phy/phy-core.c | 66 - include/linux/phy/phy.

[PATCH 3/3] phy: core: Update the runtime PM section in the docs to reflect changes

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 <cor...@lwn.net> Cc: linux-...@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- Documentation/

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

On 19 December 2017 at 04:56, Masahiro Yamada <yamada.masah...@socionext.com> wrote: > Hi Ulf, > > > 2017-12-15 18:18 GMT+09:00 Ulf Hansson <ulf.hans...@linaro.org>: >> On 24 November 2017 at 17:24, Masahiro Yamada >> <yamada.masah...@socionext.com&

Re: [RFC PATCH] mmc: tmio: use ioread* for repeated access to a register

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

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

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

Re: [PATCH 3/3] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

On 15 December 2017 at 16:56, Ulf Hansson <ulf.hans...@linaro.org> 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, el

[PATCH 3/3] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

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 <ulf.hans...@linaro.org> --- driver

[PATCH 0/3] PM / core: Extend behaviour for wakeup paths

-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 genpd drivers/base/power

[PATCH 2/3] PM / core: Add WAKEUP_PATH driver flag

itly, in case it has been set after the ->suspend() callback has been invoked for the device. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 3 ++- include/linux/pm.h| 7 +++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drive

[PATCH 1/3] PM / core: Assign the wakeup_path status flag in __device_prepare()

ssignment 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 <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

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

Re: [PATCH] mmc: renesas_sdhi: Add MODULE_LICENSE

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

Re: [PATCH v2 00/22] mmc: tmio: various fixes and cleanups

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

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

On 14 December 2017 at 11:52, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 11 December 2017 at 11:48, Geert Uytterhoeven <ge...@linux-m68k.org> >> wrote: &g

Re: [PATCH v2 3/3] soc: renesas: rcar-sysc: Keep wakeup sources active during system suspend

FLAG_ACTIVE_WAKEUP flag. > > Note that this will only affect devices configured as wakeup sources. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> Kind regards Uffe > --- > v2: > - Integrate "soc:

Re: [PATCH v2 1/3] clk: renesas: mstp: Keep wakeup sources active during system suspend

e that this will only affect devices configured as wakeup sources. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> Kind regards Uffe > --- > v2: > - Integrate "clk: renesas: mstp: Use GENPD_FLAG_ACTI

Re: [PATCH v2 2/3] clk: renesas: cpg-mssr: Keep wakeup sources active during system suspend

e that this will only affect devices configured as wakeup sources. > > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> Kind regards Uffe > --- > v2: > - Integrate "clk: renesas: cpg-mssr: Use GENPD_FLAG

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

On 12 December 2017 at 09:16, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> That together with an option of allowing "consumed resource-devices" >> (irqch

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

On 11 December 2017 at 11:48, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Mon, Dec 11, 2017 at 11:24 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 10 December 2017 at 11:16, Geert Uytterhoeven <ge...@linux-m68k.org> >> wro

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

On 10 December 2017 at 11:16, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, Ulf, > > On Sun, Dec 10, 2017 at 3:30 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Monday, November 13, 2017 4:46:42 PM CET Ulf Hansson wrote: >>> For

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

On 10 December 2017 at 03:30, Rafael J. Wysocki <r...@rjwysocki.net> 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 unders

Re: [PATCH] mmc: core: properly init drv_type

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

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 5 December 2017 at 04:23, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM >> >> On 1 December 2017 at 12:03, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com>

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 1 December 2017 at 12:03, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Friday, December 1, 2017 6:22 PM >> >> + Kishon >> >> On 30 November 2017 at 13:51, Yoshihiro Shimoda >> <yoshihiro.shim

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

+ Kishon On 30 November 2017 at 13:51, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 6:59 PM >> >> On 29 November 2017 at 10:43, Geert Uytterhoeven <ge...@linux-m68k.org> &

Re: [PATCH v2 0/2] R-Car D3 (r8a77995) SDHI (eMMC) integration

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

Re: [PATCH v2 1/2] mmc: renesas_sdhi: enable R-Car D3 (r8a77995) support

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

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 29 November 2017 at 10:43, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Wed, Nov 29, 2017 at 10:24 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 29 November 2017 at 09:21, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com&

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

On 29 November 2017 at 09:21, Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> wrote: > Hi, > >> From: Ulf Hansson, Sent: Wednesday, November 29, 2017 2:23 AM >> >> On 28 November 2017 at 13:48, Yoshihiro Shimoda >> <yoshihiro.shimoda...@renesas.com>

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

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:

Re: [PATCH 4/4] dt-bindings: mmc: renesas_sdhi: Add r8a77995 support

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 > --- >

Re: [PATCH RFT] mmc: core: use usleep_range rather than HZ magic in mmc_delay()

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

Re: [PATCH RFT] mmc: tmio: use usleep_range consistently

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

Re: [PATCH RFT] mmc: core: use usleep_range rather than HZ magic in mmc_delay()

On 16 November 2017 at 08:59, Shawn Lin <shawn@rock-chips.com> wrote: > Hi, > > On 2017/11/16 15:47, Ulf Hansson wrote: >> >> On 14 November 2017 at 23:55, Wolfram Sang >> <wsa+rene...@sang-engineering.com> wrote: >>> >>> Documentati

Re: [PATCH RFT] mmc: core: use usleep_range rather than HZ magic in mmc_delay()

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

Re: [PATCH v2 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

On 13 November 2017 at 16:46, Ulf Hansson <ulf.hans...@linaro.org> 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 t

[PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

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 <ulf.hans...@linaro.org> --- Changes in v2: - Fixed comments from Rafael:

[PATCH v2 3/3] PM / Domains: Take wakeup_path_in_band status flag into account

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 <ulf.h

[PATCH v2 1/3] PM / core: Re-factor some code dealing with parents in __device_suspend()

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 <ulf.hans...@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> --- C

[PATCH v2 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

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 (3): PM

Re: [PATCH v2 0/3] PM / Domain: renesas: Fix active wakeup behavior

On 10 November 2017 at 14:22, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Fri, Nov 10, 2017 at 1:49 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 10 November 2017 at 11:22, Geert Uytterhoeven <ge...@linux-m68k.org> >> wrote: &g

Re: [PATCH v2 0/3] PM / Domain: renesas: Fix active wakeup behavior

On 10 November 2017 at 11:22, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Fri, Nov 10, 2017 at 10:57 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 9 November 2017 at 14:26, Geert Uytterhoeven <geert+rene...@glider.be> >> wrot

Re: [PATCH v2 0/3] PM / Domain: renesas: Fix active wakeup behavior

On 9 November 2017 at 14:26, Geert Uytterhoeven wrote: > Hi Rafael, Ulf, Kevin, > > If a device in a Renesas ARM SoC is part of a Clock Domain, and it is > used as a wakeup source, it must be kept active during system suspend. Geert, I think we discussed this a

Re: [PATCH 2/3] PM / core: Add WAKEUP_POWERED driver flag

[...] >>> >>> First off, how does the driver know that the device has to be in full >>> power for wakeup to work? >> >> Because the device is accessed as part of dealing with the wakeup. > > Yes, it is, In the working state of the system. In the system wakeup > case it may not be. > >

Re: [PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

On 9 November 2017 at 17:31, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Thu, Nov 9, 2017 at 3:41 PM, Geert Uytterhoeven <ge...@linux-m68k.org> > wrote: >> Hi Ulf, >> >> On Thu, Nov 9, 2017 at 3:28 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: &g

Re: [PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

[...] >>> The Ethernet driver can still call device_set_wakeup_enable(... , false) >>> to control this. If WoL is disabled by the user (or deemed not usable, see >>> below), it already does so. >> >> I don't think that API is intended to be used like that and I wonder >> if it even works as

Re: [PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

On 9 November 2017 at 10:02, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 8 November 2017 at 16:41, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: >>> O

Re: [PATCH 2/3] PM / core: Add WAKEUP_POWERED driver flag

On 9 November 2017 at 01:41, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> For some bus types and PM domains, it's not sufficient to only check the >> return value from device_may_wakeup

Re: [PATCH 2/3] PM / core: Add WAKEUP_POWERED driver flag

On 9 November 2017 at 01:24, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> For some bus types and PM domains, it's not sufficient to only check the >> return value from device_may_wakeup

Re: [PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

On 8 November 2017 at 16:41, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> The generic problem this series is trying to solve, is that for some bus >> types >&

[PATCH 1/3] PM / core: Re-factor some code dealing with parents in __device_suspend()

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 <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 29 + 1 file c

[PATCH 2/3] PM / core: Add WAKEUP_POWERED driver flag

has the "ignore_children" flag set. This makes it also consistent with how the existing "wakeup_path" flag is being assigned. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- Documentation/driver-api/pm/devices.rst | 12 drivers/base/power

[PATCH 3/3] PM / Domains: Take WAKEUP_POWERED driver flag into account

Make genpd to take the WAKEUP_POWERED driver flag into account during system suspend/resume. More precisely, in case the WAKEUP_POWERED flag is set, let's leave the device in full power state and prevent the PM domain from being powered off. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.

[PATCH 0/3] PM / core: Invent a WAKEUP_POWERED driver flag

.html Ulf Hansson (3): PM / core: Re-factor some code dealing with parents in __device_suspend() PM / core: Add WAKEUP_POWERED driver flag PM / Domains: Take WAKEUP_POWERED driver flag into account Documentation/driver-api/pm/devices.rst | 12 drivers/base/power/domain.c

Re: [PATCH] mmc: tmio: Replace msleep() of 20ms or less with usleep_range()

On 3 November 2017 at 10:36, Simon Horman wrote: > From: Masaharu Hayakawa > > As documented in Documentation/timers/timers-howto.txt > as follows, replace msleep() with usleep_range(). > > msleep(1~20) may not do what the caller

Re: [PATCH v2 0/5] PM / Domains: Remove gpd_dev_ops.active_wakeup() callback

tive platform trees in v4.16. > Then the final patch has to be postponed until v4.17. > Alternatively, everything can go in through the PM tree in one shot. For the series: Acked-by: Ulf Hansson <ulf.hans...@linaro.org> It's easier if everything goes via Rafael's PM tree. Moreover,

Re: [PATCH] PM / QoS: Fix default runtime_pm device resume latency

On 31 October 2017 at 14:55, Geert Uytterhoeven wrote: > Hi Rafael, Tero, > > CC pinchartl, dri-devel > > On Tue, Oct 31, 2017 at 2:10 PM, Geert Uytterhoeven > wrote: >> CC linux-renesas-soc >> >> On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven >>

Re: [PATCH 00/10] PM / Domain: renesas: Fix active wakeup behavior

On 16 October 2017 at 15:55, Geert Uytterhoeven wrote: > Hi all, > > If a device in a Renesas ARM SoC is part of a Clock Domain, and it is > used as a wakeup source, it must be kept active during system suspend. > > Currently this is handled in device-specific

Re: [PATCH v2 0/2] mmc: renesas_sdhi and tmio: bugfixes for v4.14

On 20 October 2017 at 05:12, Yoshihiro Shimoda wrote: > This patch set is based on mainline v4.14-rc5. > > Changes from v1: > - Calculate the max size of swiotlb memory instead of hardcoded value >in patch 1. > - Add Reviewed-by from Geert-san in patch 2.

Re: [PATCH v3 3/3] arm64: renesas: salvator: set driver type for eMMC

On 16 October 2017 at 09:46, Simon Horman wrote: > On Sun, Oct 15, 2017 at 02:46:15PM +0200, Wolfram Sang wrote: >> These boards are known to have eMMC issues with the default driver type. >> Specify a working one. >> >> Signed-off-by: Wolfram Sang

Re: [PATCH v4 0/3] mmc: renesas_sdhi: add R-Car Gen[123] fallback compatibility strings

On 18 October 2017 at 09:00, Simon Horman wrote: > Add fallback compatibility strings for R-Car Gen 1, 2 and 3 to the SDHI > bindings and driver. > > In the case of Renesas R-Car hardware we know that there are generations of > SoCs, f.e. Gen 1 and 2. But beyond that

Re: [PATCH v2 00/11] mmc: document mmc_regulator_get_supply and fix users

On 14 October 2017 at 21:17, Wolfram Sang wrote: > Fix the drivers and add some docs according to the outcome of this discussion > [1] we had recently. The motivation from the patch description: > > Bail out everytime when mmc_regulator_get_supply() returns an

Re: [PATCH v3 2/3] mmc: parse new binding for eMMC fixed driver type

On 15 October 2017 at 14:46, Wolfram Sang wrote: > Parse the new binding and store it in the host struct after doing some > sanity checks. The code is designed to support fixed SD driver type if > we ever need that. > > Signed-off-by: Wolfram Sang

Re: [PATCH v3 1/3] dt-bindings: mmc: describe new eMMC binding for fixed driver type

On 15 October 2017 at 14:46, Wolfram Sang wrote: > Some boards may have to use a certain driver type (or drive strength) to > achieve stable eMMC communication. Describe a binding to set this up via > DT. > > Signed-off-by: Wolfram Sang

Re: [RFC PATCH] mmc: tmio: check mmc_regulator_get_supply return value

On 22 September 2017 at 13:22, Fabrizio Castro wrote: > mmc_regulator_get_supply returns -EPROBE_DEFER if either vmmc or > vqmmc regulators had their probing deferred. > vqmmc regulator is needed by UHS to work properly, therefore this > patch checks the value

Re: [RFC PATCH] mmc: sunxi: drop superfluous error message

On 8 October 2017 at 16:50, Wolfram Sang wrote: > This error message can go because a) currently nothing else than > EPROBE_DEFER is returned and b) if this is going to change a much more > detailed error message should come from mmc_regulator_get_supply() >

Re: [PATCH 00/11] mmc: document mmc_regulator_get_supply and fix users

On 7 October 2017 at 12:36, Wolfram Sang wrote: > Fix the drivers and add some docs according to the outcome of this discussion > [1] we had recently. The motivation from the patch description: > > Bail out everytime when mmc_regulator_get_supply() returns an

Re: [RFC PATCH] mmc: tmio: check mmc_regulator_get_supply return value

[...] >> >> Well, the good news is that it didn't cause a regression for me on R-Car >> E2 (Alt board) and H3 (Salvator X board). >> >> Sadly, it doesn't also fix the SDR104 problems on Alt. I had a little >> hope this could be the culprit, but sadly it is not. But this is not a >> problem with

Re: [PATCH v2 2/3] mmc: parse new binding for eMMC fixed driver type

On 4 October 2017 at 19:39, Wolfram Sang wrote: > Parse the new binding and store it in the host struct after doing some > sanity checks. The code is designed to support fixed SD driver type if > we ever need that. > > Signed-off-by: Wolfram Sang

Re: [PATCH] mmc: sdhci-pci: remove outdated declaration

On 15 September 2017 at 20:13, Wolfram Sang wrote: > The function was removed half a year ago, so this declaration can go, > too. > > Fixes: 51ced59cc02e0d ("mmc: sdhci-pci: Use ACPI DSM to get driver strength > for some Intel devices") > Signed-off-by: Wolfram

Re: [PATCH] mmc: tmio: remove broken and noisy debug macro

On 14 September 2017 at 14:30, Wolfram Sang wrote: > Some change for v4.14 broke the debug output for TMIO. But since it was > not helpful to me and too noisy for my taste anyhow, let's just remove > it instead of fixing it. We'll find something better if we'd

Re: [RFC PATCH 0/3] mmc: support eMMC driver type selection with DT

On 15 September 2017 at 20:02, Wolfram Sang wrote: > Some of the Renesas R-Car boards need to set the eMMC driver type to type 1 to > get stable HS200/400 speeds (HS400 support not upstream yet). Because the eMMC > memories are fixed (and thus the drive type), I

Re: [PATCH] mmc: host: fix typo after MMC_DEBUG move

On 5 September 2017 at 20:27, Wolfram Sang wrote: > MMC_DEBUG was moved and one letter got strangely capitalized. > > Signed-off-by: Wolfram Sang Thanks, applied for fixes! Kind regards Uffe > --- > > based on mmc/next > >

Re: [PATCH RESEND] mmc: renesas_sdhi: Add r8a7743/5 support

On 29 August 2017 at 15:52, Biju Das wrote: > Add support for r8a7743/5 SoC.Renesas RZ/G1[ME] (R8A7743/5) SDHI > is identical to the R-Car Gen2 family. > > Signed-off-by: Biju Das Thanks, applied for next! Kind regards Uffe > --- > DT binding

Re: [PATCH v3] mmc: renesas_sdhi: Add r8a7743/5 support

On 21 August 2017 at 14:25, Biju Das wrote: > Add support for r8a7743/5 SoC. Renesas RZ/G1[ME] (R8A7743/5) SDHI > is identical to the R-Car Gen2 family. > > Signed-off-by: Biju Das Thanks, applied for next! Kind regards Uffe > --- > v1->v2 >

Re: [PATCH v2] mmc: sdhi: use maximum width for the sdbuf register

On 9 August 2017 at 20:29, Wolfram Sang wrote: > Make use of the 64 bit sdbuf width on Renesas R-Car Gen3. If the > registers are 8 byte apart, the width is also 64 bit. For all others, > the width is 32 bit, even if the registers are only 16 bit apart. > >

Re: [RFT 0/2] mmc: renesas_sdhi: small patches for RZ/A1

On 9 August 2017 at 21:14, Wolfram Sang wrote: > Here is a small series to improve RZ support for SDHI. I don't have that > platform currently, so I hope Chris has some time to check these simple > patches. It is based on top of the patch just sent out: >

Re: [PATCH] Revert "mmc: sdhi: use maximum width for the sdbuf register"

On 3 August 2017 at 11:53, Wolfram Sang wrote: > On Thu, Aug 03, 2017 at 11:49:47AM +0200, Wolfram Sang wrote: >> This reverts commit 785b215250310c690142abb1bdbb0767b8487c49. There is a >> secondary SDHI instance on Gen2 with has a 32-bit wide SDBUF register >> while all

Re: [PATCH mmc/next] mmc: renesas-sdhi: provide a whitelist for Gen3 SoC ES versions

On 2 August 2017 at 14:48, Simon Horman wrote: > Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and > internal DMAC variants of the SDHI driver. This is to allow drivers to > only initialise for Gen3 SoC ES versions for which they are the

<    1   2   3   >