Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 10月, 2015 2 次提交
  3. 27 9月, 2015 1 次提交
  5. 26 9月, 2015 2 次提交
  7. 10 9月, 2015 1 次提交
  9. 09 9月, 2015 1 次提交
  11. 05 9月, 2015 1 次提交
  13. 03 9月, 2015 1 次提交
  15. 29 8月, 2015 3 次提交
  17. 28 8月, 2015 3 次提交
  19. 07 8月, 2015 10 次提交
  21. 01 8月, 2015 2 次提交
    • J
      PM / Domains: Return -EPROBE_DEFER if we fail to init or turn-on domain · 311fa6ad
      由 Jon Hunter 提交于 
      When a device is probed, the function dev_pm_domain_attach() is called
to see if there is a power-domain that is associated with the device and
needs to be turned on. If dev_pm_domain_attach() does not return
-EPROBE_DEFER then the device will be probed.

For devices using genpd, dev_pm_domain_attach() will call
genpd_dev_pm_attach(). If genpd_dev_pm_attach() does not find a power
domain associated with the device then it returns an error code not
equal to -EPROBE_DEFER to allow the device to be probed. However, if
genpd_dev_pm_attach() does find a power-domain that is associated with
the device, then it does not return -EPROBE_DEFER on failure and hence
the device will still be probed. Furthermore, genpd_dev_pm_attach() does
not check the error code returned by pm_genpd_poweron() to see if the
power-domain was turned on successfully.

Fix this by checking the return code from pm_genpd_poweron() and
returning -EPROBE_DEFER from genpd_dev_pm_attach on failure, if there
is a power-domain associated with the device.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      311fa6ad
    • U
      PM / Domains: Remove intermediate states from the power off sequence · ba2bbfbf
      由 Ulf Hansson 提交于 
      Genpd's ->runtime_suspend() (assigned to pm_genpd_runtime_suspend())
doesn't immediately walk the hierarchy of ->runtime_suspend() callbacks.
Instead, pm_genpd_runtime_suspend() calls pm_genpd_poweroff() which
postpones that until *all* the devices in the genpd are runtime suspended.

When pm_genpd_poweroff() discovers that the last device in the genpd is
about to be runtime suspended, it calls __pm_genpd_save_device() for *all*
the devices in the genpd sequentially. Furthermore,
__pm_genpd_save_device() invokes the ->start() callback, walks the
hierarchy of the ->runtime_suspend() callbacks and invokes the ->stop()
callback. This causes a "thundering herd" problem.

Let's address this issue by having pm_genpd_runtime_suspend() immediately
walk the hierarchy of the ->runtime_suspend() callbacks, instead of
postponing that to the power off sequence via pm_genpd_poweroff(). If the
selected ->runtime_suspend() callback doesn't return an error code, call
pm_genpd_poweroff() to see if it's feasible to also power off the PM
domain.

Adopting this change enables us to simplify parts of the code in genpd,
for example the locking mechanism. Additionally, it gives some positive
side effects, as described below.

i)
One device's ->runtime_resume() latency is no longer affected by other
devices' latencies in a genpd.

The complexity genpd has to support the option to abort the power off
sequence suffers from latency issues. More precisely, a device that is
requested to be runtime resumed, may end up waiting for
__pm_genpd_save_device() to complete its operations for *another* device.
That's because pm_genpd_poweroff() can't confirm an abort request while it
waits for __pm_genpd_save_device() to return.

As this patch removes the intermediate states in pm_genpd_poweroff() while
powering off the PM domain, we no longer need the ability to abort that
sequence.

ii)
Make pm_runtime[_status]_suspended() reliable when used with genpd.

Until the last device in a genpd becomes idle, pm_genpd_runtime_suspend()
will return 0 without actually walking the hierarchy of the
->runtime_suspend() callbacks. However, by returning 0 the runtime PM core
considers the device as runtime_suspended, so
pm_runtime[_status]_suspended() will return true, even though the device
isn't (yet) runtime suspended.

After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks,
pm_runtime[_status]_suspended() will accurately reflect the status of the
device.

iii)
Enable fine-grained PM through runtime PM callbacks in drivers/subsystems.

There are currently cases were drivers/subsystems implements runtime PM
callbacks to deploy fine-grained PM (e.g. gate clocks, move pinctrl to
power-save state, etc.). While using the genpd, pm_genpd_runtime_suspend()
postpones invoking these callbacks until *all* the devices in the genpd
are runtime suspended. In essence, one runtime resumed device prevents
fine-grained PM for other devices within the same genpd.

After this patch, since pm_genpd_runtime_suspend() immediately walks the
hierarchy of the ->runtime_suspend() callbacks, fine-grained PM is enabled
throughout all the levels of runtime PM callbacks.

iiii)
Enable fine-grained PM for IRQ safe devices

Per the definition for an IRQ safe device, its runtime PM callbacks must
be able to execute in atomic context. In the path while genpd walks the
hierarchy of the ->runtime_suspend() callbacks for the device, it uses a
mutex. Therefore, genpd prevents that path to be executed for IRQ safe
devices.

As this patch changes pm_genpd_runtime_suspend() to immediately walk the
hierarchy of the ->runtime_suspend() callbacks and without needing to use
a mutex, fine-grained PM is enabled throughout all the levels of runtime
PM callbacks for IRQ safe devices.

Unfortunately this patch also comes with a drawback, as described in the
summary below.

