Skip to content
Snippets Groups Projects
Select Git revision
  • feature/v6.1-ktn/add-st1633-touch-imx8mm
  • v6.12-ktn
  • v6.1-ktn default protected
  • v5.10-ktn protected
  • v5.4-ktn protected
  • feature/v6.12-ktn/mx8mp-osm-s-uart4-pinmux-fix
  • ci/upstream-sync
  • v6.10-ktn
  • feature/v6.1-ktn/ksz-switch-backports
  • feature/v6.9-ktn/mx93-dev-lvds
  • feature/v6.1-ktn/kontron-mx8m-osm-improvements
  • v4.14-ktn protected
  • feature/master/upstream-spinand-rx-delay
  • feature/next/upstream-imx8mm-dts-sync
  • feature/fix-w25n02kv-clk-to-rx-delay
  • develop-v5.10-stm32mp-ktn
  • feature/v6.1-ktn/mx8mp-hdmi-patch-sync
  • feature/v6.5/mx8mp-support
  • feature/v5.10-ktn/rtc-bsm-fix
  • v5.10-ktn-remoteproc-rpmsg-backport-5.19-rc5
  • v5.15.37
  • st-alpha
22 results
Search by author
  • Any Author
  • Alexander Arndt Alexander Arndt aarndt
  • Andreas Findeklee Andreas Findeklee afindeklee
  • Annette Kobou Annette Kobou akobou
  • Armin Mück Armin Mück amueck
  • **** **** project_143_bot_c8bbc40375b18788e4765d3c396612d5
  • Daniel Ehrler Daniel Ehrler dehrler
  • Devran Ölcer Devran Ölcer doelcer
  • Dieter Scheufele Dieter Scheufele dscheufele
  • Dietmar Kolbus Dietmar Kolbus dkolbus
  • Dominik Wurster Dominik Wurster Wurster
  • Eberhard Stoll Eberhard Stoll estoll
  • Florian Mayer Florian Mayer fmayer
  • Frieder Schrempf Frieder Schrempf fschrempf
  • Julian Bauknecht Julian Bauknecht jbauknecht
  • Jó Bitsch Jó Bitsch jbitsch
  • Jürgen Kling Jürgen Kling jgkling
  • Klemenz Christof Klemenz Christof kchristof
  • Lukas Loosli Lukas Loosli lloosli
  • Marc Gonser Marc Gonser mgonser
  • Markus Abegg Markus Abegg mabegg
20 authors
  1. Jul 14, 2012
  3. Jul 03, 2012
  5. Jul 01, 2012
  7. Jun 19, 2012
  9. May 06, 2012
  11. May 05, 2012
  13. Apr 29, 2012
  15. Apr 13, 2012
  17. Feb 09, 2012
  19. Jan 29, 2012
    • Rafael J. Wysocki's avatar
      PM / Sleep: Introduce "late suspend" and "early resume" of devices · cf579dfb
      Rafael J. Wysocki authored 
      
The current device suspend/resume phases during system-wide power
transitions appear to be insufficient for some platforms that want
to use the same callback routines for saving device states and
related operations during runtime suspend/resume as well as during
system suspend/resume.  In principle, they could point their
.suspend_noirq() and .resume_noirq() to the same callback routines
as their .runtime_suspend() and .runtime_resume(), respectively,
but at least some of them require device interrupts to be enabled
while the code in those routines is running.

It also makes sense to have device suspend-resume callbacks that will
be executed with runtime PM disabled and with device interrupts
enabled in case someone needs to run some special code in that
context during system-wide power transitions.

Apart from this, .suspend_noirq() and .resume_noirq() were introduced
as a workaround for drivers using shared interrupts and failing to
prevent their interrupt handlers from accessing suspended hardware.
It appears to be better not to use them for other porposes, or we may
have to deal with some serious confusion (which seems to be happening
already).

For the above reasons, introduce new device suspend/resume phases,
"late suspend" and "early resume" (and analogously for hibernation)
whose callback will be executed with runtime PM disabled and with
device interrupts enabled and whose callback pointers generally may
point to runtime suspend/resume routines.

Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      cf579dfb
  21. Jan 19, 2012
  23. Jan 04, 2012
  25. Dec 21, 2011
    • Rafael J. Wysocki's avatar
      PM: Run the driver callback directly if the subsystem one is not there · 35cd133c
      Rafael J. Wysocki authored 
      
Make the PM core execute driver PM callbacks directly if the
corresponding subsystem callbacks are not present.

There are three reasons for doing that.  First, it reflects the
behavior of drivers/base/dd.c:really_probe() that runs the driver's
.probe() callback directly if the bus type's one is not defined, so
this change will remove one arbitrary difference between the PM core
and the remaining parts of the driver core.  Second, it will allow
some subsystems, whose PM callbacks don't do anything except for
executing driver callbacks, to be simplified quite a bit by removing
those "forward-only" callbacks.  Finally, it will allow us to remove
one level of indirection in the system suspend and resume code paths
where it is not necessary, which is going to lead to less debug noise
with initcall_debug passed in the kernel command line (messages won't
be printed for driverless devices whose subsystems don't provide
PM callbacks among other things).

Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      35cd133c
  27. Dec 08, 2011
  29. Dec 05, 2011
  31. Nov 28, 2011
  33. Nov 21, 2011
    • Tejun Heo's avatar
      freezer: unexport refrigerator() and update try_to_freeze() slightly · a0acae0e
      Tejun Heo authored 
      
There is no reason to export two functions for entering the
refrigerator.  Calling refrigerator() instead of try_to_freeze()
doesn't save anything noticeable or removes any race condition.

