1. 29 4月, 2014 1 次提交
    • S
      cpufreq: powernow-k7: Fix double invocation of cpufreq_freq_transition_begin/end · 8997b185
      Srivatsa S. Bhat 提交于
      During frequency transitions, the cpufreq core takes the responsibility of
      invoking cpufreq_freq_transition_begin() and cpufreq_freq_transition_end()
      for those cpufreq drivers that define the ->target_index callback but don't
      set the ASYNC_NOTIFICATION flag.
      
      The powernow-k7 cpufreq driver falls under this category, but this driver was
      invoking the _begin() and _end() APIs itself around frequency transitions,
      which led to double invocation of the _begin() API. The _begin API makes
      contending callers wait until the previous invocation is complete. Hence,
      the powernow-k7 driver ended up waiting on itself, leading to system hangs
      during boot.
      
      Fix this by removing the calls to the _begin() and _end() APIs from the
      powernow-k7 driver, since they rightly belong to the cpufreq core.
      
      Fixes: 12478cf0 (cpufreq: Make sure frequency transitions are serialized)
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8997b185
  2. 26 3月, 2014 1 次提交
  3. 12 3月, 2014 1 次提交
  4. 26 10月, 2013 1 次提交
    • V
      cpufreq: Implement light weight ->target_index() routine · 9c0ebcf7
      Viresh Kumar 提交于
      Currently, the prototype of cpufreq_drivers target routines is:
      
      int target(struct cpufreq_policy *policy, unsigned int target_freq,
      		unsigned int relation);
      
      And most of the drivers call cpufreq_frequency_table_target() to get a valid
      index of their frequency table which is closest to the target_freq. And they
      don't use target_freq and relation after that.
      
      So, it makes sense to just do this work in cpufreq core before calling
      cpufreq_frequency_table_target() and simply pass index instead. But this can be
      done only with drivers which expose their frequency table with cpufreq core. For
      others we need to stick with the old prototype of target() until those drivers
      are converted to expose frequency tables.
      
      This patch implements the new light weight prototype for target_index() routine.
      It looks like this:
      
      int target_index(struct cpufreq_policy *policy, unsigned int index);
      
      CPUFreq core will call cpufreq_frequency_table_target() before calling this
      routine and pass index to it. Because CPUFreq core now requires to call routines
      present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.
      
      This also marks target() interface as deprecated. So, that new drivers avoid
      using it. And Documentation is updated accordingly.
      
      It also converts existing .target() to newly defined light weight
      .target_index() routine for many driver.
      Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NRussell King <linux@arm.linux.org.uk>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rjw@rjwysocki.net>
      9c0ebcf7
  5. 16 10月, 2013 2 次提交
  6. 01 10月, 2013 1 次提交
  7. 10 8月, 2013 1 次提交
  8. 08 8月, 2013 1 次提交
  9. 15 7月, 2013 1 次提交
    • P
      cpufreq: delete __cpuinit usage from all cpufreq files · 2760984f
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      This removes all the drivers/cpufreq uses of the __cpuinit macros
      from all C files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [v2: leave 2nd lines of args misaligned as requested by Viresh]
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: cpufreq@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Acked-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2760984f
  10. 04 6月, 2013 1 次提交
  11. 02 4月, 2013 1 次提交
  12. 29 3月, 2012 1 次提交
  13. 14 2月, 2012 1 次提交
  14. 27 1月, 2012 1 次提交
    • A
      cpufreq: Add support for x86 cpuinfo auto loading v4 · fa8031ae
      Andi Kleen 提交于
      This marks all the x86 cpuinfo tables to the CPU specific device drivers,
      to allow auto loading by udev. This should simplify the distribution
      startup scripts for this greatly.
      
      I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers,
      because those probably shouldn't be auto loaded and the acpi driver
      be used instead (not fully sure on that, would appreciate feedback)
      
      The old nforce drivers autoload based on the PCI ID.
      
      ACPI cpufreq is autoloaded in another patch.
      
      v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones)
      v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading
      
      Cc: Dave Jones <davej@redhat.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fa8031ae
  15. 20 5月, 2011 1 次提交
  16. 04 5月, 2011 1 次提交
    • D
      [CPUFREQ] use dynamic debug instead of custom infrastructure · 2d06d8c4
      Dominik Brodowski 提交于
      With dynamic debug having gained the capability to report debug messages
      also during the boot process, it offers a far superior interface for
      debug messages than the custom cpufreq infrastructure. As a first step,
      remove the old cpufreq_debug_printk() function and replace it with a call
      to the generic pr_debug() function.
      
      How can dynamic debug be used on cpufreq? You need a kernel which has
      CONFIG_DYNAMIC_DEBUG enabled.
      
      To enabled debugging during runtime, mount debugfs and
      
      $ echo -n 'module cpufreq +p' > /sys/kernel/debug/dynamic_debug/control
      
      for debugging the complete "cpufreq" module. To achieve the same goal during
      boot, append
      
      	ddebug_query="module cpufreq +p"
      
      as a boot parameter to the kernel of your choice.
      
      For more detailled instructions, please see
      Documentation/dynamic-debug-howto.txt
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      2d06d8c4
  17. 04 8月, 2010 1 次提交
  18. 25 11月, 2009 1 次提交
    • T
      [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface · e2f74f35
      Thomas Renninger 提交于
      This interface is mainly intended (and implemented) for ACPI _PPC BIOS
      frequency limitations, but other cpufreq drivers can also use it for
      similar use-cases.
      
      Why is this needed:
      
      Currently it's not obvious why cpufreq got limited.
      People see cpufreq/scaling_max_freq reduced, but this could have
      happened by:
        - any userspace prog writing to scaling_max_freq
        - thermal limitations
        - hardware (_PPC in ACPI case) limitiations
      
      Therefore export bios_limit (in kHz) to:
        - Point the user that it's the BIOS (broken or intended) which limits
          frequency
        - Export it as a sysfs interface for userspace progs.
          While this was a rarely used feature on laptops, there will appear
          more and more server implemenations providing "Green IT" features like
          allowing the service processor to limit the frequency. People want
          to know about HW/BIOS frequency limitations.
      
      All ACPI P-state driven cpufreq drivers are covered with this patch:
        - powernow-k8
        - powernow-k7
        - acpi-cpufreq
      
      Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
      via _PPC, exposed by bios_limit:
      # echo 2200000 >cpu2/cpufreq/scaling_max_freq
      # cat cpu*/cpufreq/scaling_max_freq
      2600000
      2600000
      2200000
      2200000
      # #scaling_max_freq shows general user/thermal/BIOS limitations
      
      # cat cpu*/cpufreq/bios_limit
      2600000
      2600000
      2800000
      2800000
      # #bios_limit only shows the HW/BIOS limitation
      
      CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
      CC: Len Brown <lenb@kernel.org>
      CC: davej@codemonkey.org.uk
      CC: linux@dominikbrodowski.net
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e2f74f35
  19. 09 6月, 2009 1 次提交
  20. 27 5月, 2009 1 次提交
  21. 25 2月, 2009 2 次提交
  22. 04 1月, 2009 1 次提交
  23. 21 10月, 2008 1 次提交
  24. 07 2月, 2008 1 次提交
  25. 20 10月, 2007 1 次提交
    • M
      x86: convert cpuinfo_x86 array to a per_cpu array · 92cb7612
      Mike Travis 提交于
      cpu_data is currently an array defined using NR_CPUS.  This means that
      we overallocate since we will rarely really use maximum configured cpus.
      When NR_CPU count is raised to 4096 the size of cpu_data becomes
      3,145,728 bytes.
      
      These changes were adopted from the sparc64 (and ia64) code.  An
      additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
      index.  This corresponds to the index into a cpumask_t as well as the
      per_cpu index.  It's used in various places like show_cpuinfo().
      
      cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
      case.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Mark M. Hoffman <mhoffman@lightlink.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      92cb7612
  26. 18 10月, 2007 1 次提交
  27. 11 10月, 2007 1 次提交
  28. 05 10月, 2007 1 次提交
  29. 14 5月, 2007 1 次提交
    • D
      [CPUFREQ] powernow-k7: fix MHz rounding issue with perflib · dc2585eb
      Daniel Drake 提交于
      When the PST tables are broken, powernow-k7 uses ACPI's processor_perflib to
      deduce the available frequency multipliers from the _PSS tables.
      
      Upon frequency change, processor_perflib performs some verification on the
      frequency (checks that it's within allowable bounds).
      
      powernow-k7 deals with absolute frequencies in KHz, whereas perflib only
      deals with MHz values. When performing the above verification, perflib
      multiplies the MHz values by 1000 to obtain the KHz value.
      
      We then end up with situations like the following:
       - powernow-k7 multiplies the multiplier by the FSB, and obtains a value
         such as 1266768 KHz
       - perflib belives the same state has frequency of 1266 MHz
       - acpi_processor_ppc_notifier calls cpufreq_verify_within_limits to verify
         that 1266768 is in the allowable range of 0 to 1266000 (i.e. 1266 * 1000)
       - it's not, so that frequency is rejected
       - the maximum CPU frequency is not reachable
      
      This patch solves the problem by rounding up the MHz values stored in perflib's
      tables. Additionally it corrects a broken URL.
      
      It also fixes http://bugzilla.kernel.org/show_bug.cgi?id=8255 although this
      case is a bit different: the frequencies in the _PSS tables are wildly wrong,
      but we get better results if we force ACPI to respect the fsb * multiplier
      calculations (even though it seems that the multiplier values aren't entirely
      correct either).
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      dc2585eb
  30. 27 2月, 2007 1 次提交
  31. 23 2月, 2007 2 次提交
  32. 01 7月, 2006 1 次提交
  33. 06 6月, 2006 1 次提交
  34. 31 5月, 2006 1 次提交
  35. 28 2月, 2006 1 次提交
  36. 21 10月, 2005 1 次提交
  37. 26 6月, 2005 1 次提交