Hi again, I have clarified possible scenarios related to the board I told about in my previous posts: 1) the PCIe on the board can act as PCIe Root Complex. In this scenario I can plug several PCIe devices that will act as PCIe Endpoint. From the Linux and PCIe driver point of view the activities I am supposed to do are Linux porting for the ARM processor including its PCIe support and already present Root Complex driver (pcieport-driver, linux/drivers/pci/pcie). On this Root Complex driver I could have to do some kind of customing activity (I guess) could you confirm what I said please ? 2) the PCIe on the board can act as PCIe Endpoint. In this case it will be connected for example to a PC acting as Root Complex. Here, I have to write the driver for a specific OSs PC for my board. This is a typical PCIe Endpoint driver could you confirm also this point ? thanks a lot in advance Stefano 2009/8/28 Stefano Tebaldi <steteb@xxxxxxxxx>: > 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
