Dan Malek writes: > When did I ever complain about a device tree? I think it's the right > idea, I just didn't like the way we were getting there on systems > that don't have OF.
OK, that's cool then. I didn't think we were getting "there" (i.e. towards having a device tree) at all yet on systems without OF though. In 2.5 the devicefs stuff may yet give us an acceptable unification. > What isn't needed? The page tables or the iopa()? I'm tired of having The page table pages aren't needed and are a pain for large-page entries on 4xx since the pmd is already largely occupied with the physical base address and other bits. As for iopa(), what I mainly don't like is its use in virt_to_phys and virt_to_bus. The reason for that is that every other architecture restricts the use of virt_to_phys/bus to addresses that are part of the kernel mapping of lowmem, which means that they become very simple. Using iopa() in virt_to_* is just going to tempt us to use them on other sorts of addresses, which will make our drivers less portable. Instead I think that we should only use virt_to_* on addresses that are part of the kernel mapping of lowmem. If a driver uses consistent_alloc or pci_alloc_consistent, the driver should save and use the physical address returned by those functions. Ideally we would have analogous routines to pci_[un]map_single for the on-chip devices. With that, I think there would be very few legitimate reasons for a driver to need to use virt_to_* directly at all. > different methods to look up VM information just because the memory > was allocated in a different way. With iopa() (which seems fine for > other architectures to use) I don't care how the memory was allocated, > I just feed it a virtual address and get the answer. What's wrong with > that (other than it's not a hack :-)? The page tables have always Well, if what you fed it was obtained from vmalloc, and you don't deal explicitly with the fact that vmalloc'd memory is not physically contiguous, you are in danger of DMA'ing into some random page somewhere and corrupting it. If what you feed it is a user address and you start some DMA into it, you have in addition to the physical discontiguity the fact that the page might get taken away from the process and used for something else before the DMA finishes. So in general if you want an address for doing DMA, virt_to_bus is really only safe on kernel addresses (i.e. addresses that are within the kernel mapping of lowmem). Do you have other situations in mind (other than debugging-type things) where you need to use virt_to_phys/bus on something that isn't a lowmem address? > been there, and it's not a big deal. Why haven't we done the same > hack for processors with BATs? They don't need the page tables either. True. :) > I also stated the importance of the page tables is to allow background > hardware debuggers to look up translations so they can work with Linux. > Kind of a nice thing to have once in a while. That's reasonable. > I find a simple solution for an enhancement and you don't like it because > it isn't a big hacked up mess (or maybe because I had an original thought). I don't see a lot of value in doing things differently from all the other architectures in this instance, and I think that restricting virt_to_bus/phys to lowmem addresses is reasonable. I don't mind if iopa() stays around for a few specialized uses. > If I would have made the same hacked up mess you have done it wouldn't have > been checked in.....not long ago all of the embedded stuff was viewed as a > problem child, and today it's OK to hack up generic code with an #ifdef Viewed as a problem child? By whom? > for a specific IBM embedded processor???? Does that surprise you? :-) You know I hate ifdefs. :) Paul. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
