On Wed, May 15, 2013 at 08:58:03AM -0700, Vadim Bendebury wrote:
On Tue, Apr 30, 2013 at 2:14 PM, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/30/2013 04:49 PM, Doug Anderson wrote:
Tom,
On Tue, Apr 30, 2013 at 1:35 PM, Tom Rini trini@ti.com wrote:
And I guess having this knowledge correct for the kernel is useful in other contexts like when we want to power down some banks of memory but not others? I mean, there's "lots" of platforms that lie and say 1 bank since we require contiguous mapping. Thanks!
Thanks for the review!
At the moment I'm _not_ convinced that there's a good reason to specify 8 banks. We appear to have lied and said 1 bank on exynos5250-snow (ARM Chromebook) and I don't know of any bad side effects.
The code I'm looking at right now indicates 8 banks. We need to track down why someone did that but it doesn't seem totally crazy to allow specifying the proper number of banks so I figured I'd send this patch up.
If you prefer, we can leave this patch hanging until we actually track down if specifying 8 banks was really needed.
Yes please, lets hold. Thanks!
I looked into this a bit more, what happens on this particular target (Exynos5420 with 4GB DRAM onboard) is that out of 4GB of memory only 3.5GB is usable, as the lower .5 GB of address range is taken by the architecture, and the address bus width is 32 bits.
U-boot code makes several assumptions:
- bank size is a power of 2
- bank base is aligned with bank size
- all bank sizes are the same
with this in mind, the only way to describe our memory situation is to define 7 banks, .5GB each, the lowest one starting at 0x20000000 (.5GB).
This is not a big deal for u-boot (maybe very marginally inefficient when determining the actual memory size). Is this a big deal for kernel? I mean it is easy to squash these seven memory banks into one when filling out the memory node of the device tree, the question is is it even necessary?
OK, this would be the second case of needing to describe the memory in the DT in a way that conflicts with how we dynamically do the node. Lets go and try again at a patch that lets boards opt-in to "do not override the memory property, it was already correct and you broke it".