* of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
@ 2010-06-25 3:45 Kyle Moffett
2010-06-25 4:01 ` Kyle Moffett
0 siblings, 1 reply; 6+ messages in thread
From: Kyle Moffett @ 2010-06-25 3:45 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
2010-06-25 3:45 of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM Kyle Moffett
@ 2010-06-25 4:01 ` Kyle Moffett
0 siblings, 0 replies; 6+ 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] 6+ 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 ` Kyle Moffett
0 siblings, 0 replies; 6+ 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. 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
>
^ permalink raw reply [flat|nested] 6+ 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 ` Kyle Moffett
(?)
@ 2010-06-28 7:18 ` Milton Miller
2010-06-28 17:05 ` Kyle Moffett
-1 siblings, 1 reply; 6+ 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] 6+ 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; 6+ 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. 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
@ 2010-06-28 17:05 ` Kyle Moffett
0 siblings, 0 replies; 6+ 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] 6+ messages in thread
end of thread, other threads:[~2010-06-28 17:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-25 3:45 of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM Kyle Moffett
2010-06-25 4:01 ` Kyle Moffett
2010-06-25 4:01 ` Kyle Moffett
2010-06-28 7:18 ` Milton Miller
2010-06-28 17:05 ` Kyle Moffett
2010-06-28 17:05 ` Kyle Moffett
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.