Re: Need help on Linux PCIe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 5, 2013 at 11:45 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> On Wed, Dec 4, 2013 at 11:30 PM, Jagan Teki <jagannadh.teki@xxxxxxxxx> wrote:
>> On Wed, Dec 4, 2013 at 11:35 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>>> 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().
>> Yes - understand your point.
>> I made few changes accordingly.
>> http://jagannadhteki.blog.com/files/2013/12/Linux_PCIe_zynq.png
>
> Why did you keep the pci_bus_add_device() label?  There are no calls
> from arch code.  The only calls from outside the PCI core are from
Yes.. from ARM I see pci_bus_add_devices() call from BIOS code -
arch/arm/kernel/bios32
to a defination of pci core side.

As it's a last call from pci_common_init_dev() - which actually called
from HC driver.

Correct me if am wrong.

> i82875p_setup_overfl_dev(), asus_rfkill_hotplug(), and
> eeepc_rfkill_hotplug().  These are all hacks that should not be
> emulated.

-- 
Thanks,
Jagan.
--------
Jagannadha Sutradharudu Teki,
E: jagannadh.teki@xxxxxxxxx, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
--
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




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux