1. 28 5月, 2014 1 次提交
  2. 19 4月, 2014 1 次提交
  3. 18 4月, 2014 1 次提交
    • T
      genirq: Allow forcing cpu affinity of interrupts · 01f8fa4f
      Thomas Gleixner 提交于
      The current implementation of irq_set_affinity() refuses rightfully to
      route an interrupt to an offline cpu.
      
      But there is a special case, where this is actually desired. Some of
      the ARM SoCs have per cpu timers which require setting the affinity
      during cpu startup where the cpu is not yet in the online mask.
      
      If we can't do that, then the local timer interrupt for the about to
      become online cpu is routed to some random online cpu.
      
      The developers of the affected machines tried to work around that
      issue, but that results in a massive mess in that timer code.
      
      We have a yet unused argument in the set_affinity callbacks of the irq
      chips, which I added back then for a similar reason. It was never
      required so it got not used. But I'm happy that I never removed it.
      
      That allows us to implement a sane handling of the above scenario. So
      the affected SoC drivers can add the required force handling to their
      interrupt chip, switch the timer code to irq_force_affinity() and
      things just work.
      
      This does not affect any existing user of irq_set_affinity().
      
      Tagged for stable to allow a simple fix of the affected SoC clock
      event drivers.
      Reported-and-tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Tomasz Figa <t.figa@samsung.com>,
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: linux-arm-kernel@lists.infradead.org,
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20140416143315.717251504@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      01f8fa4f
  4. 08 4月, 2014 1 次提交
  5. 07 4月, 2014 1 次提交
    • V
      cpufreq: create another field .flags in cpufreq_frequency_table · 7f4b0461
      Viresh Kumar 提交于
      Currently cpufreq frequency table has two fields: frequency and driver_data.
      driver_data is only for drivers' internal use and cpufreq core shouldn't use
      it at all. But with the introduction of BOOST frequencies, this assumption
      was broken and we started using it as a flag instead.
      
      There are two problems due to this:
      - It is against the description of this field, as driver's data is used by
        the core now.
      - if drivers fill it with -3 for any frequency, then those frequencies are
        never considered by cpufreq core as it is exactly same as value of
        CPUFREQ_BOOST_FREQ, i.e. ~2.
      
      The best way to get this fixed is by creating another field flags which
      will be used for such flags. This patch does that. Along with that various
      drivers need modifications due to the change of struct cpufreq_frequency_table.
      Reviewed-by: NGautham R Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f4b0461
  6. 01 4月, 2014 35 次提交