[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: ioremap non-contiguous phys to contiguous virt?
From:       Matthias Welwarsky <mwelwarsky () web ! de>
Date:       2004-10-18 20:56:46
Message-ID: 200410182256.47006.mwelwarsky () web ! de
[Download RAW message or body]

Hi Marc,

I'm not completely familiar with flash programming procedures, but don't you 
have to do write accesses to certain physical locations of the flash to 
unlock and erase its sections? Don't you need to know the physical address of 
the flash in order to do that?

I'm not saying that this is actually a problem, but I can image it might if 
jffs2 assumes that can do virt2phys() on an ioremapped address to get the 
physical location?


On Monday, 18. October 2004 21:34, Marc Singer wrote:
> For the sake of the making it easy on the mtd drivers, I'd like to map
> discontiguous physical memory to a contiguous virtual address space.
> This hardware layout is an artifact of the design that allows a larger
> flash device to be used in later implementations.
>
> I think that my options are
>
>   1) ignore the problem and create a custom maps driver with NO_XIP set.
>   2) create a custom maps driver, but use the io_table_init mechanism
>      to map the memory contiguously (eeww)
>   3) find a clever method to do something like this
>
>      struct memvec mv = { { PHYS0, LEN0 }, {PHYS1, LEN1 } };
>      void* virt = ioremapv (memvec, 2);
>
> I can see from the ioremap code that this would be simple to
> implement.  The questions are these: is there a better way?, is this a
> bad idea?
>
> There is a simple reason why this is desirable.  The jffs2 driver uses
> a feature of the MTD driver that grants it access to the flash memory
> array using a simple pointer.  Using option 1) above, I can circumvent
> the issue by telling MTD that the flash cannot be use for XIP and is,
> therefore, not linearly mapped.
>
> Cheers.
>
>
> -------------------------------------------------------------------
> Subscription options:
> http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel FAQ:      
> http://www.arm.linux.org.uk/armlinux/mlfaq.php
> Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]