1. 24 4月, 2015 1 次提交
    • T
      x86/intel-mid: Delay initialization of APB timer · 6648d1b4
      Thomas Gleixner 提交于
      MID has no PIC, but depending on the platform it requires the
      abt_timer, which is connected to irq0. The timer is set up at
      late_time_init().
      
      But, looking at the MID code it seems, that there is no reason to do
      so. The only code which might need the timer working is the TSC
      calibration code, but thats a non issue on MID as that is using its
      own empty calibration function. And check_timer() is not invoked
      either because MID has no PIC and therefor no legacy irqs.
      
      So if you look at intel_mid_time_init() then you'll see that in the
      ARAT case the timer setup is skipped already. So until the point where
      x86_init.timers.setup_percpu_clockev() is called for the boot cpu
      nothing really needs a timer on MID.
      
      According to the MID code the apbt horror is only used for moorestown.
      Medfield and later use the local apic timer without the apbt nonsense.
      
      The best thing we can do is to drop moorestown support and get rid of
      that apbt nonsense alltogether.
      
      I don't think anyone deeply cares about it not being supported from
      3.18 on. The number of devices which sport a moorestown should be
      pretty limited and the only relevant use case of those is to act as a
      pocket heater with short battery life time. Its pretty pointless to
      update kernels on pocket heaters except for bragging reasons.
      
      If someone at Intel really thinks that we need to keep moorestown
      alive for other than documentary and sentimental reasons, then we can
      move the apbt setup to x86_init.timers.setup_percpu_clockev(). At that
      point the IOAPIC is setup already, so it should just work.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Cohen <david.a.cohen@linux.intel.com>
      Cc: Sander Eikelenboom <linux@eikelenboom.it>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Link: http://lkml.kernel.org/r/1428905519-23704-30-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      6648d1b4
  2. 24 2月, 2015 1 次提交
  3. 16 1月, 2014 3 次提交
  4. 08 11月, 2013 1 次提交
  5. 18 10月, 2013 9 次提交
  6. 30 8月, 2013 1 次提交
  7. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      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.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  8. 12 3月, 2013 1 次提交
  9. 04 1月, 2013 1 次提交
    • G
      X86: drivers: remove __dev* attributes. · a18e3690
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitconst,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Daniel Drake <dsd@laptop.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  10. 06 6月, 2012 1 次提交
  11. 25 4月, 2012 1 次提交
  12. 21 3月, 2012 1 次提交
  13. 10 3月, 2012 1 次提交
  14. 27 1月, 2012 2 次提交
  15. 18 12月, 2011 1 次提交
  16. 05 12月, 2011 4 次提交
  17. 12 11月, 2011 1 次提交
  18. 10 11月, 2011 2 次提交
  19. 24 10月, 2011 2 次提交
  20. 14 10月, 2011 1 次提交
  21. 27 8月, 2011 2 次提交
  22. 07 5月, 2011 1 次提交
  23. 12 4月, 2011 1 次提交
    • J
      x86/mrst: Fix boot crash caused by incorrect pin to irq mapping · 9d90e49d
      Jacob Pan 提交于
      Moorestown systems crash on boot because the secondary CPU
      clockevent (apbt1) will fail to request irq#1, which does not
      have ioapic chip in its irq_desc[] entry.
      
      Background:
      
      Moorestown platform does not have ISA bus nor legacy IRQs. It
      reuses the range of legacy IRQs for regular device interrupts.
      The routing information of early system device IRQs (timers) are
      obtained from firmware provided SFI tables. We reuse/fake MP
      configuration table to facilitate IRQ setup with IOAPIC.
      
      Maintaining a 1:1 mapping of IOAPIC pin (RTE entry) and IRQ#
      makes routing information clean and easy to understand on
      Moorestown. Though optional.
      
      This patch allows SFI timer and vRTC IRQ to be treated as ISA
      IRQ so that pin2irq mapping will be 1:1.
      
      Also fixed MP table type and use macros to clearly set MP IRQ
      entries. As a result, apbt timer and RTC interrupts on
      Moorestown are within legacy IRQ range:
      
       # cat /proc/interrupts
                  CPU0       CPU1
         0:      11249          0   IO-APIC-edge      apbt0
         1:          0      12271   IO-APIC-edge      apbt1
         8:        887          0   IO-APIC-fasteoi   dw_spi
        13:          0          0   IO-APIC-fasteoi   INTEL_MID_DMAC2
        14:          0          0   IO-APIC-fasteoi   rtc0
      
      Further discussion of this patch can be found at:
      
        https://lkml.org/lkml/2010/6/10/70Suggested-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Feng Tang <feng.tang@intel.com>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Link: http://lkml.kernel.org/r/1302286980-21139-1-git-send-email-jacob.jun.pan@linux.intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>
      9d90e49d