The common PM clock management functions may be used for system
suspend/resume as well as for runtime PM, so rename them
accordingly.  Modify kerneldoc comments describing these functions
and kernel messages printed by them, so that they refer to power
management in general rather that to runtime PM.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

The common clocks management code in drivers/base/power/clock_ops.c
is going to be used during system-wide power transitions as well as
for runtime PM, so it shouldn't depend on CONFIG_PM_RUNTIME.
However, the suspend/resume functions provided by it for
CONFIG_PM_RUNTIME unset, to be used during system-wide power
transitions, should not behave in the same way as their counterparts
defined for CONFIG_PM_RUNTIME set, because in that case the clocks
are managed differently at run time.

The names of the functions still contain the word "runtime" after
this change, but that is going to be modified by a separate patch
later.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

There is the problem how to handle devices set up to wake up the
system from sleep states during system-wide power transitions.
In some cases, those devices can be turned off entirely, because the
wakeup signals will be generated on their behalf anyway.  In some
other cases, they will generate wakeup signals if their clocks are
stopped, but only if power is not removed from them.  Finally, in
some cases, they can only generate wakeup signals if power is not
removed from them and their clocks are enabled.

To allow platform-specific code to decide whether or not to put
wakeup devices (and their PM domains) into low-power state during
system-wide transitions, such as system suspend, introduce a new
generic PM domain callback, .active_wakeup(), that will be used
during the "noirq" phase of system suspend and hibernation (after
image creation) to decide what to do with wakeup devices.
Specifically, if this callback is present and returns "true", the
generic PM domain code will not execute .stop_device() for the
given wakeup device and its PM domain won't be powered off.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

Make generic PM domains support system-wide power transitions
(system suspend and hibernation).  Add suspend, resume, freeze, thaw,
poweroff and restore callbacks to be associated with struct
generic_pm_domain objects and make pm_genpd_init() use them as
appropriate.

The new callbacks do nothing for devices belonging to power domains
that were powered down at run time (before the transition).  For the
other devices the action carried out depends on the type of the
transition.  During system suspend the power domain .suspend()
callback executes pm_generic_suspend() for the device, while the
PM domain .suspend_noirq() callback runs pm_generic_suspend_noirq()
for it, stops it and eventually removes power from the PM domain it
belongs to (after all devices in the domain have been stopped and its
subdomains have been powered off).

During system resume the PM domain .resume_noirq() callback
restores power to the PM domain (when executed for it first time),
starts the device and executes pm_generic_resume_noirq() for it,
while the .resume() callback executes pm_generic_resume() for the
device.  Finally, the .complete() callback executes pm_runtime_idle()
for the device which should put it back into the suspended state if
its runtime PM usage count is equal to zero at that time.

The actions carried out during hibernation and resume from it are
analogous to the ones described above.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

There is some code in drivers/base/power/domain.c that will be useful
for both runtime PM and system-wide power transitions, so make it
depend on CONFIG_PM instead of CONFIG_PM_RUNTIME.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Introduce generic "noirq" power management callback routines for
subsystems in addition to the "regular" generic PM callback routines.

The new routines will be used, among other things, for implementing
system-wide PM transitions support for generic PM domains.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Introduce common headers, helper functions and callbacks allowing
platforms to use simple generic power domains for runtime power
management.

Introduce struct generic_pm_domain to be used for representing
power domains that each contain a number of devices and may be
parent domains or subdomains with respect to other power domains.
Among other things, this structure includes callbacks to be
provided by platforms for performing specific tasks related to
power management (i.e. ->stop_device() may disable a device's
clocks, while ->start_device() may enable them, ->power_off() is
supposed to remove power from the entire power domain
and ->power_on() is supposed to restore it).

Introduce functions that can be used as power domain runtime PM
callbacks, pm_genpd_runtime_suspend() and pm_genpd_runtime_resume(),
as well as helper functions for the initialization of a power
domain represented by a struct generic_power_domain object,
adding a device to or removing a device from it and adding or
removing subdomains.

Introduce configuration option CONFIG_PM_GENERIC_DOMAINS to be
selected by the platforms that want to use the new code.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Reviewed-by: NKevin Hilman <khilman@ti.com>