* Rename refrigerator() to __refrigerator() and make it return bool
  indicating whether it scheduled out for freezing.

* Update try_to_freeze() to return bool and relay the return value of
  __refrigerator() if freezing().

* Convert all refrigerator() users to try_to_freeze().

* Update documentation accordingly.

* While at it, add might_sleep() to try_to_freeze().

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>
Cc: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
Cc: Christoph Hellwig <hch@infradead.org>
      a0acae0e
    • Tejun Heo's avatar
      freezer: don't unnecessarily set PF_NOFREEZE explicitly · 3a7cbd50
      Tejun Heo authored 
      
Some drivers set PF_NOFREEZE in their kthread functions which is
completely unnecessary and racy - some part of freezer code doesn't
consider cases where PF_NOFREEZE is set asynchronous to freezer
operations.

In general, there's no reason to allow setting PF_NOFREEZE explicitly.
Remove them and change the documentation to note that setting
PF_NOFREEZE directly isn't allowed.

-v2: Dropped change to twl4030-irq.c as it no longer uses PF_NOFREEZE.

Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Acked-by: default avatar"Gustavo F. Padovan" <padovan@profusion.mobi>
Acked-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: wwang <wei_wang@realsil.com.cn>
      3a7cbd50
  35. Nov 04, 2011
  37. Oct 21, 2011
  39. Oct 16, 2011
    • Rafael J. Wysocki's avatar
      PM / Hibernate: Freeze kernel threads after preallocating memory · 2aede851
      Rafael J. Wysocki authored 
      
There is a problem with the current ordering of hibernate code which
leads to deadlocks in some filesystems' memory shrinkers.  Namely,
some filesystems use freezable kernel threads that are inactive when
the hibernate memory preallocation is carried out.  Those same
filesystems use memory shrinkers that may be triggered by the
hibernate memory preallocation.  If those memory shrinkers wait for
the frozen kernel threads, the hibernate process deadlocks (this
happens with XFS, for one example).

Apparently, it is not technically viable to redesign the filesystems
in question to avoid the situation described above, so the only
possible solution of this issue is to defer the freezing of kernel
threads until the hibernate memory preallocation is done, which is
implemented by this change.

Unfortunately, this requires the memory preallocation to be done
before the "prepare" stage of device freeze, so after this change the
only way drivers can allocate additional memory for their freeze
routines in a clean way is to use PM notifiers.

Reported-by: default avatarChristoph <cr2005@u-club.de>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      2aede851
    • Alan Stern's avatar
      PM: Update the policy on default wakeup settings · 8f88893c
      Alan Stern authored 
      
This patch (as1485) documents a change to the kernel's default wakeup
policy.  Devices that forward wakeup requests between buses should be
enabled for wakeup by default.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      8f88893c
    • ShuoX Liu's avatar
      PM / Suspend: Add statistics debugfs file for suspend to RAM · 2a77c46d
      ShuoX Liu authored 
      
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.

The motivation of the patch:

We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.

We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.

Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.

If not using this patch, we have other methods to get info about
what device fails. One is to turn on  CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.

In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
   Then, check its status. No serial console available during the
   testing. One is because console would be suspended, and the other
   is serial console connecting with spi or HSU devices would consume
   power. These devices are powered off at suspend-2-ram.

Signed-off-by: default avatarShuoX Liu <shuox.liu@intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      2a77c46d
  41. Oct 10, 2011
  43. Oct 07, 2011
  45. Oct 04, 2011
  47. Sep 27, 2011
    • Paul Bolle's avatar
      doc: fix broken references · 395cf969
      Paul Bolle authored 
      
There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.

Fix these broken references, sometimes by dropping the irrelevant text
they were part of.

Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      395cf969
  49. Sep 21, 2011
  51. Aug 25, 2011
  53. Aug 14, 2011
    • Colin Cross's avatar
      PM / Runtime: Add might_sleep() to runtime PM functions · 311aab73
      Colin Cross authored 
      
Some of the entry points to pm runtime are not safe to
call in atomic context unless pm_runtime_irq_safe() has
been called.  Inspecting the code, it is not immediately
obvious that the functions sleep at all, as they run
inside a spin_lock_irqsave, but under some conditions
they can drop the lock and turn on irqs.

If a driver incorrectly calls the pm_runtime apis, it can
cause sleeping and irq processing when it expects to stay
in atomic context.

Add might_sleep_if to the majority of the __pm_runtime_* entry points
to enforce correct usage.

Add pm_runtime_put_sync_autosuspend to the list of
functions that can be called in atomic context.

Signed-off-by: default avatarColin Cross <ccross@android.com>
Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      311aab73
  55. Aug 05, 2011
    • Kevin Hilman's avatar
      PM / Runtime: Allow _put_sync() from interrupts-disabled context · 02b26774
      Kevin Hilman authored 
      
Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will release the
spinlock and enable interrupts for the idle callbacks.  This enables
interrupts during a time where interrupts were expected to be
disabled, and can have strange side effects on drivers that expected
interrupts to be disabled.

This is not a bug since the documentation clearly states that only
_put_sync_suspend() is safe in IRQ-safe mode.

However, pm_runtime_put_sync() could be made safe when in IRQ-safe
mode by releasing the spinlock but not re-enabling interrupts, which
is what this patch aims to do.

Problem was found when using some buggy drivers that set
pm_runtime_irq_safe() and used _put_sync() in interrupts-disabled
context.

Reported-by: default avatarColin Cross <ccross@google.com>
Tested-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      02b26774