| Message ID | 1368010660-31465-4-git-send-email-jagarwal@nvidia.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On 05/08/2013 04:57 AM, Jay Agarwal wrote: > - Enable PCIe controller on Cardhu > - Only port 2 is connected on this board > - Add regulators required for Tegra30 > - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next > - and should be applied on top of this. > diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi > + pcie-controller { > + status = "okay"; > + pex-clk-supply = <&pex_hvdd_3v3_reg>; > + vdd-supply = <&ldo1_reg>; > + avdd-supply = <&ldo2_reg>; > + > + pci@3,0 { > + status = "okay"; > + }; > + }; So, if I apply this series, I do see the PCIe bridge and Ethernet device get enumerated, but I don't see the USB3 controller get enumerated. I believe that is a PCIe device behind the same bridge on the same Tegra PCIe port. Shouldn't this device show up? The Ethernet interface gets an IP address by DHCP, so some amount of data must be flowing. However, I cannot ping anything. If I run the same kernel on a Tegra20 TrimSlice board, which has the same Ethernet chip, then everything works as expected. Have you fully tested network connectivity with these patches applied? Perhaps this is related to the next problem: According to the Cardhu schematics, the PCIe link to the dock is a single lane. Hence, I believe that the Cardhu DT should describe a 411 port configuration. However, the Cardhu DT doesn't describe any particular link configuration, but just inherits the default from tegra30.dtsi, which describes a 222 link configuration. I would have expected the following in the Cardhu DT: pci@1,0 { nvidia,num-lanes = <4>; }; pci@2,0 { nvidia,num-lanes = <1>; }; pci@3,0 { status = "okay"; nvidia,num-lanes = <1>; }; However, if I put that there, no PCIe links are detected at all. Why does the driver work with the wrong link configuration, but fail with the correct one? Related, I notice that in Thierry's patches which you're building on, tegra_pcie_get_xbar_config() still has a bug where a zero return value is treated as an error, even though it's a valid HW register value. Perhaps this is related? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/08/2013 11:04 AM, Stephen Warren wrote: > On 05/08/2013 04:57 AM, Jay Agarwal wrote: >> - Enable PCIe controller on Cardhu >> - Only port 2 is connected on this board >> - Add regulators required for Tegra30 >> - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next >> - and should be applied on top of this. > >> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi > >> + pcie-controller { >> + status = "okay"; >> + pex-clk-supply = <&pex_hvdd_3v3_reg>; >> + vdd-supply = <&ldo1_reg>; >> + avdd-supply = <&ldo2_reg>; >> + >> + pci@3,0 { >> + status = "okay"; >> + }; >> + }; ... > According to the Cardhu schematics, the PCIe link to the dock is a > single lane. Hence, I believe that the Cardhu DT should describe a 411 > port configuration. However, the Cardhu DT doesn't describe any > particular link configuration, but just inherits the default from > tegra30.dtsi, which describes a 222 link configuration. I would have > expected the following in the Cardhu DT: > > pci@1,0 { > nvidia,num-lanes = <4>; > }; > > pci@2,0 { > nvidia,num-lanes = <1>; > }; > > pci@3,0 { > status = "okay"; > nvidia,num-lanes = <1>; > }; > > However, if I put that there, no PCIe links are detected at all. Why > does the driver work with the wrong link configuration, but fail with > the correct one? I take this back. Fixing the DT as shown above to represent the correct 4/1/1 configuration does still yield a working system. Please incorporate this into a future patch revision. The issue is more that PCIe enumeration is only reliable after a cold power cycle of the dock (the dock appears to be powered solely by its power cable and never the battery in Cardhu, and hence isn't affected by the main tablet PMIC's power on/off state like most of the board is). Is there some reset signal to the dock that the bootloader or kernel should be driving to solve this? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On 05/08/2013 04:57 AM, Jay Agarwal wrote: > > - Enable PCIe controller on Cardhu > > - Only port 2 is connected on this board > > - Add regulators required for Tegra30 > > - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next > > - and should be applied on top of this. > > > diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi > > b/arch/arm/boot/dts/tegra30-cardhu.dtsi > > > + pcie-controller { > > + status = "okay"; > > + pex-clk-supply = <&pex_hvdd_3v3_reg>; > > + vdd-supply = <&ldo1_reg>; > > + avdd-supply = <&ldo2_reg>; > > + > > + pci@3,0 { > > + status = "okay"; > > + }; > > + }; > > So, if I apply this series, I do see the PCIe bridge and Ethernet device get > enumerated, but I don't see the USB3 controller get enumerated. I believe > that is a PCIe device behind the same bridge on the same Tegra PCIe port. > Shouldn't this device show up? [>] I have also reproduced this problem. I see somehow no non-prefetchable memory is assigned to any of pcie devices. Probably that is the reason for USB3 (pci 0000:04:00.0) not getting enumerated since it uses only non-prefetchable memory. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > On 05/08/2013 04:57 AM, Jay Agarwal wrote: > > > - Enable PCIe controller on Cardhu > > > - Only port 2 is connected on this board > > > - Add regulators required for Tegra30 > > > - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next > > > - and should be applied on top of this. > > > > > diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi > > > b/arch/arm/boot/dts/tegra30-cardhu.dtsi > > > > > + pcie-controller { > > > + status = "okay"; > > > + pex-clk-supply = <&pex_hvdd_3v3_reg>; > > > + vdd-supply = <&ldo1_reg>; > > > + avdd-supply = <&ldo2_reg>; > > > + > > > + pci@3,0 { > > > + status = "okay"; > > > + }; > > > + }; > > > > So, if I apply this series, I do see the PCIe bridge and Ethernet > > device get enumerated, but I don't see the USB3 controller get > > enumerated. I believe that is a PCIe device behind the same bridge on the > same Tegra PCIe port. > > Shouldn't this device show up? > I have also reproduced this problem. I see somehow no non- > prefetchable memory is assigned to any of pcie devices. > Probably that is the reason for USB3 (pci 0000:04:00.0) not getting > enumerated since it uses only non-prefetchable memory. 1. Bus4(on which usb3 device resides) always return 0xffffffff from it's config space. which means device is not present? 2. That's why it is not assigned any resources and hence no usb3 probe happens. 3. But same bus does return valid info like vendor/device id etc from it's config space in downstream kernel and hence usb3 probe does happen. Thierry, Stephen, 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? Anything missing? 5. Also, how config space of all pcie devices are mapped? I mean if I change the config space offset in dts file, then also I find correct vendor/device id etc for bus0/device0/fun0. So how this mapping happens that even after changing the config space offset in PCIe address space, it always finds correct vendor/device id. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/17/2013 10:51 AM, Jay Agarwal wrote: >>> On 05/08/2013 04:57 AM, Jay Agarwal wrote: >>>> - Enable PCIe controller on Cardhu >>>> - Only port 2 is connected on this board >>>> - Add regulators required for Tegra30 >>>> - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next >>>> - and should be applied on top of this. ... >>> So, if I apply this series, I do see the PCIe bridge and Ethernet >>> device get enumerated, but I don't see the USB3 controller get >>> enumerated. I believe that is a PCIe device behind the same bridge on the >>> same Tegra PCIe port. >>> Shouldn't this device show up? >> >> I have also reproduced this problem. I see somehow no non- >> prefetchable memory is assigned to any of pcie devices. >> Probably that is the reason for USB3 (pci 0000:04:00.0) not getting >> enumerated since it uses only non-prefetchable memory. > > 1. Bus4(on which usb3 device resides) always return 0xffffffff from it's config space. which means device is not present? > 2. That's why it is not assigned any resources and hence no usb3 probe happens. > 3. But same bus does return valid info like vendor/device id etc from it's config space in downstream kernel and hence usb3 probe does happen. > > Thierry, Stephen, > 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? Anything missing? Is there some reset/enable GPIO or regulator that needs to be programmed to enable the PCIe USB3 controller? Take a look at the schematic. If you can make it work by tweaking those GPIOs/... manually, then we can ignore this issue and fix it up later, since it's not directly related to the PCIe controller driver patches. It's more important to get this Ethernet working than USB, I think. > 5. Also, how config space of all pcie devices are mapped? I mean if I change the config space offset in dts file, then also I find correct vendor/device id etc for bus0/device0/fun0. > So how this mapping happens that even after changing the config space offset in PCIe address space, it always finds correct vendor/device id. Can you please word-wrap your email less than 80 columns? It's quite hard to read. I don't quite understand your question. The PCIe driver implements the functions that access config space. I don't recall that being influenced by anything much in the device tree, except for the 3rd entry in the top-level PCIe controller's reg property: pcie-controller { compatible = "nvidia,tegra30-pcie"; device_type = "pci"; reg = <0x00003000 0x00000800 /* PADS registers */ 0x00003800 0x00000200 /* AFI registers */ 0x10000000 0x10000000>; /* configuration space */ -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > So, if I apply this series, I do see the PCIe bridge and Ethernet > > > device get enumerated, but I don't see the USB3 controller get > > > enumerated. I believe that is a PCIe device behind the same bridge > > > on the > > same Tegra PCIe port. > > > Shouldn't this device show up? > > I have also reproduced this problem. I see somehow no non- > > prefetchable memory is assigned to any of pcie devices. > > Probably that is the reason for USB3 (pci 0000:04:00.0) not getting > > enumerated since it uses only non-prefetchable memory. > > 1. Bus4(on which usb3 device resides) always return 0xffffffff from it's > config space. which means device is not present? > 2. That's why it is not assigned any resources and hence no usb3 probe > happens. > 3. But same bus does return valid info like vendor/device id etc from it's > config space in downstream kernel and hence usb3 probe does happen. > > Thierry, Stephen, > 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? > Anything missing? > 5. Also, how config space of all pcie devices are mapped? I mean if I change > the config space offset in dts file, then also I find correct vendor/device id > etc for bus0/device0/fun0. > So how this mapping happens that even after changing the config space > offset in PCIe address space, it always finds correct vendor/device id. Any idea on this? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/29/2013 04:10 AM, Jay Agarwal wrote: >>>> So, if I apply this series, I do see the PCIe bridge and Ethernet >>>> device get enumerated, but I don't see the USB3 controller get >>>> enumerated. I believe that is a PCIe device behind the same bridge >>>> on the >>> same Tegra PCIe port. >>>> Shouldn't this device show up? >>> I have also reproduced this problem. I see somehow no non- >>> prefetchable memory is assigned to any of pcie devices. >>> Probably that is the reason for USB3 (pci 0000:04:00.0) not getting >>> enumerated since it uses only non-prefetchable memory. >> >> 1. Bus4(on which usb3 device resides) always return 0xffffffff from it's >> config space. which means device is not present? >> 2. That's why it is not assigned any resources and hence no usb3 probe >> happens. >> 3. But same bus does return valid info like vendor/device id etc from it's >> config space in downstream kernel and hence usb3 probe does happen. >> >> Thierry, Stephen, >> 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? >> Anything missing? >> 5. Also, how config space of all pcie devices are mapped? I mean if I change >> the config space offset in dts file, then also I find correct vendor/device id >> etc for bus0/device0/fun0. >> So how this mapping happens that even after changing the config space >> offset in PCIe address space, it always finds correct vendor/device id. > > Any idea on this? I did already reply the same day you sent the original email. My response was: Is there some reset/enable GPIO or regulator that needs to be programmed to enable the PCIe USB3 controller? Take a look at the schematic. If you can make it work by tweaking those GPIOs/... manually, then we can ignore this issue and fix it up later, since it's not directly related to the PCIe controller driver patches. It's more important to get the Ethernet working than USB, I think. To be honest though, I would expect you to be asking around inside NVIDIA to determine the answer here. As the PCIe SW expert, I'd expect you to drive this process. Try asking the Cardhu board and PCIe HW experts within NVIDIA. Did you make any progress on the issues with the Ethernet device? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On 05/29/2013 04:10 AM, Jay Agarwal wrote: > >>>> So, if I apply this series, I do see the PCIe bridge and Ethernet > >>>> device get enumerated, but I don't see the USB3 controller get > >>>> enumerated. I believe that is a PCIe device behind the same bridge > >>>> on the > >>> same Tegra PCIe port. > >>>> Shouldn't this device show up? > >>> I have also reproduced this problem. I see somehow no non- > >>> prefetchable memory is assigned to any of pcie devices. > >>> Probably that is the reason for USB3 (pci 0000:04:00.0) not getting > >>> enumerated since it uses only non-prefetchable memory. > >> > >> 1. Bus4(on which usb3 device resides) always return 0xffffffff from > >> it's config space. which means device is not present? > >> 2. That's why it is not assigned any resources and hence no usb3 > >> probe happens. > >> 3. But same bus does return valid info like vendor/device id etc from > >> it's config space in downstream kernel and hence usb3 probe does > happen. > >> > >> Thierry, Stephen, > >> 4. Any idea why bus4 should return 0xffffffff values in upstream kernel? > >> Anything missing? > >> 5. Also, how config space of all pcie devices are mapped? I mean if I > >> change the config space offset in dts file, then also I find correct > >> vendor/device id etc for bus0/device0/fun0. > >> So how this mapping happens that even after changing the config > >> space offset in PCIe address space, it always finds correct vendor/device > id. > > > > Any idea on this? > > I did already reply the same day you sent the original email. My response > was: > > Is there some reset/enable GPIO or regulator that needs to be programmed > to enable the PCIe USB3 controller? Take a look at the schematic. If you can > make it work by tweaking those GPIOs/... manually, then we can ignore this > issue and fix it up later, since it's not directly related to the PCIe controller > driver patches. It's more important to get the Ethernet working than USB, I > think. > > To be honest though, I would expect you to be asking around inside NVIDIA > to determine the answer here. As the PCIe SW expert, I'd expect you to > drive this process. Try asking the Cardhu board and PCIe HW experts within > NVIDIA. > > Did you make any progress on the issues with the Ethernet device? Stephen, I have taken care of all your comments, but Ethernet device is not working for me neither on cardhu nor harmony. Could be related to my process or board, Currently debugging this. Parallely, should I push my patches for review so that it is clear from other aspects? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/30/2013 11:37 AM, Jay Agarwal wrote: ... > I have taken care of all your comments, but Ethernet device is not working for me neither on cardhu nor harmony. > Could be related to my process or board, Currently debugging this. Are you talking about a PCIe-based Ethernet device on Harmony, or the one that's built into the board? The on-board Ethernet device is USB, and should work fine already, and irrespective of any PCIe patches. I have only tried an XHCI USB controller in the PCIe slot on Harmony, so I can't say if Ethernet not working is a regression or not. Does the Ethernet device work with just Thierry's patches and not yours? > Parallely, should I push my patches for review so that it is clear from other aspects? Well, if the patches don't work, I suppose there's not much use posting them since they'll just need changes before they can be usefully applied anyway. IIRC, most of my comments last time were fairly minor, so there isn't much need for a separate review of them, right? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
<Forwarding to bigger aliases> Anybody aware of hang in r8169 driver over pcie interface mentioned at bottom of this mail? -----Original Message----- From: Jay Agarwal Sent: Tuesday, June 04, 2013 7:17 PM To: 'Stephen Warren' Cc: 'thierry.reding@avionic-design.de' Subject: RE: [PATCH 4/4] ARM: tegra: pcie: Enable PCIe controller on Cardhu > > > > > On 05/31/2013 06:17 AM, Jay Agarwal wrote: > > > > > >>> I have taken care of all your comments, but Ethernet > > > > > >>> device is not working > > > > > >> for me neither on cardhu nor harmony. > > > > > >>> Could be related to my process or board, Currently > > > > > >>> debugging > this. > > > > > >> > > > > > >> Are you talking about a PCIe-based Ethernet device on > > > > > >> Harmony, or the one that's built into the board? > > > > > >> > > > > > >> The on-board Ethernet device is USB, and should work fine > > > > > >> already, and irrespective of any PCIe patches. > > > > > > > > > > > > No I am talking about ethernet over PCIe interface. There > > > > > > is no problem > > > > > with built-in ethernet over USB. > > > > > > > > > > > >> I have only tried an XHCI USB controller in the PCIe slot > > > > > >> on Harmony, so I can't say if Ethernet not working is a > > > > > >> regression or not. Does the Ethernet device work with just > > > > > >> Thierry's patches and not > > > > yours? > > > > > > > > > > > > It does not work w/o any of my patches also. > > > > > > > > > > > > Thierry, > > > > > > Have you verified any ethernet card working on harmony? > > > > > > I am using Broadcom Ethernet card with TIGON3 driver, but it > > > > > > does not > > > > > work although PCIe enumeration and driver probe looks fine as > > > attached. > > > > > > Any idea? > > > > > > > > > > Oh, one thing to consider here: PCIe interrupts don't work > > > > > correctly when > > > > > LP2 is enabled, at least in the upstream kernel. It's > > > > > something I've been trying to investigate, but haven't tracked down yet. > > > > > > > > > > Anyway, you need to disable the LP2 CPU power management state > > > > > for sure. > > > > > Hopefully this will solve the issue for you. One way to do > > > > > this is the following patch, although we need a better > > > > > solution before we can actually merge anything: > > > > > > > > > > https://patchwork.kernel.org/patch/2525151/ > > > > Stephen, > > > > This patch also did not resolve the issue although I do get > > > > "Disabling > > > > LP2 cpuidle state..." message in logs. > > > > > > It stucks as below: > > > > > > root@localhost:~# dhclient eth0 > > > [ 1444.579544] smsc95xx 3-1.1:1.0 eth0: hardware isn't capable of > > > remote wakeup [ 1444.587300] IPv6: ADDRCONF(NETDEV_UP): eth0: link > > > is not ready > > > > My system does not have ping command, so dhclient fails like below: > > /sbin/dhclient-script: line 325: ping: command not found > > > > So I provided static IP as : ifconfig eth0 <IP> but it also did not help. > > Actually sorry, I was using wrong Ethernet interface(eth0) on > harmony, but correct one is eth1(over pcie interface) which works fine > on Thierry's repo after applying patches to disable LP2. > Now I will try after applying my patches on both harmony and cardhu. Ethernet is working on harmony is working w/ & a/o my patches but cardhu is hanging as below: root@localhost:~# ifconfig eth0 10.19.65.115 [ 102.525245] r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2) [ 102.951516] r8169 0000:03:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25). <System hangs here..> 1. Harmony is using Broadcom pcie Ethernet card and cardhu is using realtek one. 2. Enumeration and lspci seems to be fine though. 3. I tried applying similar patches for disabling LP2 for tegra 3 as well but it did not help. 4. Any idea/opinion? -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi index d2fdf95..8f8e07b 100644 --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi @@ -27,6 +27,17 @@ model = "NVIDIA Tegra30 Cardhu evaluation board"; compatible = "nvidia,cardhu", "nvidia,tegra30"; + pcie-controller { + status = "okay"; + pex-clk-supply = <&pex_hvdd_3v3_reg>; + vdd-supply = <&ldo1_reg>; + avdd-supply = <&ldo2_reg>; + + pci@3,0 { + status = "okay"; + }; + }; + host1x { dc@54200000 { rgb {
- Enable PCIe controller on Cardhu - Only port 2 is connected on this board - Add regulators required for Tegra30 - Patch is based on remotes/gitorious_thierryreding_linux/tegra/next - and should be applied on top of this. Signed-off-by: Jay Agarwal <jagarwal@nvidia.com> --- arch/arm/boot/dts/tegra30-cardhu.dtsi | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)