Re: [PATCH 10/10] cpufreq: dt: Add support for r8a7744

On Tuesday, September 25, 2018 10:16:12 AM CEST Biju Das wrote: > Hi Rafeal, > > Sorry to bother you. Are you happy to merge the below patch with 4.20 > > https://patchwork.kernel.org/patch/10595451/ Yes. You had told me that you wanted me to apply it, so I queued it up. Thanks, Rafael

Re: [PATCH 10/10] cpufreq: dt: Add support for r8a7744

On Tue, Sep 11, 2018 at 12:20 PM Biju Das wrote: > > Add the compatible strings for supporting the generic cpufreq driver on > the Renesas RZ/G1N (R8A7744) SoC. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- > drivers/cpufreq/cpufreq-dt-platdev.c | 1 + > 1 file changed, 1

Re: [PATCH 0/2] Revert explicit support for Renesas R-Car Gen 3 r8a779[56] SoCs

On Tue, May 15, 2018 at 9:35 AM, Simon Horman <ho...@verge.net.au> wrote: > On Thu, May 10, 2018 at 11:51:38AM +0200, Rafael J. Wysocki wrote: >> On Wednesday, May 2, 2018 11:58:04 AM CEST Simon Horman wrote: >> > Revert commits that added explicit support for Renesas R-

Re: [PATCH 0/2] Revert explicit support for Renesas R-Car Gen 3 r8a779[56] SoCs

On Wednesday, May 2, 2018 11:58:04 AM CEST Simon Horman wrote: > Revert commits that added explicit support for Renesas R-Car Gen 3 > r8a779[56] SoCs to the generic cpufreq driver. > > This is no longer needed since the flowing commit and to the best of my > knowledge is not relied on by any

Re: [PATCH/RFC 1/2] PM / wakeup: Add callback for wake-up change notification

On Mon, Apr 23, 2018 at 11:32 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Mon, Apr 23, 2018 at 11:18 AM, Rafael J. Wysocki <r...@rjwysocki.net> > wrote: >> On Wednesday, March 14, 2018 12:26:24 PM CEST Geert Uytterhoeven wrote: >>

Re: [PATCH/RFC 1/2] PM / wakeup: Add callback for wake-up change notification

First, sorry for the huge delay. On Wednesday, March 14, 2018 12:26:24 PM CEST Geert Uytterhoeven wrote: > Add a callback to inform a device that his wake-up setting has been > changed. This allows a device to synchronize device configuration with > an external user action. > > E.g. on systems

Re: [PATCH] dmaengine: rcar-dmac: Make DMAC reinit during system resume explicit

On Wednesday, January 17, 2018 11:19:17 AM CET Vinod Koul wrote: > On Wed, Jan 17, 2018 at 10:38:28AM +0100, Geert Uytterhoeven wrote: > > The current (empty) system sleep callbacks rely on the PM core to force > > a runtime resume to reinitialize the DMAC registers during system > > resume.

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On Wednesday, January 17, 2018 10:14:23 AM CET Geert Uytterhoeven wrote: > Hi Rafael, > > On Mon, Jan 15, 2018 at 5:17 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > > On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > >>

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson wrote: > On 15 January 2018 at 14:22, Geert Uytterhoeven wrote: [cut] >> >> I did miss a small difference in topology: in pm/linux-next, H3 has DMA >> enabled for SCIF2, while M3 hasn't (yet). >> With

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote: >>> On Fr

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote: > Hi Rafael, > > On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > > This comes from the recent discussion/testing effort that ensued after my > > pm_runtime_force_suspen

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Friday, January 12, 2018 12:26:56 PM CET Geert Uytterhoeven wrote: > Hi Rafael, > > On Tue, Jan 9, 2018 at 5:28 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > > On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: > >> On Tue, Jan 9, 2018 at 4

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Thu, Jan 11, 2018 at 1:32 PM, Ulf Hansson wrote: [cut] >>> >>> The point is, we can go for this solution, but is it good enough? >> >> I would like to treat it as a step away from what is there today, >> retaining some of the existing functionality. >> >> From a quick

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Wed, Jan 10, 2018 at 10:26 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 9 January 2018 at 17:28, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: >>> On Tue, Jan 9, 2018 at 4:30 PM, G

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Tue, Jan 9, 2018 at 7:46 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven <ge...@linux-m68k.org> > wrote: >> Hi Rafael, >> >> On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki <r...@rjwysocki.net&

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >> >> One of the l

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

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 <ge...@linux-m68k.org> > wrote: > > Hi Rafael, > > > > CC usb > > > > On Tue, Jan 9, 2018 at 4:00 PM, Rafael J. Wysocki <raf...@ker

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Tuesday, January 9, 2018 4:00:35 PM CET Rafael J. Wysocki wrote: > On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven <ge...@linux-m68k.org> > wrote: > > Hi Rafael, > > > > On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki <r...@rjwysocki.net> >

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > CC usb > > On Tue, Jan 9, 2018 at 4:00 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven <ge...@linux-m68k.org

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >> >> One of the l

