"Woodruff, Richard" <r-woodruff2@xxxxxx> writes: >> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >> owner@xxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxx/msg03813.html > > So, I think yes moving to ioremap in all drivers is good, but it would use underlying static maps where they exist. Current linux-omap has worked like this for a while now. IOW, ioremap() will first check any static mappings before doing a real remap. So, without any changes to the memory map, everything could be converted to ioremap + read/write already. Kevin -- 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
