On Wed, Dec 4, 2013 at 10:00 AM, Jagan Teki <jagannadh.teki@xxxxxxxxx> wrote: > On Wed, Dec 4, 2013 at 8:41 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> On Tue, Dec 3, 2013 at 11:20 PM, Jagan Teki <jagannadh.teki@xxxxxxxxx> wrote: >>> Thanks for your quick response. >>> Please find my comments below. >>> >>> On Tue, Dec 3, 2013 at 11:09 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >>>> On Tue, Dec 3, 2013 at 4:24 AM, Jagan Teki <jagannadh.teki@xxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> I have few question on Linux PCIe subsystem, I am trying to understand >>>>> the PCIe on ARM platform. >>>>> 1. Compared to PCI, PCIe have an extra port functionalists/services >>>>> which is implemented drivers/pci/pcie/* is it true? >>>> >>>> Yes. >>>> >>>>> 2. PCIe root complex is same as Host controller drivers in linux drivers/host/* >>>> >>>> Yes. >>>> >>>>> 3. As individual endpoint drivers are registered to pci_core as >>>>> pci_driver_register, then what is the common call for registering >>>>> individual HC driver to pci-core? >>>> >>>> The host controller-PCI core interface is not as mature as the >>>> pci_register_driver() interface. The basic interface is >>>> pci_scan_root_bus(). If you skim through the drivers in >>>> drivers/pci/host/* and drivers/acpi/pci_root.c, the interface to the >>>> PCI core will be fairly obvious. And you'll learn what the existing >>>> practices are in case you need to add or modify something. >>> >>> OK. >>> >>> I understand the flow as below - please correct if am wrong. >>> >>> From low level (hw) - HC driver has a platform registration using >>> platform_driver_register() to lower layer >>> and then pci_scan_root_bus() --> pci_common_init_dev() registration to >>> upper layer as PCI - BIOS and then ends. >> >> Yes. Sometime HC drivers use platform_driver_register(); other use >> something else depending on how the HC device is enumerated. For >> example, drivers/acpi/pci_root.c uses something else to deal with host >> bridges in the ACPI namespace. >> >>> From upper level (app) - each endpoint driver has >>> pci_driver_register() call to PCI Core for lower level >> >> Yes. >> >>> and then the upper level registration is based on endpoint(). >> >> I don't know what you mean here (I don't know of a function named >> "endpoint()"). But the driver model matches drivers to PCI functions >> based on vendor and device IDs. A Linux "pci_dev" is what the PCI >> specs refer to as a "function." > Sorry it's typo - added () > >> >>> What is the connection here for PCI-BIOS and PCI-Core here, does these >>> are two different entities means there is no common call for these? >>> I see for ARM - "arch/arm/kernel/bios32.c" is PCI-BIOS is it correct? >>> does we have separate BIOS codes for architectures? >> >> The "pcibios_*" functions are architecture-specific things called by >> the generic PCI core. Generally, things specified by the PCI specs >> are architecture-independent and should be in the PCI core >> (drivers/pci/*). > > I have some good information to discuss from this thread. > Can you please verify this Linux PCIe subsystem stack - comment > whether my understanding is correct/not. > (I just draw this based on driver calls flow - to accommodate with in > the Linux cores) > http://jagannadhteki.blog.com/2013/12/04/linux-pcie-subsystem/ Yes, that makes sense. I wouldn't label the PCIBIOS - PCI core link as "pci_bus_add_device()"; pci_bus_add_device() is part of the PCI core's generic enumeration code and shouldn't be called by arch-specific code. The link going from PCI core to PCIBIOS is the set of "pcibios_*()" functions. Going from PCIBIOS to the PCI core, it's mostly just pci_scan_root_bus(). I also probably wouldn't put in links between VFS and AER, HP, PME, and VC. It's true that there are some sysfs files that influence the operation of those PCIe features, but mostly for debugging and administration. They aren't something useful to ordinary user programs. Bjorn -- 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
