* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM [not found] <AANLkTinoWJR77N9C_We-_xD4ZeXjTx2naBUzCun6VoQv@mail.gmail.com> @ 2010-06-25 4:01 ` Kyle Moffett 2010-06-28 7:18 ` Milton Miller 0 siblings, 1 reply; 3+ messages in thread From: Kyle Moffett @ 2010-06-25 4:01 UTC (permalink / raw) To: linuxppc-dev, linux-kernel Oops... put the old linuxppc list on the CC, sorry! On Thu, Jun 24, 2010 at 23:45, Kyle Moffett <kyle@moffetthome.net> wrote: > Hello, > > 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. =C2=A0Unfortunately 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. =C2=A0I 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? =C2=A0If not= , > what changes would need to be made to MTD and/or "of-flash" to create > such functionality? > > Cheers, > Kyle Moffett > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM 2010-06-25 4:01 ` of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM Kyle Moffett @ 2010-06-28 7:18 ` Milton Miller 2010-06-28 17:05 ` Kyle Moffett 0 siblings, 1 reply; 3+ messages in thread From: Milton Miller @ 2010-06-28 7:18 UTC (permalink / raw) To: Kyle Moffett; +Cc: linux-mtd, linuxppc-dev On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote: > Oops... put the old linuxppc list on the CC, sorry! > > On Thu, Jun 24, 2010 at 23:45, Kyle Moffett <kyle at moffetthome.net> wrote: > > Hello, > > > > 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? > > > > Cheers, > > Kyle Moffett > > I believe the MTD layer would be happy, but it is beyond the scope of the physmap_of driver. A look at drivers/mtd/maps/pcmciamtd.c shows the concept of paging in a section of flash, although it has the advantage of hardware to move the window instead of calling ioremap or swapping translations. Another example is drivers/mtd/maps/pci.c, also with hardware assist. milton ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM 2010-06-28 7:18 ` Milton Miller @ 2010-06-28 17:05 ` Kyle Moffett 0 siblings, 0 replies; 3+ messages in thread From: Kyle Moffett @ 2010-06-28 17:05 UTC (permalink / raw) To: Milton Miller; +Cc: linux-mtd, linuxppc-dev On Mon, Jun 28, 2010 at 03:18, Milton Miller <miltonm@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. =C2=A0Unfortunately when I configure both flashe= s >> 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. =C2=A0I would much rather have a 5= 0% >> 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? =C2=A0If no= t, >> 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-06-28 17:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTinoWJR77N9C_We-_xD4ZeXjTx2naBUzCun6VoQv@mail.gmail.com>
2010-06-25 4:01 ` of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM Kyle Moffett
2010-06-28 7:18 ` Milton Miller
2010-06-28 17:05 ` Kyle Moffett
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).