The subsys_data field of struct dev_pm_info, introduced by commit
1d2b71f6 (PM / Runtime: Add subsystem
data field to struct dev_pm_info), is going to be used even if
CONFIG_PM_RUNTIME is not set, so move it from under the #ifdef.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The naming convention used by commit 7538e3db6e015e890825fbd9f86599b
(PM: Add support for device power domains), which introduced the
struct dev_power_domain type for representing device power domains,
evidently confuses some developers who tend to think that objects
of this type must correspond to "power domains" as defined by
hardware, which is not the case.  Namely, at the kernel level, a
struct dev_power_domain object can represent arbitrary set of devices
that are mutually dependent power management-wise and need not belong
to one hardware power domain.  To avoid that confusion, rename struct
dev_power_domain to struct dev_pm_domain and rename the related
pointers in struct device and struct pm_clk_notifier_block from
pwr_domain to pm_domain.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

Commit e1866b33 (PM / Runtime: Rework
runtime PM handling during driver removal) forgot to update the
documentation in Documentation/power/runtime_pm.txt to match the new
code in drivers/base/dd.c.  Update that documentation to match the
code it describes.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Replace reference to pm_runtime_idle_sync() in the driver core with
pm_runtime_put_sync() which is used in the code.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
  drm/i915: apply HWSTAM writes to Ivy Bridge as well
  drm/i915: move IRQ function table init to i915_irq.c
  drm/i915/overlay: Fix unpinning along init error paths
  drm/i915: Don't call describe_obj on NULL pointers
  drm/i915: Hold struct_mutex during i915_save_state/i915_restore_state

In an attempt to fix 38862 and 38863.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

* 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ.
  xen/mmu: Fix for linker errors when CONFIG_SMP is not defined.

When 3.0 is released I believe the README should reflect the new
numbering.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

David Brownell's CREDITS entry should have N: (name) instead of
M: (email).
Signed-off-by: NHenrik Ahlgren <pablo@seestieto.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

CE variant requires a different chremap setup.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=35472Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (24 commits)
  usbnet: Remove over-broad module alias from zaurus.
  MAINTAINERS: drop Michael from bfin_mac driver
  net/can: activate bit-timing calculation and netlink based drivers by default
  rionet: fix NULL pointer dereference in rionet_remove
  net+crypto: Use vmalloc for zlib inflate buffers.
  netfilter: Fix ip_route_me_harder triggering ip_rt_bug
  ipv4: Fix IPsec slowpath fragmentation problem
  ipv4: Fix packet size calculation in __ip_append_data
  cxgb3: skb_record_rx_queue now records the queue index relative to the net_device.
  bridge: Only flood unregistered groups to routers
  qlge: Add maintainer.
  MAINTAINERS: mark socketcan-core lists as subscribers-only
  MAINTAINERS: Remove Sven Eckelmann from BATMAN ADVANCED
  r8169: fix wrong register use.
  net/usb/kalmia: signedness bug in kalmia_bind()
  net/usb: kalmia: Various fixes for better support of non-x86 architectures.
  rtl8192cu: Fix missing firmware load
  udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
  ipv6/udp: Use the correct variable to determine non-blocking condition
  netconsole: fix build when CONFIG_NETCONSOLE_DYNAMIC is turned on
  ...

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/avr32-2.6:
  MAINTAINERS: update AVR32 and AT32AP maintainers

* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
  watchdog: update author email for at32ap700x_wdt
  watchdog: gef_wdt: fix MODULE_ALIAS
  watchdog: Intel SCU Watchdog: Fix build and remove duplicate code
  watchdog: mtx1-wdt: fix section mismatch
  watchdog: mtx1-wdt: fix GPIO toggling
  watchdog: mtx1-wdt: request gpio before using it
  watchdog: Handle multiple wm831x watchdogs being registered

* 'sh-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x:
  sh: use printk_ratelimited instead of printk_ratelimit
  sh: Fix up unmet dependency warnings with USB EHCI/OHCI selects.
  sh: fix the value of sh_dmae_slave_config in setup-sh7757
  sh: fix the INTC vector for IRQ and IRL in setup-sh7757
  sh: add to select the new configuration for USB EHCI/OHCI
  sh: add platform_device of EHCI/OHCI to setup-sh7757
  sh: fix compile error using sh7757lcr_defconfig

Merge branch 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x

* 'rmobile-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-3.x:
  ARM: mach-shmobile: make a struct in board-ap4evb.c static
  ARM: mach-shmobile: ag5evm: consistently name sdhi info structures
  ARM: mach-shmobile: mackerel: change usbhs devices order

In the past we would use the GSI value to preset the ACPI SCI
IRQ which worked great as GSI == IRQ:

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)

While that is most often seen, there are some oddities:

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)

which means that GSI 20 (or pin 20) is to be overriden for IRQ 9.
Our code that presets the interrupt for ACPI SCI however would
use the GSI 20 instead of IRQ 9 ending up with:

xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=20
xen: acpi sci 20
.. snip..
calling  acpi_init+0x0/0xbc @ 1
ACPI: SCI (IRQ9) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119)
ACPI: Unable to start the ACPI Interpreter