Re: [PATCH] PM / wakeup: Enable option to specify wakeup as a non in-band wakeup

On Tuesday, January 9, 2018 11:54:11 AM CET Ulf Hansson wrote: > In some cases, a driver may not require its device to be powered on to be > able to deliver wakeup signals during system suspend. That quite often is the case. It is the standard way wakeup signaling works in PCI and in ACPI. >

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

On Mon, Jan 8, 2018 at 12:13 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 6 January 2018 at 00:57, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>> In general, wakeup set

Re: [PATCH v3 3/4] PM / wakeup: Add device_set_wakeup_path() helper to control wakeup path

On Tuesday, January 2, 2018 5:08:52 PM CET Ulf Hansson wrote: > During system suspend, a driver may find that the wakeup setting is enabled > for its device and therefore configures it to deliver system wakeup > signals. > > Additionally, sometimes the driver and its device, relies on some

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

ng on the wakeup source correctly, because a > dead device shouldn't deliver wakeup signals. > > To this reasoning and to help users to properly manage wakeup settings, > let's print a warning in cases someone calls device_wakeup_enable() during > system sleep. > > Suggested-

Re: [PATCH v3 2/4] PM / core: Propagate wakeup_path status flag in __device_suspend_late()

On Fri, Jan 5, 2018 at 6:12 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 5 January 2018 at 13:57, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>> Currently the wakeup_path

Re: [PATCH v3 2/4] PM / core: Propagate wakeup_path status flag in __device_suspend_late()

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 parent device to act on the flag from its ->suspend() >

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

On Tue, Jan 2, 2018 at 5:08 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 > ->suspend() callback for the device would update the device's wakeup

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

On Tue, Jan 2, 2018 at 12:46 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > On 30 December 2017 at 01:47, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>> In case the WAKEUP_PAT

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

On Tuesday, January 2, 2018 12:36:55 PM CET Ulf Hansson wrote: > On 30 December 2017 at 01:44, Rafael J. Wysocki <raf...@kernel.org> wrote: > > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson <ulf.hans...@linaro.org> > > wrote: > >> The PM core in the device_pre

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On Tue, Jan 2, 2018 at 11:44 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Tue, Jan 2, 2018 at 11:32 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable > when wake-up is enabled"), when a GPIO is used for wakeup, the GPIO block's > module

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On Tue, Jan 2, 2018 at 10:37 AM, Geert Uytterhoeven wrote: > Hi Linus, > > On Tue, Jan 2, 2018 at 10:27 AM, Linus Walleij > wrote: >> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: >>> From: Geert Uytterhoeven

Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

On Sun, Dec 31, 2017 at 10:22 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Sun, Dec 31, 2017 at 1:56 AM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>

Re: [PATCH v2 1/3] irqchip/renesas-intc-irqpin: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > From: Geert Uytterhoeven > > Since commit 705bc96c2c15313c ("irqchip: renesas-intc-irqpin: Add minimal > runtime PM support"), when an IRQ is used for wakeup, the INTC block's > module clock

