"Woodruff, Richard" <r-woodru...@ti.com> writes: >> 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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
