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-doc@vger.kernel.org
Signed-off-by: Ulf Hansson
---
Documentation/phy.txt | 28 +++-
1 file changed, 15 inser
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-doc@vger.kernel.org
Signed-off-by: Ulf Hansson
---
Documentation/phy.txt | 29 -
1 file change
On Wed, 28 Nov 2018 at 12:47, Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Important information is missing from user/admin cpuidle documentation
> available today, so add a new user/admin document for cpuidle containing
> current and comprehensive information to admin-guide and drop
On Thu, 29 Nov 2018 at 11:28, Rafael J. Wysocki wrote:
>
> On Thu, Nov 29, 2018 at 9:07 AM Ulf Hansson wrote:
> >
> > On Wed, 28 Nov 2018 at 12:47, Rafael J. Wysocki wrote:
> > >
> > > From: Rafael J. Wysocki
> > >
> > > Important inform
On Wed, 12 Dec 2018 at 10:46, Peter Zijlstra wrote:
>
> On Tue, Dec 11, 2018 at 10:51:48AM +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra
> > wrote:
>
> > > Dunno; it could be cold cachelines, at which point it can be fairly
> > > expensive. Also, being stuck
and driver API document for cpuidle
> > under Documentation/driver-api/pm/.
> >
> > Signed-off-by: Rafael J. Wysocki
>
> In the face of the lack of any feedback I'm assuming that this is fine
> by everyone.
I have look through it, looks good and sorry for the del
On 13 October 2017 at 02:33, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Fix kerneldoc comments of __device_suspend_noirq(),
> __device_suspend_late() and __device_suspend() where the function
> names in kerneldoc don't match the actual names of the functions.
>
> Signed-off-by: Rafael
ns.
>
> Also fix the device_resume_noirq() kerneldoc comment which mentions
> "early resume" instead of "noirq resume" incorrectly.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
> ---
> drivers/base/power/main.c |8
> 1 f
On 16 October 2017 at 03:12, Rafael J. Wysocki wrote:
> Hi All,
>
> Well, this took more time than expected, as I tried to cover everything I had
> in mind regarding PM flags for drivers.
>
> This work was triggered by attempts to fix and optimize PM in the
> i2c-designware-platdev driver that end
[...]
>>
>> I am not sure I fully understand the goal you have with this series.
>> Can we please try to get that clear before I continue the review.
>
> Quoting from the above:
>
> "This patch series focuses on addressing those problems so as to make it
> easier to reuse callback routines by poin
On 18 October 2017 at 02:39, Rafael J. Wysocki wrote:
> On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
>
> [cut]
>
>> >
>> >> deploying this and from a middle layer point of view, all the trivial
>> >> cases supports this.
>>
[...]
>> Are there any major reasons why the appended patch (obviously untested) won't
>> work, then?
>
> OK, there is a reason, which is the optimizations bundled into
> pm_runtime_force_*, because (a) the device may be left in runtime suspend
> by them (in which case amba_pm_suspend_early() in m
[...]
>>
>> The reason why pm_runtime_force_* needs to respects the hierarchy of
>> the RPM callbacks, is because otherwise it can't safely update the
>> runtime PM status of the device.
>
> I'm not sure I follow this requirement. Why is that so?
If the PM domain controls some resources for the
On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>
>> On 10/18/2017 09:11 AM, Ulf Hansson wrote:
>
> [...]
>
>> >>> That's the point. We know pm_runtime_force_* works nice
On 19 October 2017 at 00:12, Rafael J. Wysocki wrote:
> On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
>> [...]
>>
>> >>
>> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
>> >> the RPM callbac
[...]
>>> > Say you want to leave the parent suspended after system resume, but the
>>> > child drivers use pm_runtime_force_suspend|resume(). The parent would
>>> > then
>>> > need to use pm_runtime_force_suspend|resume() too, no?
>>>
>>> Actually no.
>>>
>>> Currently the other options of "def
On 19 October 2017 at 19:21, Grygorii Strashko wrote:
>
>
> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
>>> On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
>>>>
>>&g
On 19 October 2017 at 20:04, Ulf Hansson wrote:
> On 19 October 2017 at 19:21, Grygorii Strashko
> wrote:
>>
>>
>> On 10/19/2017 03:33 AM, Ulf Hansson wrote:
>>> On 18 October 2017 at 23:48, Rafael J. Wysocki wrote:
>>>> On Wednesday, October 18,
On 20 October 2017 at 03:19, Rafael J. Wysocki wrote:
> On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote:
>> On 19 October 2017 at 00:12, Rafael J. Wysocki wrote:
>> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
>> >> [...]
>
[...]
> In this regards as we consider genpd being a trivial PM domain, those
> examples your bring up above is too me also examples of trivial PM
> domains. Especially because they don't deal with wakeups, as that is
> taken care of by the drivers, right!?
Not directly,
On 19 October 2017 at 01:17, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The motivation for this change is to provide a way to work around
> a problem with the direct-complete mechanism used for avoiding
> system suspend/resume handling for devices in runtime suspend.
>
> The problem i
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Replace the PCI-specific flag PCI_DEV_FLAGS_NEEDS_RESUME with the
> PM core's DPM_FLAG_NEVER_SKIP one everywhere and drop it.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Modify i2c-designware-platdrv to set DPM_FLAG_SMART_PREPARE for its
> devices and return 0 from the system suspend ->prepare callback
> if the device has an ACPI companion object in order to tell the PM
> core and
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a SMART_SUSPEND flag to instruct bus types and PM
> domains that the system suspend callbacks provided by the driver can
> cope with runtime-suspended devices, so from the driver's perspective
t will allow subsequent changes to be somewhat simpler.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
> ---
> drivers/pci/pci-driver.c | 18 --
> 1 file changed, 18 deletions(-
_lpss_suspend_late() and acpi_lpss_resume_early() use
> them too in order to unify the runtime PM and system sleep
> handling in the LPSS driver.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Ulf Hansson
> ---
>
> This is based on an RFC I posted some time ago
> (
On 16 October 2017 at 03:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> instruct the PM core that it is desirable to leave the device in
> runtime suspend after system resume (for example, the device may be
> slow t
On 16 October 2017 at 03:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a SMART_SUSPEND flag to instruct bus types and PM
> domains that the system suspend callbacks provided by the driver can
> cope with runtime-suspended devices, so from the driver's perspective
acks.
>
> Signed-off-by: Rafael J. Wysocki
> Acked-by: Greg Kroah-Hartman
> Acked-by: Bjorn Helgaas
If not too late:
Reviewed-by: Ulf Hansson
> ---
>
> -> v2: Do not use pm_generic_prepare() in acpi_subsys_prepare()
>as the latter has to distinguish b
s to be able to
> cope with that too.
>
> Signed-off-by: Rafael J. Wysocki
> Acked-by: Greg Kroah-Hartman
If not too late:
Reviewed-by: Ulf Hansson
> ---
>
> -> v2: Drop the changes in main.c, as the logic implemented by them
>previously is now going to be impl
On 8 November 2017 at 14:25, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> instruct the PM core and middle-layer (bus type, PM domain, etc.)
> code that it is desirable to leave the device in runtime suspend
> after sy
[...]
>
> An example pull request of mine might look like:
> Char/Misc patches for 4.15-rc1
>
> Here is the big char/misc patch set for the 4.15-rc1 merge
> window. Contained in here is the normal set of new functions
> added to all of these crazy drivers, as well
On 11 November 2017 at 00:45, Rafael J. Wysocki wrote:
> On Fri, Nov 10, 2017 at 10:09 AM, Ulf Hansson wrote:
>> On 8 November 2017 at 14:25, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> Define and document a new driver flag, DPM_FLAG_LEA
e" phase of system suspend and
> the "early" phase of system resume (or analogous) transitions.
>
> The helpers will be called from additional sites going forward.
>
> Signed-off-by: Rafael J. Wysocki
With a minor nitpick, see below, feel free to add:
Reviewed-by: Ulf
[...]
>>
>> My general goal is that I want to make it easier (or as easy as
>> possible) for the general driver author to deploy runtime PM and
>> system-wide PM support - in an optimized manner. Therefore, I am
>> pondering over the solution you picked in this series, trying to
>> understand how
On 12 November 2017 at 01:37, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> instruct the PM core and middle-layer (bus type, PM domain, etc.)
> code that it is desirable to leave the device in runtime suspend
> after s
[...]
>> > +++ linux-pm/include/linux/pm.h
>> > @@ -559,6 +559,7 @@ struct pm_subsys_data {
>> > * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
>> > * SMART_PREPARE: Check the return value of the driver's ->prepare
>> > callback.
>> > * SMART_SUSPEND: No need to r
[...]
>>
Second, have you considered setting the default value of
dev->power.may_skip_resume to true?
>>>
>>> Yes.
>>>
That would means the subsystem
instead need to implement an opt-out method. I am thinking that it may
not be an issue, since we anyway at this point, don'
On 17 November 2017 at 15:31, Rafael J. Wysocki wrote:
> On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson wrote:
>> [...]
>>
>>>>
>>>>>> Second, have you considered setting the default value of
>>>>>> dev->power.may_skip_resume to
left in
> suspend.
>
> The additional power.must_resume status bit introduced for the
> implementation of this mechanisn is used internally by the PM core
> to track the requirement to resume the device (which may depend on
> its children etc).
>
> Signed-off-by: Rafael J. Wysock
On 18 November 2017 at 15:41, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
> devices whose "noirq", "late" and "early" driver callbacks are
> invoked directly by it.
This indicates that your target for this particular change
On 22 February 2016 at 18:18, Mark Salyzyn wrote:
> When CONFIG_MMC_SIMULATE_MAX_SPEED is enabled, Expose max_read_speed,
> max_write_speed and cache_size sysfs controls to simulate a slow
> eMMC device. The boot default values, should one wish to set this
> behavior right from kernel start:
>
> C
gt;
> I've applied this to the docs tree, thanks.
If it's not too late you can add my:
Acked-by: Ulf Hansson
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4 July 2016 at 13:56, Bojan Prtvar wrote:
> Make operation conditions register (OCR) easily accessible from user space.
>
> Signed-off-by: Bojan Prtvar
Thanks, applied for next! Amended the changelog with the explanation
why this change is wanted.
Kind regards
Uffe
> ---
> Documentation/mm
On 6 July 2016 at 18:21, Ulf Hansson wrote:
> On 4 July 2016 at 13:56, Bojan Prtvar wrote:
>> Make operation conditions register (OCR) easily accessible from user space.
>>
>> Signed-off-by: Bojan Prtvar
>
> Thanks, applied for next! Amended the changelog with the ex
On 12 July 2016 at 14:56, Bojan Prtvar wrote:
> Export DSR register through sysfs same as we did for the CID, CSD and OCR
> registers.
>
> Signed-off-by: Bojan Prtvar
> ---
> Documentation/mmc/mmc-dev-attrs.txt | 1 +
> drivers/mmc/core/mmc.c | 17 +
> 2 files chan
On 19 July 2016 at 11:16, Bojan Prtvar wrote:
> Export DSR register through sysfs same as we did for the CID, CSD and OCR
> registers.
>
> Signed-off-by: Bojan Prtvar
Thanks, applied for next!
Kind regards
Uffe
> ---
> v2: Extended to cover SD cards
>
> Documentation/mmc/mmc-dev-attrs.txt |
47 matches
Mail list logo
