devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Ike Pan <ike.pan-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Nadav Haklai <nadavh-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	David Marlin <dmarlin-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Yehuda Yitschak <yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Dan Frazier
	<dann.frazier-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Eran Ben-Avi <benavi-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Leif Lindholm <leif.lindholm-5wv7dgnIgG8@public.gmane.org>,
	Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Chris Van Hoof <vanhoof-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Maen Suleiman <maen-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Shadi Ammouri <shadi-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Date: Fri, 22 Mar 2013 11:43:00 -0600	[thread overview]
Message-ID: <20130322174300.GA10230@obsidianresearch.com> (raw)
In-Reply-To: <20130322062854.GS21478-g2DYL2Zd6BY@public.gmane.org>

On Fri, Mar 22, 2013 at 07:28:54AM +0100, Andrew Lunn wrote:

> IO space needs to stay where it is, somewhere in the top 1GB, because
> it is limited to the 32bit address space.

Yes
 
> We must have some SDRAM in the bottom of the 40bit address range in
> order that DMA works. Bounce buffers are used for anything which is
> outside of the bottom 32bits.

Yes :(
 
> SDRAM can only be split on ranks. I assume this is also a synonym for
> chip select? 

Yes, rank is the JEDEC term. All CS inputs on every DRAM die in a rank
should be asserted at once. Note that splitting the SDRAM address map
by rank is only one choice, other chipsets can do bank interleaving
across ranks for greater performance..

> Ideally we want the boot loader to setup the split, since it is not
> very easy to move stuff around in a running system. Alternatively,
> the

Yes, there are several possibilities, but they will all require the DT
to describe the ranks on the DRAM bus directly.

> It might be possible, in theory, to copy code into the SRAM and run
> from SRAM while moving the SDRAM around. But i get the feeling its not
> very easy.

This doesn't help, the issue is the kernel has already started and is
already placed in SDRAM, so you can't really touch the mapping that
contains the kernel. The work is more of a complexity to determine
what the bootloader did and re-do it in a way that dosen't move any
memory the kernel has touched up to that point.

> If there is 4GB in the system, it is probably going to be split with
> 2GB low and 2GB high. This is probably the most important use case,
> since throwing away 1/4 of your SDRAM is much worse than 1/8, or 1/16.

Think about things in terms of rank size. A 4GB system could have 1, 2
or 4 GB ranks, and each is a different case. 1GB ranks should have a
3/1 split, 2GB ranks a 2/2 or 3/0 split, and 4GB ranks are forced into
a 2/0 split (due to alignment needs).

> With 16GB, there is no choice other than 4GB/12GB with 1GB discarded.

4x4GB ranks would be a 2/12GB split with 2GB of discard, a rank size
must be a power of two.

At a certain point low mem exhaustion becomes a serious issue for
Linux, a system that can't DMA to 85% of its memory is incredibly
broken, IMHO.

Jason

  parent reply	other threads:[~2013-03-22 17:43 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 16:26 [PATCH 0/5] arm: mvebu: Enable LPAE support for Armada XP SoCs Gregory CLEMENT
     [not found] ` <1363883179-1361-1-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2013-03-21 16:26   ` [PATCH 1/5] arm: mvebu: Aligne the internal registers virtual base to support LPAE Gregory CLEMENT
2013-03-21 16:26 ` [PATCH 2/5] arm: mvebu: Select DMA_BOUNCE when LPAE is selected in Kconfig Gregory CLEMENT
2013-03-21 18:19   ` Rob Herring
2013-03-21 19:18   ` Andrew Lunn
     [not found]   ` <1363883179-1361-3-git-send-email-gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2013-03-22 11:32     ` Russell King - ARM Linux
     [not found]       ` <20130322113251.GB4977-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-03-23 19:48         ` Krzysztof Halasa
2013-03-21 16:26 ` [PATCH 3/5] arm: mvebu: Enable pj4b on LPAE compilations Gregory CLEMENT
2013-03-21 16:26 ` [PATCH 4/5] arm: dts: Add a 64 bits version of the skeleton device tree Gregory CLEMENT
2013-03-21 16:26 ` [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits Gregory CLEMENT
2013-03-21 17:59   ` Rob Herring
     [not found]     ` <514B4A79.1070501-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-03-21 19:03       ` Arnd Bergmann
2013-03-21 19:18         ` Thomas Petazzoni
2013-03-21 21:31           ` Arnd Bergmann
     [not found]             ` <201303212131.07629.arnd-r2nGTMty4D4@public.gmane.org>
2013-03-21 22:30               ` Sebastian Hesselbarth
2013-03-21 20:15   ` Andrew Lunn
2013-03-21 20:22     ` Thomas Petazzoni
2013-03-21 20:30       ` Jason Cooper
2013-03-21 20:37       ` Andrew Lunn
2013-03-21 21:08         ` Thomas Petazzoni
2013-03-21 21:16         ` Thomas Petazzoni
2013-03-21 20:55       ` Jason Gunthorpe
2013-03-21 21:15         ` Thomas Petazzoni
2013-03-21 21:35           ` Lior Amsalem
     [not found]             ` <EE71107DF0D1F24FA2D95041E64AB9E801A56C7B6D24-YTFUtKQQMWV5iqk/IoNZdEEOCMrvLtNR@public.gmane.org>
2013-03-21 21:46               ` Jason Gunthorpe
     [not found]                 ` <20130321214607.GC8431-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 21:58                   ` Lior Amsalem
     [not found]                     ` <EE71107DF0D1F24FA2D95041E64AB9E801A56C7B6D25-YTFUtKQQMWV5iqk/IoNZdEEOCMrvLtNR@public.gmane.org>
2013-03-22  6:55                       ` Arnd Bergmann
2013-03-21 21:41           ` Jason Gunthorpe
2013-03-21 22:26             ` Sebastian Hesselbarth
2013-03-22  9:55             ` Arnd Bergmann
     [not found]         ` <20130321205545.GA8358-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-21 21:25           ` Andrew Lunn
2013-03-22  6:28           ` Andrew Lunn
     [not found]             ` <20130322062854.GS21478-g2DYL2Zd6BY@public.gmane.org>
2013-03-22 17:43               ` Jason Gunthorpe [this message]
     [not found]                 ` <20130322174300.GA10230-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-03-22 19:33                   ` Arnd Bergmann

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=20130322174300.GA10230@obsidianresearch.com \
    --to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=andrew-g2DYL2Zd6BY@public.gmane.org \
    --cc=benavi-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=dann.frazier-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=dmarlin-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=ike.pan-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
    --cc=jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=leif.lindholm-5wv7dgnIgG8@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=maen-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=nadavh-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=shadi-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=vanhoof-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=yehuday-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    /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).