Re: [PATCH 8/8] ARM: shmobile: henninger: Add dummy PCIe bus clock

[Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>]

On 06/17/2014 11:41 AM, Phil Edworthy wrote:

>>>>>>> Since the CPU's dtsi refers to pcie_bus_clock, we need an entry in
>>>>>>> the board's dts, even if we aren't using PCIe.

>>>>>>       I don't quite understand that last part: there's PCIe slot in the
>>>>>> Henninger's schematics (although it doesn't seem to be soldered in the
>>>>>> early board version).

>>>>>    In fact, we're in process of verifying PCIe on Henninger (soldered the
>>>>> connector); at least the configuration space accesses work OK...

>>>> Do you mean the internal Root-Complex config accesses work ok, or card
>>>> ones?

>>>      We inserted an Intel Wi-Fi card and saw PCI-PCI bridge and network
>>> controller in lspci's output. Another (Ethernet) card didn't work though...

    We have found firmware for the Intel Centrino card (it only has BARs in 
the memory space), it loaded successfully but WLAN interface failed to come up 
anyway:

root@10.0.0.111:~# ifconfig wlan0 11.0.0.2
iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S
iwlwifi 0000:01:00.0: Radio type=0x2-0x1-0x0
iwlwifi 0000:01:00.0: Failed to load firmware chunk!
iwlwifi 0000:01:00.0: Could not load the [0] uCode section
iwlwifi 0000:01:00.0: Failed to run INIT ucode: -110
iwlwifi 0000:01:00.0: Unable to initialize device.
SIOCSIFFLAGS: Connection timed out

    So I wanted to ask: how did you test PCIe?

>>      That PCI-PCI bridge has ID 1912:001f which corresponds to Renesas. I guess
>> it's a part of the PCIe controller and then I wonder why this device is not
>> seen when no card is inserted...

> Simply because the hardware does not support hot plug. So, during probe the driver checks for link up, and if so it will call pci_common_init_dev().

    Not sure how it's connected, could you elaborate?
    And you don't indicate probe error when there's no link anyway -- which is 
strange.
    As I already said, the PCI-PCI bridge's space doesn't look correct:

root@10.0.0.111:~# lspci -v
00:00.0 PCI bridge: Unknown device 1912:001f (prog-if 00 [Normal decode])
         Flags: bus master, fast devsel, latency 0
         Bus: primary\0, secondary\x01, subordinate\x01, sec-latency=0
         I/O behind bridge: 00000000-00000fff
         Memory behind bridge: 00000000-000fffff
         Prefetchable memory behind bridge: 00000000-000fffff
         Capabilities: [40] Power Management version 3
         Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0
Enable+
         Capabilities: [70] Express Root Port (Slot-) IRQ 0
         Capabilities: [100] Virtual Channel
         Capabilities: [1b0] Device Serial Number 00-00-00-00-00-00-00-00

01:00.0 Network controller: Intel Corporation Unknown device 088e (rev 24)
         Subsystem: Intel Corporation Unknown device 4060
         Flags: bus master, fast devsel, latency 0, IRQ 418
         Memory at fe200000 (64-bit, non-prefetchable) [size=8K]
         Capabilities: [c8] Power Management version 3
         Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable+
         Capabilities: [e0] Express Endpoint IRQ 0
         Capabilities: [100] Advanced Error Reporting
         Capabilities: [140] Device Serial Number cf-9c-3e-ff-ff-87-d9-c4

    The memory behind bridge should include the 0xfe2000000 address in card's 
BAR0 but it doesn't... I/O and prefetchable memory behind bridge also don't 
look right. The strange thing is the kernel reassigns the memory behind 
bridge's range but never writes it back into the PCI-PCI bridge:

pcieport 0000:00:00.0: BAR 8: assigned [mem 0xfe200000-0xfe2fffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xfe200000-0xfe201fff 64bit]

> Regards
> Phil

WBR, Sergei