From: Maxime Coquelin <maxime.coquelin@stericsson.com>
To: Randy Dunlap <rdunlap@xenotime.net>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
Mel Gorman <mel@csn.ul.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
Andrea GALLO <andrea.gallo@stericsson.com>,
Vincent GUITTOT <vincent.guittot@stericsson.com>,
Philippe LANGLAIS <philippe.langlais@stericsson.com>,
Loic PALLARDY <loic.pallardy@stericsson.com>
Subject: Re: [RFCv1 5/6] PASR: Add Documentation
Date: Thu, 2 Feb 2012 18:12:18 +0100 [thread overview]
Message-ID: <4F2AC3F2.3010400@stericsson.com> (raw)
In-Reply-To: <4F2A0827.4080305@xenotime.net>
On 02/02/2012 04:51 AM, Randy Dunlap wrote:
> On 01/30/2012 05:33 AM, Maxime Coquelin wrote:
>> Signed-off-by: Maxime Coquelin<maxime.coquelin@stericsson.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@stericsson.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@512M
>> +
>> +* 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.
>> +
>
Thanks Randy for the review.
Regards,
Maxime
next prev parent reply other threads:[~2012-02-02 17:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 13:33 [RFCv1 0/6] PASR: Partial Array Self-Refresh Framework Maxime Coquelin
2012-01-30 13:33 ` [RFCv1 1/6] PASR: Initialize DDR layout Maxime Coquelin
2012-01-30 13:33 ` [RFCv1 2/6] PASR: Add core Framework Maxime Coquelin
2012-01-30 13:33 ` [RFCv1 3/6] PASR: mm: Integrate PASR in Buddy allocator Maxime Coquelin
2012-01-30 15:22 ` Mel Gorman
2012-01-30 16:52 ` Maxime Coquelin
2012-01-31 12:15 ` Maxime Coquelin
2012-01-31 14:01 ` Mel Gorman
2012-01-31 18:55 ` Maxime Coquelin
2012-02-03 11:44 ` Mel Gorman
2012-01-31 12:46 ` Pekka Enberg
2012-01-30 13:33 ` [RFCv1 4/6] PASR: Call PASR initialization Maxime Coquelin
2012-01-30 13:33 ` [RFCv1 5/6] PASR: Add Documentation Maxime Coquelin
2012-02-02 3:51 ` Randy Dunlap
2012-02-02 17:12 ` Maxime Coquelin [this message]
2012-01-30 13:33 ` [RFCv1 6/6] PASR: Ux500: Add PASR support Maxime Coquelin
2012-01-30 13:53 ` [RFCv1 0/6] PASR: Partial Array Self-Refresh Framework Ingo Molnar
2012-01-30 14:19 ` Maxime Coquelin
2012-01-31 12:39 ` Ingo Molnar
2012-01-31 14:48 ` Maxime Coquelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F2AC3F2.3010400@stericsson.com \
--to=maxime.coquelin@stericsson.com \
--cc=andrea.gallo@stericsson.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=loic.pallardy@stericsson.com \
--cc=mel@csn.ul.ie \
--cc=philippe.langlais@stericsson.com \
--cc=rdunlap@xenotime.net \
--cc=vincent.guittot@stericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).