Messages in this thread | | | Subject | Re: Specifying properly the PCI driver model on all linux archite ctur es, (ioremap(), bus_to_virt() ...) | From | Jes Sorensen <> | Date | 02 Nov 1999 16:25:41 +0100 |
| |
>>>>> "Bret" == Bret Indrelee <bindrelee@sbs-cp.com> writes:
Bret> Jes Sorensen [mailto:Jes.Sorensen@cern.ch] wrote: >> This goal is already achieved, if the PPC uses bus_to_virt() it is >> doing it wrong. The correct way is to use ioremap(), however what >> ioremap() returns what could be referred to as a _bus_ _virtual_ >> address.
Bret> I think it would help a lot of people started talking about Bret> three different addresses: 1. The Bus physical address, Bret> i.e. what is in the PCI configuration registers. 2. The System Bret> physical address, i.e. what ioremap() uses and is found in the Bret> struct pci_dev base_address[] array. It is the physical address Bret> used by the CPU. On systems like SPARC, this address would then Bret> go through the IOMMU to generate the correct bus physical Bret> address. 3. The System virtual address, i.e. what the Bret> programmer uses to reference the address space. It goes through Bret> the normal kernel virtual address translation.
Dont' forget that the virtual address you get from ioremap() is not a real pointer in the sense that you are allowed to directly reference the memory it points at.
>> This one is not allowed to be accessed directly by the CPU but must >> use the readl/writel macros, or __raw_readl/__raw_writel ones.
Bret> Where in the heck did you find that?
By following Linux kernel.
Bret> I was under the impression that the readb/w/l and writeb/w/l Bret> were only for spaces marked as I/O space in PCI. I thought that Bret> if it was in PCI memory space you could directly reference the Bret> address after you used ioremap().
I/O space as in I/O ports registers or as in PCI shared memory?
Bret> If this is true, you can't just directly access the virtual Bret> address, then somebody should really add this information to the Bret> Documentation/pci.txt file.
The problem here is that some PCI implementations will not provide a direct linear mapping of the PCI shared memory space, like on some Alphas which come with sparse memory.
>> Remember that the base_address[] value are not some that we just >> make out of nowhere, they are assigned by the hardware/bios at boot >> time and we read them out of registers.
Bret> Actually, my understanding is that the base_address[] is Bret> assigned in the PCI configuration.
Correct, maybe I wasn't clear enough on this one.
Bret> If people really want to get the device drivers all working Bret> correctly, you should probably start by agreeing on AND Bret> DOCUMENTING exactly what 'correct' is. Without such information Bret> available, people are going to keep on having problems writing Bret> device drivers.
I thought it was already documented, but I guess you are right. Documentation/pci.txt still refers to the old and deprecated pcibios_foo() functions and Documentation/IO-mapping.txt doesn't mention sparse memory directly, though it does state that one should use readl/writel.
Jes
- 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/
| |