[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[cgagneraud@techworks.ie (Christian Gagneraud)]

H Hartley Sweeten wrote:
> On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote:
>> 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?
> 
> No.  My rootfs is in /dev/ram and uses the remaining space.
> 
>> 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)
>>
>> 00000000-007fffff : System RAM 
>>   00020000-00276fff : Kernel text 
>>   00278000-002c1923 : Kernel data 
>> 01000000-017fffff : System RAM 
>> 04000000-047fffff : System RAM 
>> 05000000-057fffff : System RAM
>> 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
> 
> OK.  That makes sense.  I was under the impression that the 64MB board
> was using a single chip select.
>  
>> 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.
> 
> The single chip 64MB board would work fine but it would use 8 banks.  The
> 128MB board would be a problem with flatmem because of the 16 banks.  In
> order to support this NR_BANKS would have to be increased in
> arch/arm/include/asm/setup.h.
> 
>> 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.
> 
> Sparsemem is probably a good solution for the multiple chip selects.  But
> we need to make sure that any solution used works for all ep93xx variants.
> 
> The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async)
> boot, there are 5 possible base addresses for them.  Then, depending on
> the bus width and the density of memory used, the node mapping for each
> bank can vary greatly.  Even worse, node mapping changes depending on the
> SROMLL bit.  The document referenced below has all the information needed
> but at this point I don't know of a good solution.
> 
>> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Actually, in the EP93XX User's Manual, the table 13-11 on pages 3-12 
to 13-16 gives all the possibilities.

When SROMLL=0, SECTION_SIZE_BITS=24 suits all the cases (segments are 
always spaced by a multiple of 16MB: 0xNM00.0000 with N=0,C,D,E,F 
depending of the chip select, and M=1,2,..,F).

Now for SROMLL=1, I see at least 4 exceptions:
- 64MBit/32bit/11x8x4banks => 4 segments of 2MB spaced by 4MB:
   - 0xN000-0xN01F
   - 0xN040-...
   - 0xN080-...
   - 0xN0C0-...

   23 >= SECTION_SIZE_BITS >= 22

- 128MBit/32bit/12x9x4banks => 1 segment of 32 MB
   - 0xN000-0xN1FF

   SECTION_SIZE_BITS >= 25

- 256Mbit/32bit/13x9x4banks => 2 segments of 32 MB spaced by 64MB:
   - 0xN000-0xN1FF
   - 0xN400-...

   26 >= SECTION_SIZE_BITS >=25

- 512Mbit/32bit/13x10x4 => 1 segment of 128 MB
   - 0xN000-0xN7FF

   SECTION_SIZE_BITS>=27

(Am I right Russel?)

So on 12 possibilities, there's only 4 exceptions.

And finally for the virt<->phys:

There's 4 chip select, one of them can pop-up at two different 
addresses. The biggest SDRAM segment being 128MB, we
have the following possible address ranges:
0x0000-0x07FF
0xC000-0xC7FF
0xD000-0xD7FF
0xE000-0xE7FF
0xF000-0xF7FF

So why not a mapping like this one:
0xC000 => PAGE_OFFSET + 0x0000 (1100.0XXX => XX00.0XXX)
0xD000 => PAGE_OFFSET + 0x0800 (1101.0XXX => XX00.1XXX)
0xE000 => PAGE_OFFSET + 0x1000 (1110.0XXX => XX01.0XXX)
0xF000 => PAGE_OFFSET + 0x1800 (1111.0XXX => XX01.1XXX)
0x0000 => PAGE_OFFSET + 0x2000 (0000.0XXX => XX10.0XXX)

Which should be done with:
((pa&0x80000000) ? (pa&0x07FFFFFF)|((pa&0x30000000)>>1) : 
(pa|0x20000000)) | PAGE_OFFSET

and for virt_to_phys something like:
(va&0x07FFFFFFF)| ((va&0x20000000) ? ((va&0x18000000)<<1)|0xC0000000 : 
  0x00000000)
(NB: this macro is PHYS_OFFSET agnostic and allow the use of multiple 
chips select)

A simpler possibility would be to activate sparsemem only for ts72xx 
and stuff memory.h with:

#if defined(CONFIG_SPARSEMEM)
#if defined(CONFIG_MACH_TS72XX)
...
#else
#error ...
#endif
#endif


What do you think?

Regards,
Chris


> 
> Maybe Russell can help (Cced).
> 
> Regards,
> Hartley