Re: [PATCH] OMAP: Increase VMALLOC_END to allow 256MB RAM

[Kevin Hilman <khilman@deeprootsystems.com>]

Mans Rullgard <mans@mansr.com> writes:

> This increases VMALLOC_END to 0x18000000, making room for 256MB
> RAM with the default 128MB vmalloc region.
>
> Signed-off-by: Mans Rullgard <mans@mansr.com>
> ---
>  arch/arm/plat-omap/include/mach/vmalloc.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/plat-omap/include/mach/vmalloc.h
> index d8515cb..b97dfaf 100644
> --- a/arch/arm/plat-omap/include/mach/vmalloc.h
> +++ b/arch/arm/plat-omap/include/mach/vmalloc.h
> @@ -17,5 +17,5 @@
>   * along with this program; if not, write to the Free Software
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
>   */
> -#define VMALLOC_END	  (PAGE_OFFSET + 0x17000000)
> +#define VMALLOC_END	  (PAGE_OFFSET + 0x18000000)

Acked-by: Kevin Hilman <khilman@deeprootsystems.com>

I have a similar patch locally, but the problem I currently have with
it is that there is no longer any hole between vmalloc space and the
beginning of IO space (the first virtual mappings start at
0xd8000000.)

It's a bit unsafe, but IMO it's is probably OK for the short term.
Longer term I think the virtual address space of the OMAP kernels
needs to be reworked.  It currenly just maps directly onto the
physical address space, which makes the IO_ADDRESS() conversion macros
simple, but leaves lots of wasted space in the virtual address space.

Kevin