Documentation/pasr.txt

   1 Partial Array Self-Refresh Framework
   2
   3 (C) 2012 Maxime Coquelin <maxime.coquelin@stericsson.com>, ST-Ericsson.
   4
   5 CONTENT
   6 1. Introduction
   7 2. Command-line parameters
   8 3. Allocators patching
   9 4. PASR platform drivers
  10
  11
  12 1. Introduction
  13
  14 PASR Frameworks brings support for the Partial Array Self-Refresh DDR power
  15 management feature. PASR has been introduced in LP-DDR2, and is also present
  16 in DDR3.
  17
  18 PASR provides 4 modes:
  19
  20 * Single-Ended: Only 1/1, 1/2, 1/4 or 1/8 are refreshed, masking starting at
  21   the end of the DDR die.
  22
  23 * Double-Ended: Same as Single-Ended, but refresh-masking does not start
  24   necessairly at the end of the DDR die.
  25
  26 * Bank-Selective: Refresh of each bank of a die can be masked or unmasked via
  27   a dedicated DDR register (MR16). This mode is convenient for DDR configured
  28   in BRC (Bank-Row-Column) mode.
  29
  30 * Segment-Selective: Refresh of each segment of a die can be masked or unmasked
  31   via a dedicated DDR register (MR17). This mode is convenient for DDR configured
  32   in RBC (Row-Bank-Column) mode.
  33
  34 The role of this framework is to stop the refresh of unused memory to enhance
  35 DDR power consumption.
  36
  37 It supports Bank-Selective and Segment-Selective modes, as the more adapted to
  38 modern OSes.
  39
  40 At early boot stage, a representation of the physical DDR layout is built:
  41
  42              Die 0
  43 _______________________________
  44 | I--------------------------I |
  45 | I    Bank or Segment 0     I |
  46 | I--------------------------I |
  47 | I--------------------------I |
  48 | I    Bank or Segment 1     I |
  49 | I--------------------------I |
  50 | I--------------------------I |
  51 | I    Bank or Segment ...   I |
  52 | I--------------------------I |
  53 | I--------------------------I |
  54 | I    Bank or Segment n     I |
  55 | I--------------------------I |
  56 |______________________________|
  57              ...
  58
  59              Die n
  60 _______________________________
  61 | I--------------------------I |
  62 | I    Bank or Segment 0     I |
  63 | I--------------------------I |
  64 | I--------------------------I |
  65 | I    Bank or Segment 1     I |
  66 | I--------------------------I |
  67 | I--------------------------I |
  68 | I    Bank or Segment ...   I |
  69 | I--------------------------I |
  70 | I--------------------------I |
  71 | I    Bank or Segment n     I |
  72 | I--------------------------I |
  73 |______________________________|
  74
  75 The first level is a table where elements represent a die:
  76 * Base address,
  77 * Number of segments,
  78 * Table representing banks/segments,
  79 * MR16/MR17 refresh mask,
  80 * DDR Controller callback to update MR16/MR17 refresh mask.
  81
  82 The second level is the section tables representing the banks or segments,
  83 depending on hardware configuration:
  84 * Base address,
  85 * Unused memory size counter,
  86 * Possible pointer to another section it depends on (E.g. Interleaving)
  87
  88 When some memory becomes unused, the allocator owning this memory calls the PASR
  89 Framework's pasr_put(phys_addr, size) function. The framework finds the
  90 sections impacted and updates their counters accordingly.
  91 If a section counter reach the section size, the refresh of the section is
  92 masked. If the corresponding section has a dependency with another section
  93 (E.g. because of DDR interleaving, see figure below), it checks the "paired" section is also
  94 unused before updating the refresh mask.
  95
  96 When some unused memory is requested by the allocator, the allocator owning
  97 this memory calls the PASR Framework's pasr_get(phys_addr, size) function. The
  98 framework find the section impacted and updates their counters accordingly.
  99 If before the update, the section counter was to the section size, the refrewh
 100 of the section is unmasked. If the corresponding section has a dependency with
 101 another section, it also unmask the refresh of the other section.
 102
 103 Interleaving example:
 104
 105              Die 0
 106 _______________________________
 107 | I--------------------------I |
 108 | I    Bank or Segment 0     I |<----|
 109 | I--------------------------I |     |
 110 | I--------------------------I |     |
 111 | I    Bank or Segment 1     I |     |
 112 | I--------------------------I |     |
 113 | I--------------------------I |     |
 114 | I    Bank or Segment ...   I |     |
 115 | I--------------------------I |     |
 116 | I--------------------------I |     |
 117 | I    Bank or Segment n     I |     |
 118 | I--------------------------I |     |
 119 |______________________________|     |
 120                                      |
 121              Die 1                   |
 122 _______________________________      |
 123 | I--------------------------I |     |
 124 | I    Bank or Segment 0     I |<----|
 125 | I--------------------------I |
 126 | I--------------------------I |
 127 | I    Bank or Segment 1     I |
 128 | I--------------------------I |
 129 | I--------------------------I |
 130 | I    Bank or Segment ...   I |
 131 | I--------------------------I |
 132 | I--------------------------I |
 133 | I    Bank or Segment n     I |
 134 | I--------------------------I |
 135 |______________________________|
 136
 137 In the above example, bank 0 of die 0 is interleaved with bank0 of die 0.
 138 The interleaving is done in HW by inverting some addresses lines. The goal is
 139 to improve DDR bandwidth.
 140 Practically, one buffer seen as contiguous by the kernel might be spread
 141 into two DDR dies physically.
 142
 143
 144 2. Command-line parameters
 145
 146 To buid the DDR physical layout representation, two parameters are requested:
 147
 148 * ddr_die (mandatory): Should be added for every DDR dies present in the system.
 149    - Usage: ddr_die=xxx[M|G]@yyy[M|G] where xxx represents the size and yyy
 150      the base address of the die. E.g.: ddr_die=512M@0 ddr_die=512M@512M
 151
 152 * interleaved (optionnal): Should be added for every interleaved dependencies.
 153    - Usage: interleaved=xxx[M|G]@yyy[M|G]:zzz[M|G] where xxx is the size of
 154      the interleaved area between the adresses yyy and zzz. E.g
 155      interleaved=256M@0:512M
 156
 157
 158 3. Allocator patching
 159
 160 Any allocators might call the PASR Framework for DDR power savings. Currently,
 161 only Linux Buddy allocator is patched, but HWMEM and PMEM physically
 162 contiguous memory allocators will follow.
 163
 164 Linux Buddy allocator porting uses Buddy specificities to reduce the overhead
 165 induced by the PASR Framework counter updates. Indeed, the PASR Framework is
 166 called only when MAX_ORDER (4MB page blocs by default) buddies are
 167 inserted/removed from the free lists.
 168
 169 To port PASR FW into a new allocator:
 170
 171 * Call pasr_put(phys_addr, size) each time a memory chunk becomes unused.
 172 * Call pasr_get(phys_addr, size) each time a memory chunk becomes used.
 173
 174 4. PASR platform drivers
 175
 176 The MR16/MR17 PASR mask registers are generally accessible through the DDR
 177 controller. At probe time, the DDR controller driver should register the
 178 callback used by PASR Framework to apply the refresh mask for every DDR die
 179 using pasr_register_mask_function(die_addr, callback, cookie).
 180
 181 The callback passed to apply mask must not sleep since it can me called in
 182 interrupt contexts.
 183