lkml.org 
[lkml]   [2013]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Need help on Linux PCIe
From
On Thu, Dec 5, 2013 at 11:45 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Wed, Dec 4, 2013 at 11:30 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>> On Wed, Dec 4, 2013 at 11:35 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>> On Wed, Dec 4, 2013 at 10:00 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>> On Wed, Dec 4, 2013 at 8:41 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>>> On Tue, Dec 3, 2013 at 11:20 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>>>>>> Thanks for your quick response.
>>>>>> Please find my comments below.
>>>>>>
>>>>>> On Tue, Dec 3, 2013 at 11:09 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>>>>> On Tue, Dec 3, 2013 at 4:24 AM, Jagan Teki <jagannadh.teki@gmail.com> 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@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki


\
 
 \ /
  Last update: 2013-12-05 20:01    [W:0.046 / U:2.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site