Driver's/subsystem's runtime PM callbacks may be invoked even when the
genpd hasn't actually powered off the PM domain, potentially introducing
unnecessary latency.

However, in most cases, saving/restoring register contexts for devices are
typically fast operations or can be optimized in device specific ways
(e.g. shadow copies of register contents in memory, device-specific checks
to see if context has been lost before restoring context, etc.).

Still, in some cases the driver/subsystem may suffer from latency if
runtime PM is used in a very fine-grained manner (e.g. for each IO request
or xfer). To prevent that extra overhead, the driver/subsystem may deploy
the runtime PM autosuspend feature.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NLina Iyer <lina.iyer@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ba2bbfbf
  23. 28 7月, 2015 1 次提交
  25. 23 7月, 2015 1 次提交
  27. 22 7月, 2015 1 次提交
  29. 18 7月, 2015 1 次提交
    • C
      PM / clk: don't return int on __pm_clk_enable() · f4745a92
      由 Colin Ian King 提交于 
      Static analysis by cppcheck found an issue that was recently introduced by
commit 471f7707 ("PM / clock_ops: make __pm_clk_enable more generic")
where a return status in ret was not being initialised and garbage
being returned when ce->status >= PCE_STATUS_ERROR.

The fact that ret is not being checked by the caller and that
ret is only used internally __pm_clk_enable() to check if clk_enable()
was OK means we can ignore returning it instead turn
__pm_clk_enable() into function with a void return.

Fixes: 471f7707 ("PM / clock_ops: make __pm_clk_enable more generic")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f4745a92
  31. 07 7月, 2015 2 次提交
  33. 16 6月, 2015 2 次提交
    • G
      PM / clk: Print acquired clock name in addition to con_id · f17f4adf
      由 Geert Uytterhoeven 提交于 
      Currently the con_id of the acquired clock is printed for debugging
purposes.  But in several cases, the con_id is NULL, which doesn't
provide much debugging information when printed.  These cases are:
  - When explicitly passing a NULL con_id (which means the first clock
    tied to the device, if available),
  - When not using pm_clk_add(), but pm_clk_add_clk() (which takes a
    "struct clk *" directly).

Hence print the actual clock name in addition to (and not instead of;
thanks Grygorii Strashko!) the con_id.

Note that the clock name is not available with legacy clock frameworks,
and the hex pointer address will be printed instead.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f17f4adf
    • G
      PM / Domains: Skip timings during syscore suspend/resume · a4630c61
      由 Geert Uytterhoeven 提交于 
      The PM Domain code uses ktime_get() to perform various latency
measurements.  However, if ktime_get() is called while timekeeping is
suspended, the following warning is printed:

    WARNING: CPU: 0 PID: 1340 at kernel/time/timekeeping.c:576 ktime_get+0x3

This happens when resuming the PM Domain that contains the clock events
source, which calls pm_genpd_syscore_poweron(). Chain of operations is:

    timekeeping_resume()
    {
	clockevents_resume()
	    sh_cmt_clock_event_resume()
		pm_genpd_syscore_poweron()
		    pm_genpd_sync_poweron()
			genpd_syscore_switch()
			    genpd_power_on()
				ktime_get(), but timekeeping_suspended == 1
	...
	timekeeping_suspended = 0;
    }

Fix this by adding a "timed" parameter to genpd_power_{on,off}() and
pm_genpd_sync_power{off,on}(), to indicate whether latency measurements
are allowed.  This parameter is passed as false in
genpd_syscore_switch() (i.e. during syscore suspend/resume), and true in
all other cases.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a4630c61
  35. 10 6月, 2015 1 次提交
  37. 20 5月, 2015 2 次提交
    • T
      PM / Wakeirq: Add automated device wake IRQ handling · 4990d4fe
      由 Tony Lindgren 提交于 
      Turns out we can automate the handling for the device_may_wakeup()
quite a bit by using the kernel wakeup source list as suggested
by Rafael J. Wysocki <rjw@rjwysocki.net>.

And as some hardware has separate dedicated wake-up interrupt
in addition to the IO interrupt, we can automate the handling by
adding a generic threaded interrupt handler that just calls the
device PM runtime to wake up the device.

This allows dropping code from device drivers as we currently
are doing it in multiple ways, and often wrong.

For most drivers, we should be able to drop the following
boilerplate code from runtime_suspend and runtime_resume
functions:

	...
	device_init_wakeup(dev, true);
	...
	if (device_may_wakeup(dev))
		enable_irq_wake(irq);
	...
	if (device_may_wakeup(dev))
		disable_irq_wake(irq);
	...
	device_init_wakeup(dev, false);
	...

We can replace it with just the following init and exit
time code:

	...
	device_init_wakeup(dev, true);
	dev_pm_set_wake_irq(dev, irq);
	...
	dev_pm_clear_wake_irq(dev);
	device_init_wakeup(dev, false);
	...

And for hardware with dedicated wake-up interrupts:

	...
	device_init_wakeup(dev, true);
	dev_pm_set_dedicated_wake_irq(dev, irq);
	...
	dev_pm_clear_wake_irq(dev);
	device_init_wakeup(dev, false);
	...
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4990d4fe
    • T
      PM / Runtime: Update last_busy in rpm_resume · 56f487c7
      由 Tony Lindgren 提交于 
      If we don't update last_busy in rpm_resume, devices can go back
to sleep immediately after resume. This happens at least in
cases where the device has been powered off and does not have
any interrupt pending until there's something in the FIFO.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      56f487c7
  39. 19 5月, 2015 2 次提交