1. 28 10月, 2014 2 次提交
    • G
      cpufreq: cpufreq-dt: Restore default cpumask_setall(policy->cpus) · c81407fe
      Geert Uytterhoeven 提交于
      Commit 34e5a527 ("cpufreq: cpufreq-dt: extend with
      platform_data") changed cpufreq_init() to only call
      cpumask_setall(policy->cpus) if the platform data indicates that all
      CPUs share the same clock. Before, cpufreq_generic_init() did this
      unconditionally.
      
      This causes a crash on r8a7791/koelsch when resuming from s2ram:
      
          Enabling non-boot CPUs ...
          CPU1: Booted secondary processor
          Unable to handle kernel NULL pointer dereference at virtual address 0000003c
          pgd = ee71f980
          [0000003c] *pgd=6eeb6003, *pmd=6e0e9003, *pte=00000000
          Internal error: Oops: a07 [#1] SMP ARM
          Modules linked in:
          CPU: 0 PID: 1397 Comm: s2ram Tainted: G        W      3.18.0-rc2-koelsch-00762-g7eed2a4e61d2d978 #581
          task: ee6b76c0 ti: ee7f0000 task.ti: ee7f0000
          PC is at __cpufreq_add_dev.isra.24+0x24c/0x77c
          LR is at __cpufreq_add_dev.isra.24+0x244/0x77c
          pc : [<c029e084>]    lr : [<c029e07c>]    psr: 60000153
          sp : ee7f1d48  ip : ee7f1d48  fp : ee7f1d84
          r10: c04e8448  r9 : 00000000  r8 : 00000001
          r7 : c054a8c4  r6 : 00000001  r5 : 00000001  r4 : 00000000
          r3 : 00000000  r2 : 00000000  r1 : 20000153  r0 : c054a950
          Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment user
          Control: 30c5307d  Table: 6e71f980  DAC: fffffffd
          Process s2ram (pid: 1397, stack limit = 0xee7f0240)
      
          ...
      
          Backtrace:
          [<c029de38>] (__cpufreq_add_dev.isra.24) from [<c029e620>] (cpufreq_cpu_callback+0x6c/0x74)
           r10:eec75240 r9:c04e8448 r8:c04ef3a0 r7:00000001 r6:00000012 r5:00000000
           r4:00000012
          [<c029e5b4>] (cpufreq_cpu_callback) from [<c003f20c>] (notifier_call_chain+0x48/0x70)
           r4:ffffffdd r3:c029e5b4
          [<c003f1c4>] (notifier_call_chain) from [<c003f2cc>] (__raw_notifier_call_chain+0x1c/0x24)
           r8:00000001 r7:00000010 r6:00000000 r5:00000000 r4:00000012 r3:ffffffff
          [<c003f2b0>] (__raw_notifier_call_chain) from [<c0026a00>] (__cpu_notify+0x34/0x50)
          [<c00269cc>] (__cpu_notify) from [<c0026a34>] (cpu_notify+0x18/0x1c)
           r4:00000001
          [<c0026a1c>] (cpu_notify) from [<c0026c44>] (_cpu_up+0x108/0x144)
          [<c0026b3c>] (_cpu_up) from [<c0381c68>] (enable_nonboot_cpus+0x68/0xb8)
           r10:00000000 r9:c04e8ee6 r8:00000000 r7:00000003 r6:c04e8528 r5:c0506248
           r4:00000001
          [<c0381c00>] (enable_nonboot_cpus) from [<c0059038>] (suspend_devices_and_enter+0x29c/0x3e8)
           r6:c0506e70 r5:00000000 r4:00000000 r3:60000153
      
      Restore the old default of calling cpumask_setall(policy->cpus) if no
      platform data is available to fix this.
      
      Fixes: 34e5a527 (cpufreq: cpufreq-dt: extend with platform_data)
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c81407fe
    • L
      cpufreq: cpufreq-dt: disable unsupported OPPs · 045ee45c
      Lucas Stach 提交于
      If the regulator connected to the CPU voltage plane doesn't
      support an OPP specified voltage with the acceptable tolerance
      it's better to just disable the OPP instead of constantly
      failing the voltage scaling later on.
      
      Includes a fix to move initialization of opp_freq outside
      the loop to avoid an endless loop from Geert Uytterhoeven.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      045ee45c
  2. 21 10月, 2014 2 次提交
  3. 03 10月, 2014 2 次提交
  4. 09 9月, 2014 7 次提交
  5. 07 8月, 2014 1 次提交
  6. 16 7月, 2014 1 次提交
  7. 10 6月, 2014 1 次提交
  8. 20 5月, 2014 1 次提交
  9. 12 3月, 2014 1 次提交
  10. 17 1月, 2014 1 次提交
  11. 07 12月, 2013 1 次提交
  12. 04 12月, 2013 1 次提交
    • E
      cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties · 77cff592
      Eduardo Valentin 提交于
      This patch changes the cpufreq-cpu0 driver to consider if
      a cpu needs cooling (with cpufreq). In case the cooling is needed,
      the cpu0 device tree node needs to be properly configured
      with cooling device properties.
      
      In case these properties are present,, the driver will
      load a cpufreq cooling device in the system. The cpufreq-cpu0
      driver is not interested in determining how the system should
      be using the cooling device. The driver is responsible
      only of loading the cooling device.
      
      Describing how the cooling device will be used can be
      accomplished by setting up a thermal zone that references
      and is composed by the cpufreq cooling device.
      
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: cpufreq@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: devicetree-discuss@lists.ozlabs.org
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NEduardo Valentin <eduardo.valentin@ti.com>
      77cff592
  13. 31 10月, 2013 1 次提交
  14. 26 10月, 2013 4 次提交
  15. 16 10月, 2013 3 次提交
  16. 01 10月, 2013 2 次提交
  17. 19 9月, 2013 1 次提交
  18. 21 8月, 2013 1 次提交
  19. 15 8月, 2013 1 次提交
  20. 14 8月, 2013 1 次提交
  21. 05 6月, 2013 1 次提交
  22. 12 5月, 2013 2 次提交
    • V
      cpufreq: cpufreq-cpu0: Free parent node for error cases · 5aaa9cc7
      Viresh Kumar 提交于
      We are freeing parent node in success cases but not in failure cases.
      Let's do it.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5aaa9cc7
    • N
      cpufreq: cpufreq-cpu0: defer probe when regulator is not ready · fc31d6f5
      Nishanth Menon 提交于
      With commit 1e4b545c, regulator_get will now return -EPROBE_DEFER
      when the cpu0-supply node is present, but the regulator is not yet
      registered.
      
      It is possible for this to occur when the regulator registration
      by itself might be defered due to some dependent interface not yet
      instantiated. For example: an regulator which uses I2C and GPIO might
      need both systems available before proceeding, in this case, the
      regulator might defer it's registration.
      
      However, the cpufreq-cpu0 driver assumes that any un-successful
      return result is equivalent of failure.
      
      When the regulator_get returns failure other than -EPROBE_DEFER, it
      makes sense to assume that supply node is not present and proceed
      with the assumption that only clock control is necessary in the
      platform.
      
      With this change, we can now handle the following conditions:
       a) cpu0-supply binding is not present, regulator_get will return
          appropriate error result, resulting in cpufreq-cpu0 driver
          controlling just the clock.
       b) cpu0-supply binding is present, regulator_get returns
          -EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver
          registering later once the regulator is available.
       c) cpu0-supply binding is present, regulator_get returns
          -EPROBE_DEFER, however, regulator never registers, we retry until
          cpufreq-cpu0 driver fails to register pointing at device tree
          information bug. However, in this case, the fact that
          cpufreq-cpu0 operates with clock only when the DT binding clearly
          indicates need of a supply is a bug of it's own.
       d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
          controls both the clock and regulator
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fc31d6f5
  23. 22 4月, 2013 1 次提交
  24. 02 4月, 2013 1 次提交