as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which got nine.
It used that value to request an IRQ (request_irq) and since that was not
present it failed.

The fix is to recognize that for interrupts that are overriden (in our
case we only care about the ACPI SCI) we should use the IRQ number
to present the IRQ instead of the using GSI. End result is that we get:

xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=9 (gsi=9)
xen: acpi sci 9

which fixes the ACPI interpreter failing on startup.

CC: stable@kernel.org
Reported-by: NLiwei <xieliwei@gmail.com>
Tested-by: NLiwei <xieliwei@gmail.com>
[http://lists.xensource.com/archives/html/xen-devel/2011-06/msg01727.html]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Simple enough - we use an extern defined symbol which is not
defined when CONFIG_SMP is not defined. This fixes the linker
dying.

CC: stable@kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This alters the maintenance of the AVR32 architecture and the AT32AP machine
code to be shared between Haavard Skinnemoen and me. The status is also changed
to maintained, as we no longer are being paid to look after this architecture.
Signed-off-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Acked-by: NHaavard Skinnemoen <hskinnemoen@gmail.com>

Follows the powerpc change, for much the same rationale.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

struct soc_camera_link imx074_link in board-ap4evb.c doesn't have
to be global.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This lets us make the various IRQ functions static and helps avoid
problems like the one fixed in "drm/i915: Use chipset-specific irq
installers" where one of the exported functions was called rather than
the chipset specific version.

This also fixes a UMS-mode bug -- the correct irq functions for IRL
and later chips were only getting loaded in the KMS path.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

As pointed out by Dan Carpenter, it was seemingly possible to hit an error
whilst mapping the buffer for the regs (except the only likely error
returns should not happen during init) and so leak a pin count on the
bo. To handle this we would need to reacquire the struct mutex, so for
simplicity rearrange for the lock to be held for the entire function.
For extra pedagogy, test that we only call init once.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/radeon/kms: increase rom size for atrm method

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: caam - fix operator precedence in shared descriptor allocation

The vbios rom is >64k on a lot of modern asics.  Increase
the fetch size for atrm to make sure we don't miss part
of a larger rom.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

setkey allocates 16 bytes (CAAM_CMD_SZ *
DESC_AEAD_SHARED_TEXT_LEN) shy of what is needed to
store the shared descriptor, resulting in memory
corruption.  Fix this.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Reported-by: NPavel Roskin <proski@gnu.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38777
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Lots of register access in these functions, some of which requires the
struct mutex.

These functions now hold the struct mutex across the calls to
i915_save_display and i915_restore_display, and so the internal mutex
calls in those functions have been removed. To ensure that no-one else
was calling them (and hence violating the new required locking
invarient), those functions have been made static.

gen6_enable_rps locks the struct mutex, and so i915_restore_state
unlocks the mutex around calls to that function.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

* 'kvm-updates/3.0' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86 emulator: fix %rip-relative addressing with immediate source operand

* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
  i2c/pca954x: Initialize the mux to disconnected state
  i2c-taos-evm: Fix log messages

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  arch/powerpc: use printk_ratelimited instead of printk_ratelimit
  powerpc/rtas-rtc: remove sideeffects of printk_ratelimit
  powerpc/pseries: remove duplicate SCSI_BNX2_ISCSI in pseries_defconfig
  powerpc/e500: fix breakage with fsl_rio_mcheck_exception
  powerpc/p1022ds: fix audio-related properties in the device tree
  powerpc/85xx: fix NAND_CMD_READID read bytes number

It's not so much an error as a warning about normal Marvell crazines.
So don't use KERN_ERR that ends up spamming the console even in quiet
mode, it's not _that_ critical.

Explained by Jeff:

 "Long explanation, it's a mess:

  Marvell took standard AHCI, and bastardized it to include a weird mode
  whereby PATA devices appear inside the AHCI DMA and interrupt
  infrastructure you're familiar with.

  So, PATA devices appear via pata_marvell driver, using basic legacy
  IDE programming interface.  But SATA devices, which might also be
  attached to this chip, either work in under-performing mode or
  simply don't work at all (e.g.  newer 6 Gbps devices or port
  multiplier attachments, NCQ, ...)

  On the other hand, 'ahci' driver loads and works with the chip's
  attached SATA devices quite beautifully, but is completely unable to
  drive any attached PATA devices, due to the Marvell-specific
  PATA-under-AHCI interface.

  The "masking port_map 0x7 -> 0x3" message is the ahci driver "hiding"
  the PATA port(s) from itself, making sure it will only drive the SATA
  ports it knows how to drive."
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>