On Wed, Jul 14, 2010 at 08:04:07PM +0900, Minchan Kim wrote: > On Wed, Jul 14, 2010 at 5:49 PM, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 14, 2010 at 08:59:06AM +0900, Minchan Kim wrote: > >> But I think Kukjin case's best solution is to make section size 16M, not 256M. > >> Regardless of this, Your idea is the direction we should proceed, I think. > > > > So what if someone decides to fit 8MB DRAMs to the board? > > > > Hmm. It might be a problem. > Should we consider all configuration? > > Then, in below cases ram size never can change? > How does it acked and merged? > I don't know below board can't configurable ram size. Just out of curiosity. All of these, SECTION_SIZE_BITS refers to the _spacing_ of memory, not the minimum size of DRAM which can ever be fitted. Reducing SECTION_SIZE_BITS is really not an option for some of these platforms - just look at where memory starts in physical space: arch/arm/mach-clps711x/include/mach/memory.h:#define PHYS_OFFSET UL(0xc0000000) arch/arm/mach-clps711x/include/mach/memory.h:#define SECTION_SIZE_BITS 24 arch/arm/mach-lh7a40x/include/mach/memory.h:#define PHYS_OFFSET UL(0xc0000000) arch/arm/mach-lh7a40x/include/mach/memory.h:#define SECTION_SIZE_BITS 24 arch/arm/mach-realview/include/mach/memory.h:#define PHYS_OFFSET UL(0x70000000) arch/arm/mach-realview/include/mach/memory.h:#define SECTION_SIZE_BITS 28 arch/arm/mach-realview/include/mach/memory.h:#define PHYS_OFFSET UL(0x00000000) arch/arm/mach-rpc/include/mach/memory.h:#define PHYS_OFFSET UL(0x10000000) arch/arm/mach-rpc/include/mach/memory.h:#define SECTION_SIZE_BITS 26 arch/arm/mach-s5pv210/include/mach/memory.h:#define PHYS_OFFSET UL(0x20000000) arch/arm/mach-s5pv210/include/mach/memory.h:#define SECTION_SIZE_BITS 28 arch/arm/mach-sa1100/include/mach/memory.h:#define PHYS_OFFSET UL(0xc0000000) arch/arm/mach-sa1100/include/mach/memory.h:#define SECTION_SIZE_BITS 27 If physical memory starts at 3GB, with SECTION_SIZE_BITS set at 24, there's 256 sections already. Reducing SECTION_SIZE_BITS to the multiple of RAM size will increase the number of sections to many thousands. Clearly, sparsemem doesn't handle sparse memory very well, and is defficient. I don't know what the answer is to this; I'm totally fed up with being pushed into using things, and then later down the line being told that its all wrong and shouldn't be used like we are. Maybe we should just delete these sub-architectures which use sparsemem and say to people that the kernel just doesn't support their memory layouts. <depressed>. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |