Re: Reclaim address space on omaps, Tony on vacation in July

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Shilimkar, Santosh <santosh.shilimkar@xxxxxx> [090626 10:45]:
> > -----Original Message-----
> > From: linux-omap-owner@xxxxxxxxxxxxxxx 
> > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren
> > Sent: Friday, June 26, 2009 11:56 AM
> > To: linux-omap@xxxxxxxxxxxxxxx
> > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: RFC: Reclaim address space on omaps, Tony on vacation in July
> > 
> > Hi all,
> > 
> > Last week I posted some more omap io.h clean-up patches to 
> > the linux-omap
> > list [1], and started looking at what it would take to 
> > reclaim lost address
> > space on top of the io.h clean-up patches.
> > 
> > Looks like we should be able to reclaim about 454MB of the 640MB
> > of the lost IO address space by doing the following:
> > 
> > 1. Start converting drivers using omap_read/write to use ioremap +
> >    __raw_read/write
> > 
> > 2. Remove OMAP2_IO_ADDRESS macro, and replace it with with 
> > finer grained
> >    OMAP_L3_ADDRESS, OMAP_L4_ADDRESS, OMAP_SDRC_ADDRESS and so 
> > on macros
> 
> > 3. Remap the the IO addresses in smaller sections in io.h so 
> > the virtual
> >    address for the blocks stays the same, and is counted down from the
> >    ARM reserved DMA address.
> > 
> > After these steps, omap io.h would look like this:
> > 
> > #define ARM_RESERVED_FUTURE_DMA	0xff000000 /* 
> > Documentation/arm/memory.txt */
> > #define OMAP23_L4_PHYS		0x48000000
> > #define OMAP24_L3_PHYS		0x68000000
> > #define OMAP4_L3_PHYS		0x44000000
> > #define OMAP4_L4_PHYS		0x4a000000
> > 
> > /* These virtual addresses are the same for all omaps */
> > #define OMAP_L3_SIZE		SZ_1M
> > #define OMAP_L3_VIRT		(ARM_RESERVED_FUTURE_DMA - OMAP_L3_SIZE)
> > #define OMAP_L4_SIZE		(SZ_16M + SZ_1M)
> > #define OMAP_L4_VIRT		(OMAP_L3_VIRT - OMAP_L4_SIZE)
> > #define OMAP_SDRC_SIZE		SZ_1M
> > #define OMAP_SDRC_BASE		(OMAP_L4_VIRT - OMAP_SDRC_SIZE)
> > ...
> > 
> > 
> > #define OMAP_L3_ADDRESS(pa)	(((pa) & ~0xff000000) + OMAP_L3_VIRT)
> > #define OMAP_L4_ADDRESS(pa)	(((pa) & ~0xff000000) + OMAP_L4_VIRT)
> > #define OMAP_SDRC_ADDRESS(pa)	(((pa) & ~0xff000000) + OMAP_SDRC_VIRT)
> We surely need this going forward since there is also demand to fit higher 
> RAMS(256MB,512MB,1GB)in the system. 
> 
> Just to confirm, any further patches on this topic should be on top of this:
> Tony Lindgren (3):
>       OMAP: Remove ifdefs for io.h
>       OMAP: Rename OMAP_MPUIO_BASE to OMAP1_MPUIO_BASE
>       OMAP: Remove OMAP_IO_ADDRESS, use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS instead
> 
> Is that correct Tony ?

Yes it makes it easier as the patches above remove all the ifdefs for io.h.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux