On Mon, Jun 28, 2010 at 03:18, Milton Miller <milt...@bga.com> wrote: > On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote: >> I've got a new P2020 (32bit mpc85xx family) board I'm working on a >> port for that includes 2 NOR flashes (128MB each) and a removable >> SO-RDIMM of 2GB or 4GB. Unfortunately when I configure both flashes >> in the device-tree off my elbc, Linux is completely unable to access >> the second one because it attempts to ioremap() the entire virtual >> address space of both FLASH chips. >> >> Even with only one flash chip enabled, there's a bit of a noticeable >> performance degradation because the mapping consumes almost all of my >> available vmalloc space and forces bounce-buffering for all my >> HIGHMEM. >> >> It looks like the "of-flash" driver currently requires that the whole >> chip be mapped in the kernel at once. I would much rather have a 50% >> performance penalty on flash accesses (which are already very slow) >> and regain most of the vmap space. >> >> So the question is, is there a way to convince the MTD layer to >> iomap() only what it needs to access to do reads and writes? If not, >> what changes would need to be made to MTD and/or "of-flash" to create >> such functionality? > > I believe the MTD layer would be happy, but it is beyond the scope of > the physmap_of driver.
Well, I believe that the physmap_of driver is the correct place for it; that driver is used by a large number of embedded PPC systems and at present it is completely unable to handle some of the larger flash memories currently being produced (256MByte+), and there's a decent system-wide performance penalty (due to lack of ioremap space) even for the larger flash memories which do function. Cheers, Kyle Moffett _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
