1. 29 5月, 2012 3 次提交
    • M
      edac: Don't initialize csrow's first_page & friends when not needed · 5e2af0c0
      Mauro Carvalho Chehab 提交于
      Almost all edac	drivers	initialize csrow_info->first_page,
      csrow_info->last_page and csrow_info->page_mask. Those vars are
      used inside the EDAC core, in order to calculate the csrow affected
      by an error, by using the routine edac_mc_find_csrow_by_page().
      
      However, very few drivers actually use it:
              e752x_edac.c
              e7xxx_edac.c
              i3000_edac.c
              i82443bxgx_edac.c
              i82860_edac.c
              i82875p_edac.c
              i82975x_edac.c
              r82600_edac.c
      
      There also a few other drivers that have their own calculus
      formula internally using those vars.
      
      All the others are just wasting time by initializing those
      data.
      
      While initializing data without using them won't cause any troubles, as
      those information is stored at the wrong place (at csrows structure), it
      is better to remove what is unused, in order to simplify the next patch.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5e2af0c0
    • M
      edac: move dimm properties to struct dimm_info · 084a4fcc
      Mauro Carvalho Chehab 提交于
      On systems based on chip select rows, all channels need to use memories
      with the same properties, otherwise the memories on channels A and B
      won't be recognized.
      
      However, such assumption is not true for all types of memory
      controllers.
      
      Controllers for FB-DIMM's don't have such requirements.
      
      Also, modern Intel controllers seem to be capable of handling such
      differences.
      
      So, we need to get rid of storing the DIMM information into a per-csrow
      data, storing it, instead at the right place.
      
      The first step is to move grain, mtype, dtype and edac_mode to the
      per-dimm struct.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: NBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: James Bottomley <James.Bottomley@parallels.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Mike Williams <mike@mikebwilliams.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      084a4fcc
    • M
      edac: Create a dimm struct and move the labels into it · a7d7d2e1
      Mauro Carvalho Chehab 提交于
      The way a DIMM is currently represented implies that they're
      linked into a per-csrow struct. However, some drivers don't see
      csrows, as they're ridden behind some chip like the AMB's
      on FBDIMM's, for example.
      
      This forced drivers to fake^Wvirtualize a csrow struct, and to create
      a mess under csrow/channel original's concept.
      
      Move the DIMM labels into a per-DIMM struct, and add there
      the real location of the socket, in terms of csrow/channel.
      Latter patches will modify the location to properly represent the
      memory architecture.
      
      All other drivers will use a per-csrow type of location.
      Some of those drivers will require a latter conversion, as
      they also fake the csrows internally.
      
      TODO: While this patch doesn't change the existing behavior, on
      csrows-based memory controllers, a csrow/channel pair points to a memory
      rank. There's a known bug at the EDAC core that allows having different
      labels for the same DIMM, if it has more than one rank. A latter patch
      is need to merge the several ranks for a DIMM into the same dimm_info
      struct, in order to avoid having different labels for the same DIMM.
      
      The edac_mc_alloc() will now contain a per-dimm initialization loop that
      will be changed by latter patches in order to match other types of
      memory architectures.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a7d7d2e1
  2. 04 4月, 2012 1 次提交
  3. 03 4月, 2012 1 次提交
  4. 22 3月, 2012 9 次提交
    • M
      edac: rename channel_info to rank_info · a4b4be3f
      Mauro Carvalho Chehab 提交于
      What it is pointed by a csrow/channel vector is a rank information, and
      not a channel information.
      
      On a traditional architecture, the memory controller directly access the
      memory ranks, via chip select rows. Different ranks at the same DIMM is
      selected via different chip select rows. So, typically, one
      csrow/channel pair means one different DIMM.
      
      On FB-DIMMs, there's a microcontroller chip at the DIMM, called Advanced
      Memory Buffer (AMB) that serves as the interface between the memory
      controller and the memory chips.
      
      The AMB selection is via the DIMM slot, and not via a csrow.
      
      It is up to the AMB to talk with the csrows of the DRAM chips.
      
      So, the FB-DIMM memory controllers see the DIMM slot, and not the DIMM
      rank. RAMBUS is similar.
      
      Newer memory controllers, like the ones found on Intel Sandy Bridge and
      Nehalem, even working with normal DDR3 DIMM's, don't use the usual
      channel A/channel B interleaving schema to provide 128 bits data access.
      
      Instead, they have more channels (3 or 4 channels), and they can use
      several interleaving schemas. Such memory controllers see the DIMMs
      directly on their registers, instead of the ranks, which is better for
      the driver, as its main usageis to point to a broken DIMM stick (the
      Field Repleceable Unit), and not to point to a broken DRAM chip.
      
      The drivers that support such such newer memory architecture models
      currently need to fake information and to abuse on EDAC structures, as
      the subsystem was conceived with the idea that the csrow would always be
      visible by the CPU.
      
      To make things a little worse, those drivers don't currently fake
      csrows/channels on a consistent way, as the concepts there don't apply
      to the memory controllers they're talking with. So, each driver author
      interpreted the concepts using a different logic.
      
      In order to fix it, let's rename the data structure that points into a
      DIMM rank to "rank_info", in order to be clearer about what's stored
      there.
      
      Latter patches will provide a better way to represent the memory
      hierarchy for the other types of memory controller.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a4b4be3f
    • M
      i5400_edac: Avoid calling pci_put_device() twice · 0142877a
      Mauro Carvalho Chehab 提交于
      When i5400_edac driver is removed and re-loaded a few times, it causes
      an OOPS, as it is currently decrementing some PCI device usage two
      times.
      
      When called inside a loop, pci_get_device() will call
      pci_put_device(). That mangles the error count. In this specific
      case, it seems easier to just duplicate the call.
      
      Also fixes the error logic when pci_get_device fails.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0142877a
    • N
      edac: i5100 ack error detection register after each read · df95e42e
      Niklas Söderlund 提交于
      If I only ack the detection register after a error have been detected
      I'm unable to reliably detect errors. I have verified this behavior
      using both an error injection DIMM and software to inject errors.
      
      I can't find any documentation supporting this behavior in Intel 5100
      Memory Controller Hub Chipset, see 1. So this is all based on
      experimentation.
      
      [1] Intel® 5100 Memory Controller Hub Chipset
          http://www.intel.com/content/dam/doc/datasheet/5100-
      	memory-controller-hub-chipset-datasheet.pdf
      Signed-off-by: NNiklas Söderlund <niklas.soderlund@ericsson.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      df95e42e
    • N
      edac: i5100 fix erroneous define for M1Err · b6378cb3
      Niklas Söderlund 提交于
      According to [1] the define for M1Err in the FERR_NF_MEM register is
      wrong. It should be at position 1 not 0.
      
      [1] Intel 5100 Memory Controller Hub Chipset Doc.Nr: 318378
          http://www.intel.com/content/dam/doc/datasheet/5100-
          memory-controller-hub-chipset-datasheet.pdf
      Reported-by: NBa Thang Nguyen <thang.b.nguyen@dektech.com.au>
      Signed-off-by: NNiklas Söderlund <niklas.soderlund@ericsson.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b6378cb3
    • H
      edac: sb_edac: Fix a wrong value setting for the previous value · 7fae0db4
      Hui Wang 提交于
      >From the driver design, the variable limit wants to compare with its
      previous value, we should set the value of limit instead of the value
      of tmp_mb to the variable prev.
      Signed-off-by: NHui Wang <jason77.wang@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7fae0db4
    • H
      edac: sb_edac: Fix a INTERLEAVE_MODE() misuse · ad9c40b7
      Hui Wang 提交于
      We can identify dram interleave mode from the Dram Rule register
      rather than Dram Interleave list register.
      
      In this context, the reg of INTERLEAVE_MODE(reg) contains the Dram
      Interleave list register, we can't get interleave mode from the reg,
      while the variable interleave_mode saves the the mode got from the
      Dram Rule register, so we use the variable to replace
      INTERLEAVE_MDDE(reg) here.
      Signed-off-by: NHui Wang <jason77.wang@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ad9c40b7
    • H
      edac: sb_edac: Let the driver depend on PCI_MMCONFIG · 22a5c27b
      Hui Wang 提交于
      This driver needs to access PCIe Extended Configuration Space
      Registers (0x100~0xfff), to correctly access those registers, we need
      to enable PCI_MMCONFIG option. Since this option is not enabled for
      X86_64 by default, we let the driver depend on it to prevent users
      forgetting to enable this option.
      Signed-off-by: NHui Wang <jason77.wang@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      22a5c27b
    • M
      edac/ppc4xx_edac: Fix compilation · b877763e
      Mauro Carvalho Chehab 提交于
      It seems that nobody is cross-compiling for this arch anymore...
      
      drivers/edac/ppc4xx_edac.c: In function 'ppc4xx_edac_probe':
      drivers/edac/ppc4xx_edac.c:188:12: error: storage class specified for parameter 'ppc4xx_edac_remove'
      ...
      drivers/edac/ppc4xx_edac.c:1068:19: error: 'match' undeclared (first use in this function)
      drivers/edac/ppc4xx_edac.c:1068:19: note: each undeclared identifier is reported only once for each function it appears in
      drivers/edac/ppc4xx_edac.c:1068:36: warning: left-hand operand of comma expression has no effect [-Wunused-value]
      Acked-by: NJosh Boyer <jwboyer@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b877763e
    • M
      Fix sb_edac compilation with 32 bits kernels · 5b889e37
      Mauro Carvalho Chehab 提交于
      As reported by Josh Boyer <jwboyer@redhat.com>:
      >	drivers/edac/sb_edac.c: In function 'get_memory_error_data':
      > 	drivers/edac/sb_edac.c:861:2: warning: left shift count >= width of type
      > 	[enabled by default]
      > 	<snip>
      > 	ERROR: "__udivdi3" [drivers/edac/sb_edac.ko] undefined!
      > 	make[1]: *** [__modpost] Error 1
      > 	make: *** [modules] Error 2
      
      PS.: compile-tested only
      Reported-by: NJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5b889e37
  5. 20 3月, 2012 1 次提交
  6. 19 3月, 2012 10 次提交
  7. 12 3月, 2012 1 次提交
    • P
      device.h: cleanup users outside of linux/include (C files) · 51990e82
      Paul Gortmaker 提交于
      For files that are actively using linux/device.h, make sure
      that they call it out.  This will allow us to clean up some
      of the implicit uses of linux/device.h within include/*
      without introducing build regressions.
      
      Yes, this was created by "cheating" -- i.e. the headers were
      cleaned up, and then the fallout was found and fixed, and then
      the two commits were reordered.  This ensures we don't introduce
      build regressions into the git history.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      51990e82
  8. 22 2月, 2012 1 次提交
    • H
      asm-generic: architecture independent readq/writeq for 32bit environment · 797a796a
      Hitoshi Mitake 提交于
      This provides unified readq()/writeq() helper functions for 32-bit
      drivers.
      
      For some cases, readq/writeq without atomicity is harmful, and order of
      io access has to be specified explicitly.  So in this patch, new two
      header files which contain non-atomic readq/writeq are added.
      
       - <asm-generic/io-64-nonatomic-lo-hi.h> provides non-atomic readq/
         writeq with the order of lower address -> higher address
      
       - <asm-generic/io-64-nonatomic-hi-lo.h> provides non-atomic readq/
         writeq with reversed order
      
      This allows us to remove some readq()s that were added drivers when the
      default non-atomic ones were removed in commit dbee8a0a ("x86:
      remove 32-bit versions of readq()/writeq()")
      
      The drivers which need readq/writeq but can do with the non-atomic ones
      must add the line:
      
        #include <asm-generic/io-64-nonatomic-lo-hi.h> /* or hi-lo.h */
      
      But this will be nop in 64-bit environments, and no other #ifdefs are
      required.  So I believe that this patch can solve the problem of
       1. driver-specific readq/writeq
       2. atomicity and order of io access
      
      This patch is tested with building allyesconfig and allmodconfig as
      ARCH=x86 and ARCH=i386 on top of tip/master.
      
      Cc: Kashyap Desai <Kashyap.Desai@lsi.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Ravi Anand <ravi.anand@qlogic.com>
      Cc: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: James Bottomley <James.Bottomley@parallels.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: James Bottomley <jbottomley@parallels.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NHitoshi Mitake <h.mitake@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      797a796a
  9. 13 1月, 2012 1 次提交
  10. 21 12月, 2011 1 次提交
  11. 15 12月, 2011 1 次提交
  12. 14 12月, 2011 1 次提交
  13. 02 12月, 2011 1 次提交
  14. 24 11月, 2011 1 次提交
  15. 04 11月, 2011 1 次提交
  16. 01 11月, 2011 6 次提交