| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 01 Feb 2012 19:51:03 -0800
From: Randy Dunlap <rdunlap@...otime.net>
To: Maxime Coquelin <maxime.coquelin@...ricsson.com>
CC: linux-mm@...ck.org, linaro-mm-sig@...ts.linaro.org,
Mel Gorman <mel@....ul.ie>, Ankita Garg <ankita@...ibm.com>,
linux-kernel@...r.kernel.org, linus.walleij@...ricsson.com,
andrea.gallo@...ricsson.com, vincent.guittot@...ricsson.com,
philippe.langlais@...ricsson.com, loic.pallardy@...ricsson.com
Subject: Re: [RFCv1 5/6] PASR: Add Documentation
On 01/30/2012 05:33 AM, Maxime Coquelin wrote:
> Signed-off-by: Maxime Coquelin <maxime.coquelin@...ricsson.com>
> ---
> Documentation/pasr.txt | 183 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 183 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/pasr.txt
>
> diff --git a/Documentation/pasr.txt b/Documentation/pasr.txt
> new file mode 100644
> index 0000000..d40e3f6
> --- /dev/null
> +++ b/Documentation/pasr.txt
> @@ -0,0 +1,183 @@
> +Partial Array Self-Refresh Framework
> +
> +(C) 2012 Maxime Coquelin <maxime.coquelin@...ricsson.com>, ST-Ericsson.
> +
> +CONTENT
> +1. Introduction
> +2. Command-line parameters
> +3. Allocators patching
> +4. PASR platform drivers
> +
> +
> +1. Introduction
> +
> +PASR Frameworks brings support for the Partial Array Self-Refresh DDR power
The PASR framework brings support
> +management feature. PASR has been introduced in LP-DDR2, and is also present
was introduced in LP-DDR2 and is also present
> +in DDR3.
> +
> +PASR provides 4 modes:
> +
> +* Single-Ended: Only 1/1, 1/2, 1/4 or 1/8 are refreshed, masking starting at
> + the end of the DDR die.
> +
> +* Double-Ended: Same as Single-Ended, but refresh-masking does not start
> + necessairly at the end of the DDR die.
necessarily
> +
> +* Bank-Selective: Refresh of each bank of a die can be masked or unmasked via
> + a dedicated DDR register (MR16). This mode is convenient for DDR configured
> + in BRC (Bank-Row-Column) mode.
> +
> +* Segment-Selective: Refresh of each segment of a die can be masked or unmasked
> + via a dedicated DDR register (MR17). This mode is convenient for DDR configured
> + in RBC (Row-Bank-Column) mode.
> +
> +The role of this framework is to stop the refresh of unused memory to enhance
> +DDR power consumption.
> +
> +It supports Bank-Selective and Segment-Selective modes, as the more adapted to
> +modern OSes.
huh? parse error above.
> +
> +At early boot stage, a representation of the physical DDR layout is built:
> +
> + Die 0
> +_______________________________
> +| I--------------------------I |
> +| I Bank or Segment 0 I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment 1 I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment ... I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment n I |
> +| I--------------------------I |
> +|______________________________|
> + ...
> +
> + Die n
> +_______________________________
> +| I--------------------------I |
> +| I Bank or Segment 0 I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment 1 I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment ... I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment n I |
> +| I--------------------------I |
> +|______________________________|
> +
> +The first level is a table where elements represent a die:
> +* Base address,
> +* Number of segments,
> +* Table representing banks/segments,
> +* MR16/MR17 refresh mask,
> +* DDR Controller callback to update MR16/MR17 refresh mask.
> +
> +The second level is the section tables representing the banks or segments,
> +depending on hardware configuration:
> +* Base address,
> +* Unused memory size counter,
> +* Possible pointer to another section it depends on (E.g. Interleaving)
> +
> +When some memory becomes unused, the allocator owning this memory calls the PASR
> +Framework's pasr_put(phys_addr, size) function. The framework finds the
> +sections impacted and updates their counters accordingly.
> +If a section counter reach the section size, the refresh of the section is
reaches
> +masked. If the corresponding section has a dependency with another section
> +(E.g. because of DDR interleaving, see figure below), it checks the "paired" section is also
it checks if the "paired" section is also
> +unused before updating the refresh mask.
> +
> +When some unused memory is requested by the allocator, the allocator owning
> +this memory calls the PASR Framework's pasr_get(phys_addr, size) function. The
> +framework find the section impacted and updates their counters accordingly.
finds and updates its counter accordingly.
or
find the sections impacted and updates their counters accordingly.
> +If before the update, the section counter was to the section size, the refrewh
was equal to the section size, the refresh
> +of the section is unmasked. If the corresponding section has a dependency with
> +another section, it also unmask the refresh of the other section.
unmasks
> +
> +Interleaving example:
> +
> + Die 0
> +_______________________________
> +| I--------------------------I |
> +| I Bank or Segment 0 I |<----|
> +| I--------------------------I | |
> +| I--------------------------I | |
> +| I Bank or Segment 1 I | |
> +| I--------------------------I | |
> +| I--------------------------I | |
> +| I Bank or Segment ... I | |
> +| I--------------------------I | |
> +| I--------------------------I | |
> +| I Bank or Segment n I | |
> +| I--------------------------I | |
> +|______________________________| |
> + |
> + Die 1 |
> +_______________________________ |
> +| I--------------------------I | |
> +| I Bank or Segment 0 I |<----|
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment 1 I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment ... I |
> +| I--------------------------I |
> +| I--------------------------I |
> +| I Bank or Segment n I |
> +| I--------------------------I |
> +|______________________________|
> +
> +In the above example, bank 0 of die 0 is interleaved with bank0 of die 0.
bank 0 of die 1.
> +The interleaving is done in HW by inverting some addresses lines. The goal is
in hardware
> +to improve DDR bandwidth.
> +Practically, one buffer seen as contiguous by the kernel might be spread
> +into two DDR dies physically.
> +
> +
> +2. Command-line parameters
> +
> +To buid the DDR physical layout representation, two parameters are requested:
build
> +
> +* ddr_die (mandatory): Should be added for every DDR dies present in the system.
die
> + - Usage: ddr_die=xxx[M|G]@yyy[M|G] where xxx represents the size and yyy
> + the base address of the die. E.g.: ddr_die=512M@0 ddr_die=512M@...M
> +
> +* interleaved (optionnal): Should be added for every interleaved dependencies.
(optional): for all interleaved dependencies.
> + - Usage: interleaved=xxx[M|G]@yyy[M|G]:zzz[M|G] where xxx is the size of
> + the interleaved area between the adresses yyy and zzz. E.g
> + interleaved=256M@0:512M
> +
> +
> +3. Allocator patching
> +
> +Any allocators might call the PASR Framework for DDR power savings. Currently,
> +only Linux Buddy allocator is patched, but HWMEM and PMEM physically
only the Linux Buddy
> +contiguous memory allocators will follow.
> +
> +Linux Buddy allocator porting uses Buddy specificities to reduce the overhead
> +induced by the PASR Framework counter updates. Indeed, the PASR Framework is
> +called only when MAX_ORDER (4MB page blocs by default) buddies are
blocks
> +inserted/removed from the free lists.
> +
> +To port PASR FW into a new allocator:
the PASR framework
> +
> +* Call pasr_put(phys_addr, size) each time a memory chunk becomes unused.
> +* Call pasr_get(phys_addr, size) each time a memory chunk becomes used.
> +
> +4. PASR platform drivers
> +
> +The MR16/MR17 PASR mask registers are generally accessible through the DDR
> +controller. At probe time, the DDR controller driver should register the
> +callback used by PASR Framework to apply the refresh mask for every DDR die
> +using pasr_register_mask_function(die_addr, callback, cookie).
> +
> +The callback passed to apply mask must not sleep since it can me called in
can be
> +interrupt contexts.
> +
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists