1. 29 May, 2016 1 commit
  2. 24 Feb, 2016 1 commit
  3. 16 Nov, 2015 1 commit
  4. 13 Sep, 2015 2 commits
  5. 12 May, 2015 1 commit
  6. 26 Apr, 2015 3 commits
  7. 23 Feb, 2015 1 commit
  8. 04 Dec, 2014 1 commit
  9. 08 Sep, 2014 1 commit
  10. 04 Jun, 2014 1 commit
  11. 25 May, 2014 2 commits
  12. 12 May, 2014 1 commit
    • Geert Uytterhoeven's avatar
      drivers: sh: compile drivers/sh/pm_runtime.c if ARCH_SHMOBILE_MULTI · 3c90c55d
      Geert Uytterhoeven authored
      If the kernel is built to support multi-ARM configuration with shmobile
      support built in, then drivers/sh is not built. This contains the PM
      runtime code in drivers/sh/pm_runtime.c, which implicitly enables the
      module clocks for all devices, and thus is quite essential.
      Without this, the state of clocks depends on implicit reset state, or on
      the bootloader.
      If ARCH_SHMOBILE_MULTI then build the drivers/sh directory, but ensure that
      bits that may conflict (drivers/sh/clk if the common clock framework is
      enabled) or are not used (drivers/sh/intc), are not built.
      Also, only enable the PM runtime code when actually running on a shmobile
      SoCs that needs it.
      ARCH_SHMOBILE_MULTI was added a while ago by commit
      efacfce5 ("ARM: shmobile: Introduce
      ARCH_SHMOBILE_MULTI"), but drivers/sh was compiled for both
      bf98c1ea ("ARM: Rename ARCH_SHMOBILE to
      Inspired by a patch from Ben Dooks <ben.dooks@codethink.co.uk>.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
  13. 03 Jun, 2013 1 commit
  14. 10 Nov, 2011 2 commits
    • Paul Mundt's avatar
    • Paul Mundt's avatar
      drivers: sh: Generalize runtime PM platform stub. · 750a7eee
      Paul Mundt authored
      The runtime PM platform support stub in use by ARM-based SH/R-Mobile
      platforms contains nothing that's specifically ARM-related and instead of
      wholly generic to anything using the clock framework.
      The recent runtime PM changes interact rather badly with the lazy
      disabling of clocks late in the boot process through the clock framework,
      leading to situations where the runtime suspend/resume paths are entered
      without a clock being actively driven due to having been lazily gated
      In order to correct this we can trivially tie in the aforementioned stub
      as a general fallback for all SH platforms that don't presently have
      their own runtime PM implementations (the corner case being SH-based
      SH-Mobile platforms, which have their own stub through the hwblk API --
      which in turn has bitrotted and will be subsequently adapted to use the
      same stub as everyone else), regardless of whether the platforms choose
      to define power domains of their own or not.
      This fixes up regressions for clock framework users who also build in
      runtime PM support without any specific power domains of their own, which
      was previously causing the serial console to be lost when warring with
      lazy clock disabling.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  15. 25 Aug, 2011 1 commit
  16. 13 Jul, 2011 1 commit
  17. 10 Jul, 2011 1 commit
  18. 02 Jul, 2011 2 commits
    • Rafael J. Wysocki's avatar
      PM: Rename clock management functions · 3d5c3036
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
    • Rafael J. Wysocki's avatar
      PM / Domains: Rename struct dev_power_domain to struct dev_pm_domain · 564b905a
      Rafael J. Wysocki authored
      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: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarKevin Hilman <khilman@ti.com>
  19. 29 Apr, 2011 1 commit
  20. 28 Apr, 2011 2 commits
    • Rafael J. Wysocki's avatar
      PM / Runtime: Add subsystem data field to struct dev_pm_info · 1d2b71f6
      Rafael J. Wysocki authored
      Some subsystems need to attach PM-related data to struct device and
      they need to use devres for this purpose.  For their convenience
      and to make code more straightforward, add a new field called
      subsys_data to struct dev_pm_info and let subsystems use it for
      attaching PM-related information to devices.
      Convert the ARM shmobile platform to using the new field.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
    • Rafael J. Wysocki's avatar
      shmobile: Use power domains for platform runtime PM · 38ade3a1
      Rafael J. Wysocki authored
      shmobile platforms replace the runtime PM callbacks of the platform
      bus type with their own routines, but this means that the callbacks
      are replaced system-wide.  This may not be the right approach if the
      platform devices on the system are not of the same type (e.g. some
      of them belong to an SoC and the others are located in separate
      chips), because in those cases they may require different handling.
      Thus it is better to use power domains to override the platform bus
      type's PM handling, as it generally is possible to use different
      power domains for devices with different PM requirements.
      Define a default power domain for shmobile in both the SH and ARM
      falvors and use it to override the platform bus type's PM callbacks.
      Since the suspend and hibernate callbacks of the new "default" power
      domains need to be the same and the platform bus type's suspend and
      hibernate callbacks for the time being, export those callbacks so
      that can be used outside of the platform bus type code.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
  21. 15 Aug, 2010 1 commit