> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> > > 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: Using section entries to cover ranges provides superior performance. 1 TLB will cover a whole series of accesses when doing things like servicing an interrupt. Using fewer TLBs to cover system accesses leaves more in tact for application usage. I've not see recent data but long back TLB optimization provided sizeable performance boost for many applications. Additionally debug is simplified by having the simple static map around. Russell recently pointed out and David showed an example of how ioremap() can take an arch specific function which can return virtual address from already defined static ranges. I do think this is a nice clean up and optimization (to stop some double mapping which now happens with ioremap). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg03813.html So, I think yes moving to ioremap in all drivers is good, but it would use underlying static maps where they exist. It might be not _all_ ranges need to be fully static mapped, but the common device ones should be. On this thread there has been a mounting request for more physical memory. Starting to make a 2x2gig split option and perhaps understanding more how to use extended addressing like xscale is doing would be good road map stuff. If io.h is getting messy maybe it should be broken in to a couple files... Anyway, driver cleanup using common ioremap would be the big winner. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
