video: tegra: edid: Verify checksum of edid
[linux-3.10.git] / 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