1. 05 6月, 2013 1 次提交
  2. 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
  3. 22 4月, 2013 1 次提交
  4. 02 4月, 2013 4 次提交
    • V
      cpufreq: Notify all policy->cpus in cpufreq_notify_transition() · b43a7ffb
      Viresh Kumar 提交于
      policy->cpus contains all online cpus that have single shared clock line. And
      their frequencies are always updated together.
      
      Many SMP system's cpufreq drivers take care of this in individual drivers but
      the best place for this code is in cpufreq core.
      
      This patch modifies cpufreq_notify_transition() to notify frequency change for
      all cpus in policy->cpus and hence updates all users of this API.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NStephen Warren <swarren@nvidia.com>
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b43a7ffb
    • V
      cpufreq: cpufreq-cpu0: Call CPUFREQ_POSTCHANGE notifier for failure cases too · fd143b4d
      Viresh Kumar 提交于
      Currently we are simply returning from target() if we encounter some error after
      broadcasting CPUFREQ_PRECHANGE notifier. Which looks to be wrong as others might
      depend on POSTCHANGE notifier for their functioning.
      
      So, better broadcast CPUFREQ_POSTCHANGE notifier for these failure cases too,
      but with old frequency.
      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>
      fd143b4d
    • V
      cpufreq: cpufreq-cpu0: No need to check cpu number in init() · 746b3df9
      Viresh Kumar 提交于
      It is not possible for init() to be called for any cpu other than cpu0. During
      bootup whatever cpu is used to boot system will be assigned as cpu0. And later
      on policy->cpu can only change if we hotunplug all cpus first and then hotplug
      them back in different order, which isn't possible (system requires atleast one
      cpu to be up always :)).
      
      Though I can see one situation where policy->cpu can be different then zero.
      - Hot-unplug cpu 0.
      - rmmod cpufreq-cpu0 module
      - insmod it back
      - hotplug cpu 0 again.
      
      Here, policy->cpu would be different. But the driver doesn't have any dependency
      on cpu0 as such. We don't mind which cpu of a system is policy->cpu and so this
      check is just not required.
      
      Remove 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>
      746b3df9
    • P
      cpufreq: check OF node /cpus presence before dereferencing it · f5c3ef21
      Paolo Pisati 提交于
      Check for the presence of the '/cpus' OF node before dereferencing it
      blindly:
      
      [    4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c
      [    4.181793] pgd = c0004000
      [    4.181823] [0000001c] *pgd=00000000
      [    4.181823] Internal error: Oops: 5 [#1] SMP ARM
      [    4.181823] Modules linked in:
      [    4.181823] CPU: 1    Tainted: G        W     (3.8.0-15-generic #25~hbankD)
      [    4.181854] PC is at of_get_next_child+0x64/0x70
      [    4.181854] LR is at of_get_next_child+0x24/0x70
      [    4.181854] pc : [<c04fda18>]    lr : [<c04fd9d8>]    psr: 60000113
      [    4.181854] sp : ed891ec0  ip : ed891ec0  fp : ed891ed4
      [    4.181884] r10: c04dafd0  r9 : c098690c  r8 : c0936208
      [    4.181884] r7 : ed890000  r6 : c0a63d00  r5 : 00000000  r4 : 00000000
      [    4.181884] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c0b2acc8
      [    4.181884] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      [    4.181884] Control: 10c5387d  Table: adcb804a  DAC: 00000015
      [    4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238)
      [    4.181915] Stack: (0xed891ec0 to 0xed892000)
      [    4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70
      [    4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc
      [    4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914
      [    4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208
      [    4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007
      [    4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000
      [    4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000
      [    4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000
      [    4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [    4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284)
      [    4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0)
      [    4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c)
      [    4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4)
      [    4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20)
      [    4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c)
      [    4.182128] ---[ end trace 634903a22e8609cb ]---
      [    4.182189] Kernel panic - not syncing: Attempted to kill init!  exitcode=0x0000000b
      [    4.182189]
      [    4.642395] CPU0: stopping
      
      [rjw: Changelog]
      Signed-off-by: NPaolo Pisati <paolo.pisati@canonical.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f5c3ef21
  5. 01 4月, 2013 1 次提交
  6. 02 2月, 2013 3 次提交
  7. 22 1月, 2013 1 次提交
  8. 21 11月, 2012 1 次提交
  9. 10 9月, 2012 1 次提交