Re: [PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote: > 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

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

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 provided by the PM core, to properly act on active wakeup >

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

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 status > flag for the device. Therefore, let's be safe and check it

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

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 > ->suspend() callback for the device would update the device's

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

On Saturday, December 23, 2017 4:17:58 PM CET Ulf Hansson wrote: > [...] > > 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. >

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

On Sat, Dec 23, 2017 at 1:50 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Sat, Dec 23, 2017 at 1:03 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 22 December 2017 at 20:12, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >>> On Thursday, December

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

On Sat, Dec 23, 2017 at 1:03 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > 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

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

On Sat, Dec 23, 2017 at 1:37 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > 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 2

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

On Thu, Dec 21, 2017 at 2:39 AM, 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 b

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

On Sat, Dec 23, 2017 at 2:35 AM, 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 v2 1/3] phy: core: Move runtime PM reference counting to the parent device

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, 2017 at 3:09 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >>> The runtime PM deployme

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

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 Hansson <ulf.hans...@linaro.org> wrote: > >> The PM core in the device_prepare()

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

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 > ->suspend() callback for the device would update the device's

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

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 > the phy provider device. > > The behaviour around the runtime PM

Re: [PATCH] bus: simple-pm-bus: convert bool SIMPLE_PM_BUS to tristate

On Friday, December 1, 2017 8:02:33 AM CET Simon Horman wrote: > On Thu, Nov 30, 2017 at 12:57:00PM +0100, Geert Uytterhoeven wrote: > > From: Paul Gortmaker > > > > The Kconfig currently controlling compilation of this code is: > > > > config SIMPLE_PM_BUS > >

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

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 > wakeup settings for the device during system suspend. > > In particular,

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

On Monday, November 13, 2017 4:46:41 PM CET Ulf Hansson wrote: > 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 >

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

On Tue, Dec 5, 2017 at 4:03 PM, Alan Stern wrote: > On Tue, 5 Dec 2017, Yoshihiro Shimoda wrote: > >> Hi, >> >> > From: Ulf Hansson, Sent: Monday, December 4, 2017 7:41 PM >> > >> > On 1 December 2017 at 12:03, Yoshihiro Shimoda >> >

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

On Tue, Nov 28, 2017 at 11:58 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, Shimoda-san, > > On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >

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

On Thu, Nov 9, 2017 at 3:41 PM, Geert Uytterhoeven wrote: > Hi Ulf, > > On Thu, Nov 9, 2017 at 3:28 PM, Ulf Hansson wrote: >> [...] >> > The Ethernet driver can still call device_set_wakeup_enable(... , false) > to control this. If WoL is

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

On Thu, Nov 9, 2017 at 12:59 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Thu, Nov 9, 2017 at 11:08 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 9 November 2017 at 10:02, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: >>> Hi Ulf, >>

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

On Thu, Nov 9, 2017 at 11:08 AM, Ulf Hansson wrote: > On 9 November 2017 at 10:02, Geert Uytterhoeven wrote: >> Hi Ulf, >> >> On Thu, Nov 9, 2017 at 9:28 AM, Ulf Hansson wrote: >>> On 8 November 2017 at 16:41, Geert

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

On Thu, Nov 9, 2017 at 9:53 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > 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

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

On Thu, Nov 9, 2017 at 9:44 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote: > 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

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

On Wed, Nov 8, 2017 at 4:15 PM, 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 treat the > device during system suspend. > > In particular, sometimes the

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

On Wed, Nov 8, 2017 at 4:15 PM, 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 treat the > device during system suspend. > > In particular, sometimes the

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

On Tuesday, November 7, 2017 1:48:10 PM CET Geert Uytterhoeven wrote: > Hi Rafael, Ulf, Kevin, > > It is quite common for PM Domains to require slave devices to be kept > active during system suspend if they are to be used as wakeup sources. > To enable this, currently each PM Domain or

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

[cut] >> It seems the default values for pm_qos have changed with the patch, and that >> breaks genpd at least. I only fixed PM runtime initially, but you could try >> this diff to fix the genpd part also: >> >> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h >> index

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

