Hi Matthew, thanks for your answers some aspects are not completely clear to me yet, especially for Root Complex device, but I have just started on these topics Stefano 2009/8/26 Matthew Wilcox <matthew@xxxxxx>: > On Wed, Aug 26, 2009 at 05:09:28PM +0200, Stefano Tebaldi wrote: >> Hi all, >> >> I am quite newbie about PCIe and Linux Kernel development >> I have to write a driver for a PCIe chip that can act either as >> EndPoint or Root Complex device >> The chip is on a board with an ARM processor and Linux 2.6 > > I think what you're trying to say here is that from the point of view > of the host system, it's an endpoint, but from the point of view of the > ARM processor, it's a Root Complex. Is that correct? > >> I have understood that for a PCIe endpoint the driver model to be used >> is the normal PCI driver model that uses pci_register_driver() API and >> pci_driver struct for example as described in >> linux/Documentation/PCI/pci.txt. A possible example of such type of >> driver is the e1000e driver in linux/drivers/net >> is it correct ? > > That's correct. > >> My doubts are related to drivers for a Root Complex device. In this >> case I have understood that the model described in >> linux/Documentation/PCI/PCIEBUS-HOWTO.txt is to be used and service >> drivers for the 4 services (AER, HP, PME, VC) are to be written if >> needed. But is providing only service drivers enough to completely >> manage a Root Complex device or something else is needed ? Is there a >> Root Complex driver that anyone can use as example ? > > You generally don't need to write drivers for a Root Complex. You may > need to discover it using whatever mechanism the ARM platform provides > for discovering devices. You might need to write code to translate inb() > into IO port cycles on the PCI bus and writeb() into memory cycles. > I would recommend that you _not_ do PCI config cycles; Linux doesn't > handle multiple root complexes in a system particularly well -- if you try > to resize BARs on an active device, you're likely to crash the machine. > > It's probably best to ignore the RC functionality, and concentrate on > having your ARM board be just an endpoint. > > If you want to get really advanced, you could look at having some way > of partitioning the devices between the host board and the ARM board, > but I'm not sure that the hardware in the PCIe fabric is going to handle > having multiple root complexes terribly well. > > -- > Matthew Wilcox Intel Open Source Technology Centre > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html