)]}'
{
  "commit": "a4b4be3fd7a76021f67380b03d8bccebf067db72",
  "tree": "545aa3c8a1f8a5ae5747df1c8886d1e5e9518bab",
  "parents": [
    "0142877aa4e54dd9943fb727e9b386c36c8e3ab7"
  ],
  "author": {
    "name": "Mauro Carvalho Chehab",
    "email": "mchehab@redhat.com",
    "time": "Fri Jan 27 10:26:13 2012 -0300"
  },
  "committer": {
    "name": "Mauro Carvalho Chehab",
    "email": "mchehab@redhat.com",
    "time": "Wed Mar 21 15:22:50 2012 -0300"
  },
  "message": "edac: rename channel_info to rank_info\n\nWhat it is pointed by a csrow/channel vector is a rank information, and\nnot a channel information.\n\nOn a traditional architecture, the memory controller directly access the\nmemory ranks, via chip select rows. Different ranks at the same DIMM is\nselected via different chip select rows. So, typically, one\ncsrow/channel pair means one different DIMM.\n\nOn FB-DIMMs, there\u0027s a microcontroller chip at the DIMM, called Advanced\nMemory Buffer (AMB) that serves as the interface between the memory\ncontroller and the memory chips.\n\nThe AMB selection is via the DIMM slot, and not via a csrow.\n\nIt is up to the AMB to talk with the csrows of the DRAM chips.\n\nSo, the FB-DIMM memory controllers see the DIMM slot, and not the DIMM\nrank. RAMBUS is similar.\n\nNewer memory controllers, like the ones found on Intel Sandy Bridge and\nNehalem, even working with normal DDR3 DIMM\u0027s, don\u0027t use the usual\nchannel A/channel B interleaving schema to provide 128 bits data access.\n\nInstead, they have more channels (3 or 4 channels), and they can use\nseveral interleaving schemas. Such memory controllers see the DIMMs\ndirectly on their registers, instead of the ranks, which is better for\nthe driver, as its main usageis to point to a broken DIMM stick (the\nField Repleceable Unit), and not to point to a broken DRAM chip.\n\nThe drivers that support such such newer memory architecture models\ncurrently need to fake information and to abuse on EDAC structures, as\nthe subsystem was conceived with the idea that the csrow would always be\nvisible by the CPU.\n\nTo make things a little worse, those drivers don\u0027t currently fake\ncsrows/channels on a consistent way, as the concepts there don\u0027t apply\nto the memory controllers they\u0027re talking with. So, each driver author\ninterpreted the concepts using a different logic.\n\nIn order to fix it, let\u0027s rename the data structure that points into a\nDIMM rank to \"rank_info\", in order to be clearer about what\u0027s stored\nthere.\n\nLatter patches will provide a better way to represent the memory\nhierarchy for the other types of memory controller.\n\nSigned-off-by: Mauro Carvalho Chehab \u003cmchehab@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ca6c04d350ee4a613be2df96e0c0100f0518fbfb",
      "old_mode": 33188,
      "old_path": "drivers/edac/edac_mc.c",
      "new_id": "690cbf15a007ccbe27fad5d9f7b55c033dcd7148",
      "new_mode": 33188,
      "new_path": "drivers/edac/edac_mc.c"
    },
    {
      "type": "modify",
      "old_id": "0714d67a6e1a27471443c8bb9d9faa23c68c280e",
      "old_mode": 33188,
      "old_path": "include/linux/edac.h",
      "new_id": "e3e3d26c638e218df9f4aab76a5e9c9a2beda315",
      "new_mode": 33188,
      "new_path": "include/linux/edac.h"
    }
  ]
}