On Tue, Nov 28, 2017 at 11:58 AM, Geert Uytterhoeven
wrote:
> Hi Rafael, Shimoda-san,
>
> On Sun, Nov 12, 2017 at 1:27 AM, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> The check for "active" children in __pm_runtime_set_status(), when
>>
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
>> > wrote:
>>
>> > > Sure! I tested your patch, and then the follo
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
> Reviewed-by: Geert Uytterhoeven
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, sometim
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
> > bool "Simple Power-Managed
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 deployment cause some issue
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 wakeup
> setting, this doesn't
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:
> >> The PM core in the device_prepare() phase, resets the wakeup_path status
> &g
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 phy core is deployed using the phy core
>>> device, which is
On Sat, Dec 23, 2017 at 2:35 AM, 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
On Thu, Dec 21, 2017 at 2:39 AM, 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 Sat, Dec 23, 2017 at 1:37 PM, Ulf Hansson wrote:
> 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:0
On Sat, Dec 23, 2017 at 1:03 PM, Ulf Hansson wrote:
> 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
On Sat, Dec 23, 2017 at 1:50 PM, Rafael J. Wysocki wrote:
> On Sat, Dec 23, 2017 at 1:03 PM, Ulf Hansson wrote:
>> 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 20
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 simplify the phy code, but the
> > additional use_runtime_pm field in struct phy represents redundant
> > inf
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.
> >
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 wakeup
> setting, this doesn'
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 explicitly.
>
> Signed-off-by: U
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
> sources.
>
> However, there
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 includes some minor changes to
> each
> patch
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 (if exists) is manually kept running during system s
On Sun, Dec 31, 2017 at 10:22 AM, Geert Uytterhoeven
wrote:
> Hi Rafael,
>
> On Sun, Dec 31, 2017 at 1:56 AM, Rafael J. Wysocki wrote:
>> On Fri, Dec 29, 2017 at 2:31 PM, Ulf Hansson wrote:
>>> From: Geert Uytterhoeven
>>>
>>> Changes in v2: [By Ulf H
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
>>> Since commit ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable
>>
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 clock (if exists) is manually kept running during syst
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 wrote:
>>> From: Geert Uytterhoeven
>>>
>>> Since commit ab82fa7da
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 core in the device_prepare() phase, resets the wakeup_path status
&
On Tue, Jan 2, 2018 at 12:46 PM, Ulf Hansson wrote:
> 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() callb
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
> setting, this doesn't
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()
> callback.
>
> However, in si
On Fri, Jan 5, 2018 at 6:12 PM, Ulf Hansson wrote:
> 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
rrectly, 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-by: Rafael J. Wys
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 further
On Mon, Jan 8, 2018 at 12:13 PM, Ulf Hansson wrote:
> 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
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.
> Lik
On Tue, Jan 9, 2018 at 2:37 PM, 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 wan
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:
>> On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven
>> wrote:
>>> On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wyso
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
> wrote:
> > Hi Rafael,
> >
> > On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki
> > wrote:
> >> From: Rafael J. Wysoc
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:
> >> On Tue, Jan 9, 201
On Tue, Jan 9, 2018 at 2:37 PM, 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 wan
On Tue, Jan 9, 2018 at 7:46 PM, Rafael J. Wysocki wrote:
> On Tue, Jan 9, 2018 at 2:37 PM, Geert Uytterhoeven
> wrote:
>> Hi Rafael,
>>
>> On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki
>> wrote:
>>> From: Rafael J. Wysocki
>>>
[cut]
>
On Wed, Jan 10, 2018 at 10:26 AM, Ulf Hansson wrote:
> 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:
[cut]
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 look at the existing use
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 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
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 wrote:
> > This comes from the recent discussion/testing effort that ensued after my
> > pm_runtime_force_suspend|resume() changes pr
On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
wrote:
> Hi Rafael,
>
> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki wrote:
>> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote:
>>> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki
>>
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 DMA enabled on M3, it fails in the same way.
>>
>
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 wrote:
> > On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson wrote:
> >> On 15 January 2018 at 14:22, Geert Uytterhoeven
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. Witho
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"
> o
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 th
On Wed, Feb 22, 2017 at 2:14 PM, Geert Uytterhoeven
wrote:
> Hi Rafael,
>
> On Wed, Feb 22, 2017 at 2:14 AM, Rafael J. Wysocki wrote:
>> 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
On Wed, Feb 22, 2017 at 3:32 PM, Sudeep Holla wrote:
>
>
> On 22/02/17 13:38, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Wed, Feb 22, 2017 at 12:03 PM, Sudeep Holla wrote:
>>> On 22/02/17 01:14, Rafael J. Wysocki wrote:
>>>> On Tuesday,
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 psci_system_suspend_valid(suspend_state_t
>>> state)
>>> sta
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
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 wrote:
> > On Sat, Apr 15, 2017 at 12:27:31AM +0200, Rafael J. Wysocki wrote:
> >> On Friday, April 14, 2017 10:22:49 AM Lukas Wunner wrote:
>
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 u
On Mon, Apr 23, 2018 at 11:32 AM, Geert Uytterhoeven
wrote:
> Hi Rafael,
>
> On Mon, Apr 23, 2018 at 11:18 AM, Rafael J. Wysocki
> wrote:
>> On Wednesday, March 14, 2018 12:26:24 PM CEST Geert Uytterhoeven wrote:
>>> Add a callback to inform a device that h
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 upstr
On Tue, May 15, 2018 at 9:35 AM, Simon Horman 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-Car Gen 3
>> > r8a
On Thursday, December 20, 2018 11:00:29 AM CET Hans de Goede wrote:
> Hi,
>
> On 19-12-18 23:33, Wolfram Sang wrote:
> > Hi Lukas, Hans,
> >
> > On Wed, Dec 19, 2018 at 07:36:54PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 19-12-18 18:22, Lukas Wunner wrote:
> >>> On Wed, Dec 19, 2018 at 0
On Wed, Jan 30, 2019 at 10:14 AM Vincent Guittot
wrote:
>
> Hi Geert,
>
> On Wed, 30 Jan 2019 at 09:21, Geert Uytterhoeven wrote:
> >
> > Hi Vincent,
> >
> > On Wed, Jan 30, 2019 at 9:16 AM Vincent Guittot
> > wrote:
> > > A deadlock has been seen when swicthing clocksources which use PM runtime
On Wed, Jan 30, 2019 at 12:16 PM Vincent Guittot
wrote:
>
> A deadlock has been seen when swicthing clocksources which use PM runtime.
> The call path is:
> change_clocksource
> ...
> write_seqcount_begin
> ...
> timekeeping_update
> ...
> sh_cmt_clocksource_enable
On Wed, Jan 30, 2019 at 6:26 PM Vincent Guittot
wrote:
>
> A deadlock has been seen when swicthing clocksources which use PM runtime.
> The call path is:
> change_clocksource
> ...
> write_seqcount_begin
> ...
> timekeeping_update
> ...
> sh_cmt_clocksource_enable
>
On Monday, February 4, 2019 5:25:51 PM CET Vincent Guittot wrote:
> Fix time accounting which has the same lock contraint as for using hrtimer
> and update accounting_timestamp only when useful.
>
> Vincent Guittot (2):
> PM-runtime: move runtime accounting on ktime_get_mono_fast_ns()
> PM-run
On Wednesday, January 30, 2019 10:40:17 PM CET Ladislav Michl wrote:
> pm_runtime_autosuspend_expiration calls ktime_get_mono_fast_ns
> even when its returned value may be unused. Therefore get
> current time later and remove gotos while there.
>
> Signed-off-by: Ladislav Michl
> Acked-by: Tony L
out to be a red herring.
>
> On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL.
> Hence if a driver has used a managed DMA allocation API, the allocated
> DMA memory will be freed using the direct DMA ops, while it may have
> been allocated using a custom DMA ops
On Friday, March 8, 2019 10:35:49 PM CET Marek Vasut wrote:
> On 3/8/19 6:17 PM, Bjorn Helgaas wrote:
> > [+cc linux-pm, Rafael for SET_NOIRQ_SYSTEM_SLEEP_PM_OPS question at the end]
> >
> > On Thu, Mar 07, 2019 at 11:49:34PM +0100, Marek Vasut wrote:
> >> On 3/7/19 9:50 PM, Bjorn Helgaas wrote:
>
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
> > ---
> > Untested due t
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
> > ---
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 in
/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.
On Thu, Apr 21, 2016 at 10:57 PM, Laurent Pinchart
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:
>> > The pm_runtime_force_suspend() and pm_runtime_force_resume() help
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, Geert Uytterhoeven wrote:
>> >> On Wed,
On Tue, Jul 4, 2017 at 10:05 PM, Krzysztof Kozlowski 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 wrote:
>> > On Tue, Jul 04, 2017 at 08:19:47PM +0200, Geert Uytterhoeven wrote:
On Tue, Jul 4, 2017 at 10:20 PM, Krzysztof Kozlowski 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 wrote:
> >> >> > Thanks for report!
>> >> >> >
>> >
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 cpufreq-dt support.
> > Hence, foll
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 keeping
> > with support for other Renes
esas-soc
>>>
>>> On Tue, Oct 31, 2017 at 2:09 PM, Geert Uytterhoeven
>>> wrote:
>>>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki
>>>> wrote:
>>>>> On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
>>>
gt; wrote:
>>> On Tue, Oct 31, 2017 at 12:27 AM, Rafael J. Wysocki
>>> wrote:
>>>> On Monday, October 30, 2017 11:19:08 AM CET Rafael J. Wysocki wrote:
>>>>> On Mon, Oct 30, 2017 at 8:10 AM, Tero Kristo wrote:
>>>>> > The recent
On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven
wrote:
> Hi Rafael,
>
> On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. Wysocki wrote:
>> On Tue, Oct 31, 2017 at 2:55 PM, Geert Uytterhoeven
>> wrote:
>>> Hi Rafael, Tero,
>>>
>>> CC pinchartl, d
On Wed, Nov 1, 2017 at 11:28 AM, Tero Kristo wrote:
> On 01/11/17 00:32, Rafael J. Wysocki wrote:
>>
>> On Tue, Oct 31, 2017 at 7:07 PM, Geert Uytterhoeven
>> wrote:
>>>
>>> Hi Rafael,
>>>
>>> On Tue, Oct 31, 2017 at 6:22 PM, Rafael J. W
[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 d68b056..7c8f643
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 driv
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 device may need to stay in fu
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 device may need to stay in fu
On Thu, Nov 9, 2017 at 9:44 AM, Ulf Hansson wrote:
> On 9 November 2017 at 01:24, Rafael J. Wysocki wrote:
>> 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 fr
On Thu, Nov 9, 2017 at 9:53 AM, Ulf Hansson wrote:
> On 9 November 2017 at 01:41, Rafael J. Wysocki wrote:
>> 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 fr
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 Uytterhoeven
>>> wrote:
On Wed, Nov 8, 2017 at 4:15 PM, Ulf Hansson wrot
On Thu, Nov 9, 2017 at 12:59 PM, Rafael J. Wysocki wrote:
> 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 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 disabled by the user (or deemed not usable,
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 ins
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
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 separate Kconfig options.
> >
>
93 matches
Mail list logo