On Wed, Nov 1, 2017 at 11:28 AM, Tero Kristo <t-kri...@ti.com> wrote: > On 01/11/17 00:32, Rafael J. Wysocki wrote: >> >> On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> >>> Hi Rafael, >>>

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

On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: >> On Tue, Oct 31, 2017 at 2:55 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org>

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

Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki <r...@rjwysocki.net> >>> wrote: >>>> On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote: >&

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

Uytterhoeven >> <ge...@linux-m68k.org> wrote: >>> CC linux-renesas-soc >>> >>> On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven >>> <ge...@linux-m68k.org> wrote: >>>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki <r...@rj

Re: [PATCH] cpufreq: dt: Add r8a7796 support to to use generic cpufreq driver

On Wednesday, August 16, 2017 5:25:18 AM CEST Viresh Kumar wrote: > On 11-08-17, 17:36, Simon Horman wrote: > > From: Khiem Nguyen > > > > This patch adds the r8a7796 support the generic cpufreq driver > > by adding an appropriate compat string. This is in

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

On Monday, August 7, 2017 5:37:05 AM CEST Viresh Kumar wrote: > On 04-08-17, 15:18, Simon Horman wrote: > > From: Khiem Nguyen > > > > After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev > > driver", will use cpufreq-dt-platdev driver to enable

Re: [PATCH v3 2/8] PM / Domains: Handle safely genpd_syscore_switch() call on non-genpd device

On Tue, Jul 4, 2017 at 10:20 PM, Krzysztof Kozlowski <k...@kernel.org> wrote: > On Tue, Jul 04, 2017 at 10:12:13PM +0200, Rafael J. Wysocki wrote: >> On Tue, Jul 4, 2017 at 10:05 PM, Krzysztof Kozlowski <k...@kernel.org> wrote: > >> >> > Thanks for report!

Re: [PATCH v3 2/8] PM / Domains: Handle safely genpd_syscore_switch() call on non-genpd device

On Tue, Jul 4, 2017 at 10:05 PM, Krzysztof Kozlowski <k...@kernel.org> wrote: > On Tue, Jul 04, 2017 at 09:54:10PM +0200, Rafael J. Wysocki wrote: >> On Tue, Jul 4, 2017 at 8:36 PM, Krzysztof Kozlowski <k...@kernel.org> wrote: >> > On Tue, Jul 04, 2017 at 08:19:47PM +

Re: [PATCH v3 2/8] PM / Domains: Handle safely genpd_syscore_switch() call on non-genpd device

On Tue, Jul 4, 2017 at 8:36 PM, Krzysztof Kozlowski wrote: > On Tue, Jul 04, 2017 at 08:19:47PM +0200, Geert Uytterhoeven wrote: >> Hi Krzysztof, >> >> On Tue, Jul 4, 2017 at 8:10 PM, Krzysztof Kozlowski wrote: >> > On Tue, Jul 04, 2017 at 03:01:15PM +0200,

Re: PCI / PM: Crashes in PME scan during system suspend

On Tuesday, April 18, 2017 08:49:39 AM Geert Uytterhoeven wrote: > Hi Lukas, > > On Sun, Apr 16, 2017 at 9:55 AM, Lukas Wunner <lu...@wunner.de> wrote: > > On Sat, Apr 15, 2017 at 12:27:31AM +0200, Rafael J. Wysocki wrote: > >> On Friday, April 14, 2017

Re: PCI / PM: Crashes in PME scan during system suspend

On Friday, April 14, 2017 10:22:49 AM Lukas Wunner wrote: > On Tue, Feb 14, 2017 at 12:26:01PM +0100, Rafael J. Wysocki wrote: > > On Tuesday, February 14, 2017 10:31:38 AM Geert Uytterhoeven wrote: > > > Laurent Pinchart reported that r8a7790/Lager crashes during suspend tes

