Messages in this thread | | | Date | Mon, 16 Aug 1999 17:05:23 -0700 | From | Richard Henderson <> | Subject | Re: New resources - pls, explain :-( |
| |
On Mon, Aug 16, 1999 at 11:37:14AM +0100, Alan Cox wrote: > How do you propose to implement bus specific ioremap efficiently on the > majority of CPU's which don't have magic endian bits in the MMU, don't have > magic coherency bits in the MMU.
The very same way it's done now. That is to say, by ignoring the issue entirely.
Why do you even consider these an issue? What has the memory map got to do (necessarily) with the bus type? And why would things be more or less efficient based on whether the arch has magic mmu bits? Either you need coherency or you don't, and consequently you either have mmu bits or you have mb insns.
What _I_ want is for pci_ioremap to take the struct pci_dev for the device the driver wants to map, so that I can track down which 32-bit I/O space to allocate from, depending on which of N non-bridged PCI busses the device is located on. The hack in place at present is too gross to live, and won't scale to the larger Alpha machines (144 PCI slots).
I want a PCI_ioremap so that I can pass in data that is _clearly_ PCI related -- the pci_dev. I also want an ISA_ioremap because it would be stupid to pretend crufty old drivers could gen up a fake pci_dev struct just so it could pass off the info to the new pci_ioremap. All the important bits in the pci_dev were filled in by arch specific code at boot time. (I am fortunate that while I have multiple PCI busses, I only ever have one EISA bus, so I never have to hunt down the proper I/O space for that case.)
Everything I propose above _speeds_ ioremap. What objection do you have? If I've completely missed what you were trying to express above, please spell it out in small words.
r~
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |