1. 14 3月, 2012 1 次提交
    • R
      PM / QoS: Make it possible to expose PM QoS latency constraints · 85dc0b8a
      Rafael J. Wysocki 提交于
      A runtime suspend of a device (e.g. an MMC controller) belonging to
      a power domain or, in a more complicated scenario, a runtime suspend
      of another device in the same power domain, may cause power to be
      removed from the entire domain.  In that case, the amount of time
      necessary to runtime-resume the given device (e.g. the MMC
      controller) is often substantially greater than the time needed to
      run its driver's runtime resume callback.  That may hurt performance
      in some situations, because user data may need to wait for the
      device to become operational, so we should make it possible to
      prevent that from happening.
      
      For this reason, introduce a new sysfs attribute for devices,
      power/pm_qos_resume_latency_us, allowing user space to specify the
      upper bound of the time necessary to bring the (runtime-suspended)
      device up after the resume of it has been requested.  However, make
      that attribute appear only for the devices whose drivers declare
      support for it by calling the (new) dev_pm_qos_expose_latency_limit()
      helper function with the appropriate initial value of the attribute.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      85dc0b8a
  2. 13 2月, 2012 1 次提交
    • J
      PM / QoS: unconditionally build the feature · a9b542ee
      Jean Pihet 提交于
      The PM QoS feature originally didn't depend on CONFIG_PM, which was
      mistakenly changed by commit e8db0be1
      
          PM QoS: Move and rename the implementation files
      
      Later, commit d020283d
      
          PM / QoS: CPU C-state breakage with PM Qos change
      
      partially fixed that by introducing a static inline definition of
      pm_qos_request(), but that still didn't allow user space to use
      the PM QoS interface if CONFIG_PM was unset (which had been possible
      before).  For this reason, remove the dependency of PM QoS on
      CONFIG_PM to make it work (as intended) with CONFIG_PM unset.
      
      [rjw: Replaced the original changelog with a new one.]
      Signed-off-by: NJean Pihet <j-pihet@ti.com>
      Reported-by: NVenkatesh Pallipadi <venki@google.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a9b542ee
  3. 05 2月, 2012 1 次提交
    • V
      PM / QoS: CPU C-state breakage with PM Qos change · d020283d
      Venkatesh Pallipadi 提交于
      Looks like change "PM QoS: Move and rename the implementation files"
      merged during the 3.2 development cycle made PM QoS depend on
      CONFIG_PM which depends on (PM_SLEEP || PM_RUNTIME).
      
      That breaks CPU C-states with kernels not having these CONFIGs, causing CPUs
      to spend time in Polling loop idle instead of going into deep C-states,
      consuming way way more power. This is with either acpi idle or intel idle
      enabled.
      
      Either CONFIG_PM should be enabled with any pm_qos users or
      the !CONFIG_PM pm_qos_request() should return sane defaults not to break
      the existing users. Here's is the patch for the latter option.
      
      [rjw: Modified the changelog slightly.]
      Signed-off-by: NVenkatesh Pallipadi <venki@google.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: stable@vger.kernel.org
      d020283d
  4. 31 1月, 2012 1 次提交
  5. 30 1月, 2012 4 次提交
    • A
      PM / QoS: Simplify PM QoS expansion/merge · d031e1de
      Alex Frid 提交于
       - Replace class ID #define with enumeration
       - Loop through PM QoS objects during initialization (rather than
         initializing them one-by-one)
      Signed-off-by: NAlex Frid <afrid@nvidia.com>
      Reviewed-by: NAntti Miettinen <amiettinen@nvidia.com>
      Reviewed-by: NDiwakar Tundlam <dtundlam@nvidia.com>
      Reviewed-by: NScott Williams <scwilliams@nvidia.com>
      Reviewed-by: NYu-Huan Hsu <yhsu@nvidia.com>
      Acked-by: Nmarkgross <markgross@thegnar.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d031e1de
    • R
      PM / Sleep: Introduce generic callbacks for new device PM phases · e470d066
      Rafael J. Wysocki 提交于
      Introduce generic subsystem callbacks for the new phases of device
      suspend/resume during system power transitions: "late suspend",
      "early resume", "late freeze", "early thaw", "late poweroff",
      "early restore".
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e470d066
    • R
      PM / Sleep: Introduce "late suspend" and "early resume" of devices · cf579dfb
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      cf579dfb
    • R
      PM / Hibernate: Fix s2disk regression related to freezing workqueues · 181e9bde
      Rafael J. Wysocki 提交于
      Commit 2aede851
      
        PM / Hibernate: Freeze kernel threads after preallocating memory
      
      introduced a mechanism by which kernel threads were frozen after
      the preallocation of hibernate image memory to avoid problems with
      frozen kernel threads not responding to memory freeing requests.
      However, it overlooked the s2disk code path in which the
      SNAPSHOT_CREATE_IMAGE ioctl was run directly after SNAPSHOT_FREE,
      which caused freeze_workqueues_begin() to BUG(), because it saw
      that worqueues had been already frozen.
      
      Although in principle this issue might be addressed by removing
      the relevant BUG_ON() from freeze_workqueues_begin(), that would
      reintroduce the very problem that commit 2aede851
      attempted to avoid into that particular code path.  For this reason,
      to fix the issue at hand, introduce thaw_kernel_threads() and make
      the SNAPSHOT_FREE ioctl execute it.
      
      Special thanks to Srivatsa S. Bhat for detailed analysis of the
      problem.
      Reported-and-tested-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: stable@kernel.org
      181e9bde
  6. 28 1月, 2012 1 次提交
  7. 27 1月, 2012 1 次提交
  8. 25 1月, 2012 5 次提交
  9. 24 1月, 2012 9 次提交
    • A
      usb: otg: kill langwell_otg driver · c1084a56
      Alexander Shishkin 提交于
      The way this driver was added by f0ae849d (usb: Add Intel Langwell USB
      OTG Transceiver Driver) never even compiled together with langwell_udc,
      and that's the only way for it to be useful.
      Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: stable@vger.kernel.org # v2.6.31+
      Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: linux-usb@vger.kernel.org
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c1084a56
    • S
      migrate_mode.h is not exported to user mode · c1aab02d
      Stephen Rothwell 提交于
      so move its include into fs.h inside the __KERNEL__ protection.
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c1aab02d
    • R
      kernel-doc: fix kernel-doc warnings in sched · fa757281
      Randy Dunlap 提交于
      Fix new kernel-doc notation warnings:
      
      Warning(include/linux/sched.h:2094): No description found for parameter 'p'
      Warning(include/linux/sched.h:2094): Excess function parameter 'tsk' description in 'is_idle_task'
      Warning(kernel/sched/cpupri.c:139): No description found for parameter 'newpri'
      Warning(kernel/sched/cpupri.c:139): Excess function parameter 'pri' description in 'cpupri_set'
      Warning(kernel/sched/cpupri.c:208): Excess function parameter 'bootmem' description in 'cpupri_init'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc:	Ingo Molnar <mingo@elte.hu>
      Cc:	Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fa757281
    • R
      kernel-doc: fix new warnings in cfg80211.h · 2f6c76aa
      Randy Dunlap 提交于
      Fix new kernel-doc warnings:
      
      Warning(include/net/cfg80211.h:1165): No description found for parameter 'channel_type'
      Warning(include/net/cfg80211.h:2090): No description found for parameter 'probe_resp_offload'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc:	Johannes Berg <johannes@sipsolutions.net>
      Cc:	linux-wireless@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f6c76aa
    • R
      kernel-doc: fix new warning in usb.h · 4d922612
      Randy Dunlap 提交于
      Fix new kernel-doc warning:
      
      Warning(include/linux/usb.h:1251): No description found for parameter 'num_mapped_sgs'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d922612
    • R
      kernel-doc: fix new warnings in device.h · 2eda013f
      Randy Dunlap 提交于
      Fix new kernel-doc warnings:
      
      Warning(include/linux/device.h:299): No description found for parameter 'name'
      Warning(include/linux/device.h:299): No description found for parameter 'subsys'
      Warning(include/linux/device.h:299): No description found for parameter 'node'
      Warning(include/linux/device.h:299): No description found for parameter 'add_dev'
      Warning(include/linux/device.h:299): No description found for parameter 'remove_dev'
      Warning(include/linux/device.h:685): No description found for parameter 'id'
      Warning(include/linux/device.h:1009): No description found for parameter '__driver'
      Warning(include/linux/device.h:1009): No description found for parameter '__register'
      Warning(include/linux/device.h:1009): No description found for parameter '__unregister'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2eda013f
    • H
      SHM_UNLOCK: fix Unevictable pages stranded after swap · 24513264
      Hugh Dickins 提交于
      Commit cc39c6a9 ("mm: account skipped entries to avoid looping in
      find_get_pages") correctly fixed an infinite loop; but left a problem
      that find_get_pages() on shmem would return 0 (appearing to callers to
      mean end of tree) when it meets a run of nr_pages swap entries.
      
      The only uses of find_get_pages() on shmem are via pagevec_lookup(),
      called from invalidate_mapping_pages(), and from shmctl SHM_UNLOCK's
      scan_mapping_unevictable_pages().  The first is already commented, and
      not worth worrying about; but the second can leave pages on the
      Unevictable list after an unusual sequence of swapping and locking.
      
      Fix that by using shmem_find_get_pages_and_swap() (then ignoring the
      swap) instead of pagevec_lookup().
      
      But I don't want to contaminate vmscan.c with shmem internals, nor
      shmem.c with LRU locking.  So move scan_mapping_unevictable_pages() into
      shmem.c, renaming it shmem_unlock_mapping(); and rename
      check_move_unevictable_page() to check_move_unevictable_pages(), looping
      down an array of pages, oftentimes under the same lock.
      
      Leave out the "rotate unevictable list" block: that's a leftover from
      when this was used for /proc/sys/vm/scan_unevictable_pages, whose flawed
      handling involved looking at pages at tail of LRU.
      
      Was there significance to the sequence first ClearPageUnevictable, then
      test page_evictable, then SetPageUnevictable here? I think not, we're
      under LRU lock, and have no barriers between those.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Reviewed-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: <stable@vger.kernel.org> [back to 3.1 but will need respins]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      24513264
    • M
      kdump: define KEXEC_NOTE_BYTES arch specific for s390x · cb78edfd
      Michael Holzheu 提交于
      kdump only allocates memory for the prstatus ELF note.  For s390x,
      besides of prstatus multiple ELF notes for various different register
      types are stored.  Therefore the currently allocated memory is not
      sufficient.  With this patch the KEXEC_NOTE_BYTES macro can be defined
      by architecture code and for s390x it is set to the correct size now.
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cb78edfd
    • A
      mm: fix warnings regarding enum migrate_mode · 6536e312
      Andrew Morton 提交于
      sparc64 allmodconfig:
      
      In file included from include/linux/compat.h:15,
                       from /usr/src/25/arch/sparc/include/asm/siginfo.h:19,
                       from include/linux/signal.h:5,
                       from include/linux/sched.h:73,
                       from arch/sparc/kernel/asm-offsets.c:13:
      include/linux/fs.h:618: warning: parameter has incomplete type
      
      It seems that my sparc64 compiler (gcc-3.4.5) doesn't like the forward
      declaration of enums.
      
      Fix this by moving the "enum migrate_mode" definition into its own header
      file.
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andy Isaacson <adi@hexapodia.org>
      Cc: Nai Xia <nai.xia@gmail.com>
      Cc: Johannes Weiner <jweiner@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6536e312
  10. 23 1月, 2012 9 次提交
  11. 21 1月, 2012 4 次提交
    • R
      MFD: mcp-core: fix mcp_priv() to be more type safe · 2a7f51a3
      Russell King 提交于
      mcp_priv() does unexpected things when passed a void pointer.  Make it
      a typed inline function, which ensures that it works correctly in
      these cases.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2a7f51a3
    • M
      ACPI: Remove ./drivers/acpi/atomicio.[ch] · 1001a3a3
      Myron Stowe 提交于
      With the conversion of atomicio's routines in place (see commits
      6f68c91c and 700130b4), atomicio.[ch] can be removed, replacing
      the APEI specific pre-mapping capabilities with the more generalized
      versions that drivers/acpi/osl.c provides.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1001a3a3
    • M
      ACPI, APEI: Add 64-bit read/write support for APEI on i386 · e615bf5b
      Myron Stowe 提交于
      Base ACPI (CA) currently does not support atomic 64-bit reads and writes
      (acpi_read() and acpi_write() split 64-bit loads/stores into two
      32-bit transfers) yet APEI expects 64-bit transfer capability, even
      when running on 32-bit systems.
      
      This patch implements 64-bit read and write routines for APEI usage.
      
      This patch re-factors similar functionality introduced in commit
      04c25997, bringing it into the ACPI subsystem in preparation for
      removing ./drivers/acpi/atomicio.[ch].  In the implementation I have
      replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
      64-bit versions for APEI to utilize, as opposed to something more
      elegant.  My thinking is that we should attempt to see if we can get
      ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
      interfaces are natively 64-bit capable and then subsequently remove the
      replication.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e615bf5b
    • R
      Revert "ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus." · 65f2e753
      Russell King 提交于
      This reverts commit 5dd7bf59.
      
      Conflicts:
      
      	scripts/mod/file2alias.c
      
      This change is wrong on many levels.  First and foremost, it causes a
      regression.  On boot on Assabet, which this patch gives a codec id of
      'ucb1x00', it gives:
      
      	ucb1x00 ID not found: 1005
      
      0x1005 is a valid ID for the UCB1300 device.
      
      Secondly, this patch is way over the top in terms of complexity.  The
      only device which has been seen to be connected with this MCP code is
      the UCB1x00 (UCB1200, UCB1300 etc) devices, and they all use the same
      driver.  Adding a match table, requiring the codec string to match the
      hardware ID read out of the ID register, etc is completely over the top
      when we can just read the hardware ID register.
      65f2e753
  12. 20 1月, 2012 2 次提交
    • T
      ACPI processor hotplug: Delay acpi_processor_start() call for hotplugged cores · 99b72508
      Thomas Renninger 提交于
      Delay the setting up of features (cpuidle, throttling by calling
      acpi_processor_start()) to the time when the hotplugged
      core got onlined the first time and got fully
      initialized.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      99b72508
    • S
      PM / Hibernate: Rewrite unlock_system_sleep() to fix s2disk regression · 72081624
      Srivatsa S. Bhat 提交于
      Commit 33e638b9, "PM / Sleep: Use the freezer_count() functions in
      [un]lock_system_sleep() APIs" introduced an undesirable change in the
      behaviour of unlock_system_sleep() since freezer_count() internally calls
      try_to_freeze() - which we don't need in unlock_system_sleep().
      
      And commit bcda53fa, "PM / Sleep: Replace mutex_[un]lock(&pm_mutex) with
      [un]lock_system_sleep()" made these APIs wide-spread. This caused a
      regression in suspend-to-disk where snapshot_read() and snapshot_write()
      were getting frozen due to the try_to_freeze embedded in
      unlock_system_sleep(), since these functions were invoked when the freezing
      condition was still in effect.
      
      Fix this by rewriting unlock_system_sleep() by open-coding freezer_count()
      and dropping the try_to_freeze() part. Not only will this fix the
      regression but this will also ensure that the API only does what it is
      intended to do, and nothing more, under the hood.
      
      While at it, make the code more correct and robust by ensuring that the
      PF_FREEZER_SKIP flag gets cleared with pm_mutex held, to avoid a race with
      the freezer.
      
      Also, to be on the safer side, open-code freezer_do_not_count() as well
      (inside lock_system_sleep()), to ensure that any unrelated modification to
      freezer[_do_not]_count() does not break things again!
      Reported-and-tested-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      72081624
  13. 19 1月, 2012 1 次提交