Re: [PATCH/RFC 4/6] drivers: firmware: psci: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On Wed, Feb 22, 2017 at 3:05 PM, Geert Uytterhoeven wrote: > Hi Mark, > > On Tue, Feb 21, 2017 at 6:48 PM, Mark Rutland wrote: >> On Mon, Feb 20, 2017 at 09:33:27PM +0100, Geert Uytterhoeven wrote: >>> @@ -440,12 +442,14 @@ static int

Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla <sudeep.ho...@arm.com> wrote: > > > On 22/02/17 13:38, Geert Uytterhoeven wrote: >> Hi Sudeep, >> >> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla <sudeep.ho...@arm.com> wrote: >>> On 22/02/17 01:14, Ra

Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Rafael, > > On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: >> On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: >>> On 21/02/17 18

Re: [PATCH/RFC 0/6] PSCI: Fix non-PMIC wake-up if SYSTEM_SUSPEND cuts power

On Tuesday, February 21, 2017 06:45:13 PM Sudeep Holla wrote: > > On 21/02/17 18:27, Sudeep Holla wrote: > > > > > > On 21/02/17 17:51, Sudeep Holla wrote: > >> > >> > >> On 21/02/17 17:34, Geert Uytterhoeven wrote: > > > > [...] > > > >>> > >>> The SoC can wake-up. It's just not guaranteed

Re: PCI / PM: Crashes in PME scan during system suspend

On Tuesday, February 14, 2017 10:31:38 AM Geert Uytterhoeven wrote: > Hi all, > > Laurent Pinchart reported that r8a7790/Lager crashes during suspend tests. > > I managed to reproduce the issue on r8a7791/koelsch: > - It only happens during suspend tests, after writing either "platform" >

Re: [PATCH] PM / Domains: Do not print PM domain add error message if EPROBE_DEFER

On Wednesday, November 30, 2016 01:24:56 PM Geert Uytterhoeven wrote: > EPROBE_DEFER is not an error, hence printing an error message like > > renesas_irqc e61c.interrupt-controller: failed to add to PM domain > always-on: -517 > > may confuse the user. > > Suppress the error message

Re: [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745

On Wednesday, November 16, 2016 03:39:06 PM Viresh Kumar wrote: > On 16-11-16, 11:05, Geert Uytterhoeven wrote: > > Add the compatible strings for supporting the generic cpufreq driver on > > the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs. > > > > Signed-off-by: Geert Uytterhoeven

Re: [PATCH] cpufreq: dt: Add support for r8a7792

On Wednesday, September 07, 2016 10:32:59 AM Viresh Kumar wrote: > On 06-09-16, 14:18, Geert Uytterhoeven wrote: > > Add the compatible string for supporting the generic cpufreq driver on > > the Renesas R-Car V2H (r8a7792) SoC. > > > > Signed-off-by: Geert Uytterhoeven

Re: [PATCH 4/4] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()

On Tuesday, June 28, 2016 06:26:36 PM Geert Uytterhoeven wrote: > Hi Ulf, Rafael, > > On Tue, May 17, 2016 at 1:41 PM, Ulf Hansson wrote: > > When the pm_runtime_force_suspend|resume() helpers were invented, we still > > had CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP as

Re: [PATCH v2] PM / Runtime: Only force-resume device if it has been force-suspended

On Thu, Apr 21, 2016 at 10:57 PM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > Hi Rafael, > > On Thursday 21 Apr 2016 21:52:56 Rafael J. Wysocki wrote: >> On Thursday, April 21, 2016 02:52:55 AM Laurent Pinchart wrote: >> >

Re: [PATCH v2] PM / Runtime: Only force-resume device if it has been force-suspended

e 100644 > --- a/include/linux/pm.h > +++ b/include/linux/pm.h > @@ -596,6 +596,7 @@ struct dev_pm_info { > unsigned intuse_autosuspend:1; > unsigned inttimer_autosuspends:1; > unsigned intmemalloc_noio:1; > + unsigned intis_force_suspended:1; > enum rpm_requestrequest; > enum rpm_status runtime_status; > int runtime_error; > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.