On Wed, 2005-05-25 at 01:49 -0400, Dan Malek wrote: > On May 25, 2005, at 1:20 AM, Benjamin Herrenschmidt wrote: > > > Ok, that was my point... since init page tables can be loaded by it, > > why > > not make ioremap work that early and do the same ? > > Because you lose the efficiency of mapping with BATs or CAMs. > > > ... The problem is of > > course allocating the pte pages but how does io_block_mapping() do on > > CPUS without BAT/CAMs/whatever ? > > It just loads init's page tables directly. > > > We have the pgdir, but not the PTE pages... > > The PTE pages are allocated as they are needed. The PTE pages > are there :-)
Well, you say "loads init's page tables directly"... well, init starts with a pgdir, it needs to allocate PTE pages in order to "load" the page tables with PTEs, thus my question, how does io_block_mapping does this ? It use the bootmem allocator ? If yes, then that means we can have ioremap working as well. I'm not completely arguing against io_block_mapping() but I think it's abused, and thus looking into encouraging different approaches. > > No, we have a trick with ioremap_bot, we don't need to get vmalloc > > space > > for ioremap to work early. > > That's only if you have already done something to already allocate BATs > or CAMs. On processors that don't have these, ioremap() would fail > because it would think it has to allocate VM space. The ioremap_bot trick works in whatever case provided MMU_init has been called so ioremap_bot & ioremap_base are initialized. It would be fairly easy to turn that into a static init though. > > .... In fact, it would be nice to just have > > io_block_mapping be able to "dynamically" allocate virtual space using > > the same mecanism instead of beeing passed a virtual address. That > > would > > fix most of the problems with hard coded 1:1 mappings. > > I think we should make ioremap() smarter and have some board > initialization that helps it by setting up BATs, CAMs, or unique page table > mappings. There is also an interdependence between ioremap() and other IO > initialization. In the past some of the fixed addressing was necessary > due to assumptions built into IO setup, mapping functions, or macros. I > don't know how much of this is still present. It depends on the platform I suppose. There is still a few bits in PReP that I can fix, I'm not sure about embedded. > > Well, my problem is with hard-coded v:p mappings... If we can simply > > have io_block_mapping take, for example, 0 for v (or -1) and use the > > ioremap_bot trick to "allocate" virtual space, that would make me happy > > (it needs to return the allocated address too). > > Somewhere, at some point, prior to VM setup, we need to forcibly map > virtual to physical addresses. These are going to be "hard coded" > mappings, that's exactly how ioremap_bot is set. This is why > io_block_mapping was created in the first place. Somehow you have > to specify this mapping before you have a VM allocator to give it to > you. :-) No, you just need to have ioremap_bot (which is in fact "top" not "bottom", bad naming) initialized to something sane. This is currently done in MMU_init() but could probably be initialized statically instead. I do just that on ppc64 and thus can ioremap at any time without needing to allocate vmalloc space. The vmalloc space is automatically "cap'd" by ioremap_bot anyway. > Even if you don't call it io_block_mapping(), you are going to need > a function that does exactly this.
