linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: cgagneraud@techworks.ie (Christian Gagneraud)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem
Date: Mon, 05 Oct 2009 19:16:39 +0100	[thread overview]
Message-ID: <4ACA3807.9050908@techworks.ie> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190901DB7687@mi8nycmail19.Mi8.com>

H Hartley Sweeten wrote:
> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
>> Hi,
>>
>> What people think about enabling sparsemem on EP93XX? I know this 
>> patch as it is will break all but this board.
>>
>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
>> will suit all the supported boards?
> 
> With sparsemem enabled what is your memory detected during boot?  For
> instance on my ep9307 based system with flatmem I get:
> 
> Memory: 32MB 32MB = 64MB total
> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem)
           ^^^^^
Are you missing 16MB?

Here is what i get with sparsemem:

Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total 

Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem)

> And cat /proc/iomem shows:
> 
> c0000000-c1ffffff : System RAM
>   c0027000-c0385fff : Kernel text
>   c03a0000-c03df88f : Kernel data
> c4000000-c5ffffff : System RAM


00000000-007fffff : System RAM 

   00020000-00276fff : Kernel text 

   00278000-002c1923 : Kernel data 

01000000-017fffff : System RAM 

04000000-047fffff : System RAM 

05000000-057fffff : System RAM
80010000-8001ffff : ep93xx-eth 

   80010000-8001ffff : ep93xx-eth 

80020000-80020fff : ep93xx-ohci 

808c0000-808c0fff : apb:uart1 

   808c0000-808c003f : uart-pl010 

808d0000-808d0fff : apb:uart2 

   808d0000-808d003f : uart-pl010 

808e0000-808e0fff : apb:uart3 

   808e0000-808e003f : uart-pl010 

80920000-8092010b : ep93xx-rtc
e0000000-e07fffff : System RAM 

e1000000-e17fffff : System RAM 

e4000000-e47fffff : System RAM 

e5000000-e57fffff : System RAM


For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that 
shows at 0x00000000, for boards shipped with 64MB there's another 32MB 
chip on SD_CS2 which pop up at 0xe0000000

That's for the models that offer 32 or 64MB, but TS have other models 
that offer 64 or 128MB, these boards are designed the same way: 1 64MB 
chip on SD_CS3 and optional a second 64MB chip on SD_CS2.
I was told that in that case 16 banks needed to be define (and btw it 
couldn't be handled , I didn't check it yet.

Before sparsemem, we had to use discontigmem (and patch it),now with 
parsemem there's no needs for such a thing anymore, the only needed 
bits are 4 #define.


> 
> So the kernel finds two 32MB chunks which is what the bootloader passed
> in the ATAGS.  And the addresses match what was passed.
> 
> What is your intended result by switching to sparsemem?
> 
> I have also messed with sparsemem and I get the same results as above
> with it enabled.  I don't see any real reason to switch to sparsemem.
> 
> The _only_ reason I can see is if a system has more than 8 banks of
> memory.  I think that is the current limit for flatmem support in the
> kernel.  There are only two configuration I know of that can cause this
> on the ep93xx when only on chip select is used:
> 
> 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 0 -> 16 banks
> 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 0 -> 16 banks
> 
> Both of these configuration can be "fixed" by having the bootloader set
> the SROMLL bit = 1. 
> 
> 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 1 -> 8 banks
> 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 1 -> 1 bank
> 
> Please refer to the following document for more information:
> 
> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Interesting, thank you.

Regards,
Chris

> 
> Regards,
> Hartley

  reply	other threads:[~2009-10-05 18:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-04  1:14 [RFC][PATCH v1.0] Update and enhance TS-7XXX support Christian Gagneraud
2009-10-04  1:14 ` [PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg Christian Gagneraud
2009-10-04  1:14 ` [PATCH v1.0 2/4] TS72XX: Allow to override machine ID Christian Gagneraud
2009-10-04 11:05   ` Matthieu Crapet
2009-10-04 11:13   ` Alexander Clouter
2009-10-04 18:34     ` Bill Gatliff
2009-10-04 18:35     ` Bill Gatliff
2009-10-04 11:21   ` Russell King - ARM Linux
2009-10-04 11:55     ` Christian Gagneraud
2009-10-04 23:03   ` H Hartley Sweeten
2009-10-05 12:17     ` Christian Gagneraud
2009-10-05 14:10       ` Alexander Clouter
2009-10-05 15:15       ` Mikael Pettersson
2009-10-05 16:01         ` Marek Vasut
2009-10-05 18:34           ` Christian Gagneraud
2009-10-04  1:14 ` [PATCH v1.0 3/4] EP93XX: Add more register definition Christian Gagneraud
2009-10-04 19:33   ` Ryan Mallon
2009-10-04 23:09   ` H Hartley Sweeten
2009-10-05 12:06     ` Christian Gagneraud
2009-10-05 16:51       ` H Hartley Sweeten
2009-10-05 18:30         ` Christian Gagneraud
2009-10-04  1:14 ` [PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem Christian Gagneraud
2009-10-05 12:21   ` Christian Gagneraud
2009-10-05 17:06     ` H Hartley Sweeten
2009-10-05 18:16       ` Christian Gagneraud [this message]
2009-10-05 18:52         ` H Hartley Sweeten
2009-10-06 21:21           ` Christian Gagneraud
2009-10-06 21:26             ` Christian Gagneraud

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=4ACA3807.9050908@techworks.ie \
    --to=cgagneraud@techworks.ie \
    --cc=linux-arm-kernel@lists.infradead.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).