From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Shtylyov Date: Thu, 19 Jun 2014 22:02:22 +0000 Subject: Re: [PATCH 8/8] ARM: shmobile: henninger: Add dummy PCIe bus clock Message-Id: <53A35DEE.2080201@cogentembedded.com> List-Id: References: <1401261843-6964-9-git-send-email-phil.edworthy@renesas.com> In-Reply-To: <1401261843-6964-9-git-send-email-phil.edworthy@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org 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, secondary, subordinate, 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