-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Mar 17, 2007 at 10:23:18AM +0200, Tzahi Fadida wrote: > Hi, > First, i am more interested in X86 behavior... > Moreover, the following is probably a BIG salad of wrong use/mix of terms so > bear with me and correct me where needed. > Generally, i big time did not understand this concept of memory mapping to > hardware in PCI. > > I have been reading LDD3 but failed to understand some things. > If i recall something from electronics, the ISA I/O worked like this: > you executed a special I/O write assembly command to the CPU which just > switched the writing from RAM data bus to the I/O data bus. I believe the > 16 bits of the address bus was used for both cases. That's right for IO mapped devices. There were quite some ISA devices with memory mapped IO, think for example about network cards like the WD 80x3. > Now, as i understand, in > linux, you can map a region of I/O ports (I/O address) to a memory region and > the kernel just translates the pointer to memory somehow to a port. > This is done in software or in hardware i don't know, perhaps with something > called IOMMU (so tell me :) ). That can only be done for devices with memory mapped IO so it's a hardware "trick", not a software trick. > Now, for PCI: > It naturally have some kind of separate xx-bits data bus to write the data but > it probably also shares the address bus with the memory bus in the wires of > the CPU. However, differently from ISA the address bus is more weird in that > you can add another redirection to a specific device using the combination of > domain/bus/device/function. Device/function is only to distinguish between classes of devices. It doesn't mean that every device/function combination has its own separate address space on the bus. > Each of these you can address the complete 32/64 > bits address space, though for memory mapping all the devices share the same > address space (otherwise how a mere pointer will know where to go). > Again, somehow mapped using probably something called IOMMU. A CPU can have more than one PCI bus attached. Each bus has it's own 32/64 bits address space. An IOMMU can be used to map smaller pieces of each PCI bus address space into the CPU address space. > Does it behave exactly like ISA when writing either to ports or to mapped > memory regions? Yes. Most of the PCI functionality is to overcome ISA limitations. PCI has a larger address space, a faster bus clock, and resources can be assigned dynamically. > with the exception that it's I/O address region starts just after the end of > the ISA region(don't know where)? ISA has only a 64k IO address space simply because it's not an ISA bus limititation, but a CPU limitation. Trading in the ISA bus for the PCI bus doesn't make the CPU limitation go away: all x86 CPUs still have a 64k IO address space. > or from the bus/device/function combo it knows how to avoid that somehow? > Do i need to explicitly map the ports to a memory region or the kernel somehow > knows to do that for me (from the values written in the PCI peripheral > registers). I.e. if i just *mem_reg_pointer = 1; will cause the > kernel by hardware or software to redirect this write to PCI I/O ports? The answers to those questions can be found in the file Documentation/IO-mapping.txt in your kernel tree. The most important is that you can't use *mem_reg_pointer = 1; > In these functions like: > int pci_bus_read_config_byte (struct pci_bus *bus, unsigned int devfn, int > where, u8 *val); > The devfn means both the device 5 bits and the 3 function bits? I wouldn't know and I don't actually care. You usually use pci_read_config_byte() and friends and let the PCI subsystem care about the devfn parameters. Erik - -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF/oBU/PlVHJtIto0RAg2kAJ983YPX7OsQNMkvfY7iER+X3ryMEACfZPWg Cy2YfDy4XU9p5c3xG5IJN3g= =cAt1 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
