of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM

[Kyle Moffett]

On Mon, Jun 28, 2010 at 03:18, Milton Miller <miltonm at 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