| Message ID | 20170612122202.3379-26-sjg@chromium.org |
|---|---|
| State | Accepted |
| Delegated to: | Simon Glass |
| Headers | show |
Update the tegra pci driver to support a live device tree. Fix the check
for nvidia,num-lanes so that an error will actually be detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Add new patch to convert tegra PCI to device tree
Changes in v2: None
drivers/pci/pci_tegra.c | 53 ++++++++++++++++++++++---------------------------
1 file changed, 24 insertions(+), 29 deletions(-)
Applied to u-boot-dm, thanks!
On 07/06/2017 11:36 AM, sjg@google.com wrote: > Update the tegra pci driver to support a live device tree. Fix the check > for nvidia,num-lanes so that an error will actually be detected. Simon, Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test simply fails due to lack of any Ethernet adapter. I don't see any errors during either boot or the network test setup scripts, which include "pci enum": TK1 (built-in RTL8169 PCI Ethernet): Tegra124 (Jetson TK1) # ping $serverip No ethernet found. ping failed; host 192.168.100.1 is not alive Tegra124 (Jetson TK1) # TX1 (add-on RTL8169 PCI Ethernet): Tegra210 (P2371-2180) # pci enum ERROR: tegra-pcie: failed to power on PHY: -110 at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller() ERROR: tegra-pcie: failed to enable controller at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe() Tegra210 (P2371-2180) # setenv autoload no Tegra210 (P2371-2180) # dhcp No ethernet found. Tegra210 (P2371-2180) # I also retested u-boot/master to make sure there's no test system infrastructure issue (that branch passes), and re-ran the failing test 3 times on TK1 with identical results. Other Tegra boards that I test all seem fine, at least as far as passing test/py. P.S. I'll be away next week and the week after. Tom Warren may be able to monitor the test system emails, but I don't think I've set him up with access to e.g. retrigger tests etc.; perhaps I should look into that...
Hi Stephen, On 6 July 2017 at 12:55, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 07/06/2017 11:36 AM, sjg@google.com wrote: >> >> Update the tegra pci driver to support a live device tree. Fix the check >> for nvidia,num-lanes so that an error will actually be detected. > > > Simon, > > Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test simply fails due to lack of any Ethernet adapter. I don't see any errors during either boot or the network test setup scripts, which include "pci enum": > > TK1 (built-in RTL8169 PCI Ethernet): > Tegra124 (Jetson TK1) # ping $serverip > No ethernet found. > ping failed; host 192.168.100.1 is not alive > Tegra124 (Jetson TK1) # > > TX1 (add-on RTL8169 PCI Ethernet): > Tegra210 (P2371-2180) # pci enum > ERROR: tegra-pcie: failed to power on PHY: -110 > at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller() > ERROR: tegra-pcie: failed to enable controller > at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe() > Tegra210 (P2371-2180) # setenv autoload no > Tegra210 (P2371-2180) # dhcp > No ethernet found. > Tegra210 (P2371-2180) # > > I also retested u-boot/master to make sure there's no test system infrastructure issue (that branch passes), and re-ran the failing test 3 times on TK1 with identical results. Other Tegra boards that I test all seem fine, at least as far as passing test/py. > > P.S. I'll be away next week and the week after. Tom Warren may be able to monitor the test system emails, but I don't think I've set him up with access to e.g. retrigger tests etc.; perhaps I should look into that... As mentioned elsewhere that error (failing to power on PHY) happens for me always on my TK1 (and has for about a year) because it seems to have a broken PMIC. I do have a TX1 somewhere but cannot find it despite much searching. Obviously I chose Tegra for the livetree work based on Nyan which I have and which is quick to develop on. I am beginning to regret this because: - No one at Nvidia appears to be maintaining the code at present - e.g. DM enablement, Kconfig versions - The test report you provides is a signal, but it is not actionable for me - As above due to broken/lost boards I am not able to test as well as I originally thought Is there any way someone at Nvidia could jump into this and work on bringing mainline up to scratch? Regards, Simon
On 07/06/2017 09:57 PM, Simon Glass wrote: > Hi Stephen, > > On 6 July 2017 at 12:55, Stephen Warren <swarren@wwwdotorg.org> wrote: >> >> On 07/06/2017 11:36 AM, sjg@google.com wrote: >>> >>> Update the tegra pci driver to support a live device tree. Fix the check >>> for nvidia,num-lanes so that an error will actually be detected. >> >> >> Simon, >> >> Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test simply fails due to lack of any Ethernet adapter. I don't see any errors during either boot or the network test setup scripts, which include "pci enum": >> >> TK1 (built-in RTL8169 PCI Ethernet): >> Tegra124 (Jetson TK1) # ping $serverip >> No ethernet found. >> ping failed; host 192.168.100.1 is not alive >> Tegra124 (Jetson TK1) # >> >> TX1 (add-on RTL8169 PCI Ethernet): >> Tegra210 (P2371-2180) # pci enum >> ERROR: tegra-pcie: failed to power on PHY: -110 >> at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller() >> ERROR: tegra-pcie: failed to enable controller >> at /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe() >> Tegra210 (P2371-2180) # setenv autoload no >> Tegra210 (P2371-2180) # dhcp >> No ethernet found. >> Tegra210 (P2371-2180) # >> >> I also retested u-boot/master to make sure there's no test system infrastructure issue (that branch passes), and re-ran the failing test 3 times on TK1 with identical results. Other Tegra boards that I test all seem fine, at least as far as passing test/py. >> >> P.S. I'll be away next week and the week after. Tom Warren may be able to monitor the test system emails, but I don't think I've set him up with access to e.g. retrigger tests etc.; perhaps I should look into that... > > As mentioned elsewhere that error (failing to power on PHY) happens > for me always on my TK1 (and has for about a year) because it seems to > have a broken PMIC. I do have a TX1 somewhere but cannot find it > despite much searching. I'm very puzzled that you claim your TK1 always has this issue; this issue is clearly not present in mainline U-Boot (unless it's very intermittent and my test system has got lucky, but it's very reproducible so I don't think so), and I don't believe there's anything in the the PMIC that can be altered permanently; the boot configuration is in OTP (One Time Programmable) memory (fuses?) and can't be changed. Are you absolutely 100% sure that you cleanly replaced your development version of U-Boot correctly and tested with a 100% unmodified mainline U-Boot? Also, please try (a) flashing unmodified mainline U-Boot (b) disconnecting EVERY cable from the TK1 and leaving it that way for 10 minutes to drain any capacitors (or perhaps even overnight) (c) powering up to see if any problems still exist. > Obviously I chose Tegra for the livetree work based on Nyan which I > have and which is quick to develop on. I am beginning to regret this > because: > > - No one at Nvidia appears to be maintaining the code at present - > e.g. DM enablement, Kconfig versions Well, the existing code works perfectly. There's no need to change it. If you want to change it, that's fine, but you must take on the job of validating your changes and fixing any issues they introduce. It's not reasonable to introduce changes that break things and then try and push forward with them even in the face of known breakage caused by those changes. It's not reasonable to create patches that introduce problems and then expect others to do the work of debugging and fixing them. > - The test report you provides is a signal, but it is not actionable for me Why is it not actionable? You possess hardware that will reproduce the change (your TX1 board even if not the TK1 system). The test system source is checked into the U-Boot source tree and available to you, although I believe that simply running "pci enum; dhcp Image" should reproduce the problem so it's even simpler than running test/py. > - As above due to broken/lost boards I am not able to test as well as > I originally thought Perhaps you should only modify the boards you can test? You mentioned that Nyan works for you. If so, limit the modifications to the boards/drivers/features you have available. > Is there any way someone at Nvidia could jump into this and work on > bringing mainline up to scratch? If anyone can, it'd be Tom Warren. P.S. I'm on vacation for the next 2 weeks, so won't be able to respond further for a while.
Hi Stephen, On 7 July 2017 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/06/2017 09:57 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 6 July 2017 at 12:55, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> >>> On 07/06/2017 11:36 AM, sjg@google.com wrote: >>>> >>>> >>>> Update the tegra pci driver to support a live device tree. Fix the check >>>> for nvidia,num-lanes so that an error will actually be detected. >>> >>> >>> >>> Simon, >>> >>> Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on >>> Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test >>> simply fails due to lack of any Ethernet adapter. I don't see any errors >>> during either boot or the network test setup scripts, which include "pci >>> enum": >>> >>> TK1 (built-in RTL8169 PCI Ethernet): >>> Tegra124 (Jetson TK1) # ping $serverip >>> No ethernet found. >>> ping failed; host 192.168.100.1 is not alive >>> Tegra124 (Jetson TK1) # >>> >>> TX1 (add-on RTL8169 PCI Ethernet): >>> Tegra210 (P2371-2180) # pci enum >>> ERROR: tegra-pcie: failed to power on PHY: -110 >>> at >>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller() >>> ERROR: tegra-pcie: failed to enable controller >>> at >>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe() >>> Tegra210 (P2371-2180) # setenv autoload no >>> Tegra210 (P2371-2180) # dhcp >>> No ethernet found. >>> Tegra210 (P2371-2180) # >>> >>> I also retested u-boot/master to make sure there's no test system >>> infrastructure issue (that branch passes), and re-ran the failing test 3 >>> times on TK1 with identical results. Other Tegra boards that I test all seem >>> fine, at least as far as passing test/py. >>> >>> P.S. I'll be away next week and the week after. Tom Warren may be able to >>> monitor the test system emails, but I don't think I've set him up with >>> access to e.g. retrigger tests etc.; perhaps I should look into that... >> >> >> As mentioned elsewhere that error (failing to power on PHY) happens >> for me always on my TK1 (and has for about a year) because it seems to >> have a broken PMIC. I do have a TX1 somewhere but cannot find it >> despite much searching. > > > I'm very puzzled that you claim your TK1 always has this issue; this issue > is clearly not present in mainline U-Boot (unless it's very intermittent and > my test system has got lucky, but it's very reproducible so I don't think > so), and I don't believe there's anything in the the PMIC that can be > altered permanently; the boot configuration is in OTP (One Time > Programmable) memory (fuses?) and can't be changed. Are you absolutely 100% > sure that you cleanly replaced your development version of U-Boot correctly > and tested with a 100% unmodified mainline U-Boot? Also, please try (a) > flashing unmodified mainline U-Boot (b) disconnecting EVERY cable from the > TK1 and leaving it that way for 10 minutes to drain any capacitors (or > perhaps even overnight) (c) powering up to see if any problems still exist. I have tried to explain this quite a few times. My TK1 has some sort of power problem. I think it is due to my overwriting the PMIC registers with invalid values during some I2C testing a while back. I'll try what you suggest, although I do generally leave it powered off between use. > >> Obviously I chose Tegra for the livetree work based on Nyan which I >> have and which is quick to develop on. I am beginning to regret this >> because: >> >> - No one at Nvidia appears to be maintaining the code at present - >> e.g. DM enablement, Kconfig versions > > > Well, the existing code works perfectly. There's no need to change it. If > you want to change it, that's fine, but you must take on the job of > validating your changes and fixing any issues they introduce. It's not > reasonable to introduce changes that break things and then try and push > forward with them even in the face of known breakage caused by those > changes. It's not reasonable to create patches that introduce problems and > then expect others to do the work of debugging and fixing them. That's a different point. Please see the point I made above. Kconfig conversion needs to be completed by the end of this year [1] and DM conversion needs to be done at some point (no specific deadline). > >> - The test report you provides is a signal, but it is not actionable for >> me > > > Why is it not actionable? You possess hardware that will reproduce the > change (your TX1 board even if not the TK1 system). The test system source > is checked into the U-Boot source tree and available to you, although I > believe that simply running "pci enum; dhcp Image" should reproduce the > problem so it's even simpler than running test/py. I have this morning found the TX1 board so hopefully can figure this out! > >> - As above due to broken/lost boards I am not able to test as well as >> I originally thought > > > Perhaps you should only modify the boards you can test? You mentioned that > Nyan works for you. If so, limit the modifications to the > boards/drivers/features you have available. Yes that was my original series, but Nyan does not have PCI. > >> Is there any way someone at Nvidia could jump into this and work on >> bringing mainline up to scratch? > > > If anyone can, it'd be Tom Warren. > > P.S. I'm on vacation for the next 2 weeks, so won't be able to respond > further for a while. Have a nice break. Regards, Simon [1] https://lists.denx.de/pipermail/u-boot/2017-January/277605.html
On Fri, Jul 7, 2017 at 4:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 07/06/2017 09:57 PM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 6 July 2017 at 12:55, Stephen Warren <swarren@wwwdotorg.org> wrote: >>> >>> >>> On 07/06/2017 11:36 AM, sjg@google.com wrote: >>>> >>>> >>>> Update the tegra pci driver to support a live device tree. Fix the check >>>> for nvidia,num-lanes so that an error will actually be detected. >>> >>> >>> >>> Simon, >>> >>> Something in the latest u-boot-dm/master branch breaks PCI or Ethernet on >>> Jeton TK1 and TX1. I don't know which patch it is. test/py's ping test >>> simply fails due to lack of any Ethernet adapter. I don't see any errors >>> during either boot or the network test setup scripts, which include "pci >>> enum": >>> >>> TK1 (built-in RTL8169 PCI Ethernet): >>> Tegra124 (Jetson TK1) # ping $serverip >>> No ethernet found. >>> ping failed; host 192.168.100.1 is not alive >>> Tegra124 (Jetson TK1) # >>> >>> TX1 (add-on RTL8169 PCI Ethernet): >>> Tegra210 (P2371-2180) # pci enum >>> ERROR: tegra-pcie: failed to power on PHY: -110 >>> at >>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:774/tegra_pcie_enable_controller() >>> ERROR: tegra-pcie: failed to enable controller >>> at >>> /var/lib/jenkins/workspace/u-boot-denx_uboot_dm-master-build/src/u-boot/drivers/pci/pci_tegra.c:1154/pci_tegra_probe() >>> Tegra210 (P2371-2180) # setenv autoload no >>> Tegra210 (P2371-2180) # dhcp >>> No ethernet found. >>> Tegra210 (P2371-2180) # >>> >>> I also retested u-boot/master to make sure there's no test system >>> infrastructure issue (that branch passes), and re-ran the failing test 3 >>> times on TK1 with identical results. Other Tegra boards that I test all seem >>> fine, at least as far as passing test/py. >>> >>> P.S. I'll be away next week and the week after. Tom Warren may be able to >>> monitor the test system emails, but I don't think I've set him up with >>> access to e.g. retrigger tests etc.; perhaps I should look into that... >> >> >> As mentioned elsewhere that error (failing to power on PHY) happens >> for me always on my TK1 (and has for about a year) because it seems to >> have a broken PMIC. I do have a TX1 somewhere but cannot find it >> despite much searching. > > > I'm very puzzled that you claim your TK1 always has this issue; this issue > is clearly not present in mainline U-Boot (unless it's very intermittent and > my test system has got lucky, but it's very reproducible so I don't think > so), and I don't believe there's anything in the the PMIC that can be > altered permanently; the boot configuration is in OTP (One Time > Programmable) memory (fuses?) and can't be changed. Are you absolutely 100% > sure that you cleanly replaced your development version of U-Boot correctly > and tested with a 100% unmodified mainline U-Boot? Also, please try (a) > flashing unmodified mainline U-Boot (b) disconnecting EVERY cable from the > TK1 and leaving it that way for 10 minutes to drain any capacitors (or > perhaps even overnight) (c) powering up to see if any problems still exist. I've never seen this on my device, but one of the Fedora QA devices has similar issues with vanilla upstream u-boot, I wondered whether it was a slightly different HW rev. Peter
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c index 7d9c63b06f..c969954182 100644 --- a/drivers/pci/pci_tegra.c +++ b/drivers/pci/pci_tegra.c @@ -16,7 +16,6 @@ #include <clk.h> #include <dm.h> #include <errno.h> -#include <fdtdec.h> #include <malloc.h> #include <pci.h> #include <power-domain.h> @@ -25,6 +24,7 @@ #include <asm/io.h> #include <asm/gpio.h> +#include <linux/ioport.h> #include <linux/list.h> #ifndef CONFIG_TEGRA186 @@ -220,9 +220,9 @@ struct tegra_pcie_soc { struct tegra_pcie { struct pci_controller hose; - struct fdt_resource pads; - struct fdt_resource afi; - struct fdt_resource cs; + struct resource pads; + struct resource afi; + struct resource cs; struct list_head ports; unsigned long xbar; @@ -364,13 +364,12 @@ static int pci_tegra_write_config(struct udevice *bus, pci_dev_t bdf, return 0; } -static int tegra_pcie_port_parse_dt(const void *fdt, int node, - struct tegra_pcie_port *port) +static int tegra_pcie_port_parse_dt(ofnode node, struct tegra_pcie_port *port) { const u32 *addr; int len; - addr = fdt_getprop(fdt, node, "assigned-addresses", &len); + addr = ofnode_read_prop(node, "assigned-addresses", &len); if (!addr) { error("property \"assigned-addresses\" not found"); return -FDT_ERR_NOTFOUND; @@ -382,7 +381,7 @@ static int tegra_pcie_port_parse_dt(const void *fdt, int node, return 0; } -static int tegra_pcie_get_xbar_config(const void *fdt, int node, u32 lanes, +static int tegra_pcie_get_xbar_config(ofnode node, u32 lanes, enum tegra_pci_id id, unsigned long *xbar) { switch (id) { @@ -456,14 +455,12 @@ static int tegra_pcie_get_xbar_config(const void *fdt, int node, u32 lanes, return -FDT_ERR_NOTFOUND; } -static int tegra_pcie_parse_port_info(const void *fdt, int node, - unsigned int *index, - unsigned int *lanes) +static int tegra_pcie_parse_port_info(ofnode node, uint *index, uint *lanes) { struct fdt_pci_addr addr; int err; - err = fdtdec_get_int(fdt, node, "nvidia,num-lanes", 0); + err = ofnode_read_u32_default(node, "nvidia,num-lanes", -1); if (err < 0) { error("failed to parse \"nvidia,num-lanes\" property"); return err; @@ -471,7 +468,7 @@ static int tegra_pcie_parse_port_info(const void *fdt, int node, *lanes = err; - err = fdtdec_get_pci_addr(fdt, node, 0, "reg", &addr); + err = ofnode_read_pci_addr(node, 0, "reg", &addr); if (err < 0) { error("failed to parse \"reg\" property"); return err; @@ -487,28 +484,26 @@ int __weak tegra_pcie_board_init(void) return 0; } -static int tegra_pcie_parse_dt(const void *fdt, int node, enum tegra_pci_id id, +static int tegra_pcie_parse_dt(struct udevice *dev, enum tegra_pci_id id, struct tegra_pcie *pcie) { - int err, subnode; + ofnode subnode; u32 lanes = 0; + int err; - err = fdt_get_named_resource(fdt, node, "reg", "reg-names", "pads", - &pcie->pads); + err = dev_read_resource(dev, 0, &pcie->pads); if (err < 0) { error("resource \"pads\" not found"); return err; } - err = fdt_get_named_resource(fdt, node, "reg", "reg-names", "afi", - &pcie->afi); + err = dev_read_resource(dev, 1, &pcie->afi); if (err < 0) { error("resource \"afi\" not found"); return err; } - err = fdt_get_named_resource(fdt, node, "reg", "reg-names", "cs", - &pcie->cs); + err = dev_read_resource(dev, 2, &pcie->cs); if (err < 0) { error("resource \"cs\" not found"); return err; @@ -531,12 +526,11 @@ static int tegra_pcie_parse_dt(const void *fdt, int node, enum tegra_pci_id id, } #endif - fdt_for_each_subnode(subnode, fdt, node) { + dev_for_each_subnode(subnode, dev) { unsigned int index = 0, num_lanes = 0; struct tegra_pcie_port *port; - err = tegra_pcie_parse_port_info(fdt, subnode, &index, - &num_lanes); + err = tegra_pcie_parse_port_info(subnode, &index, &num_lanes); if (err < 0) { error("failed to obtain root port info"); continue; @@ -544,7 +538,7 @@ static int tegra_pcie_parse_dt(const void *fdt, int node, enum tegra_pci_id id, lanes |= num_lanes << (index << 3); - if (!fdtdec_get_is_enabled(fdt, subnode)) + if (!ofnode_is_available(subnode)) continue; port = malloc(sizeof(*port)); @@ -555,7 +549,7 @@ static int tegra_pcie_parse_dt(const void *fdt, int node, enum tegra_pci_id id, port->num_lanes = num_lanes; port->index = index; - err = tegra_pcie_port_parse_dt(fdt, subnode, port); + err = tegra_pcie_port_parse_dt(subnode, port); if (err < 0) { free(port); continue; @@ -565,7 +559,8 @@ static int tegra_pcie_parse_dt(const void *fdt, int node, enum tegra_pci_id id, port->pcie = pcie; } - err = tegra_pcie_get_xbar_config(fdt, node, lanes, id, &pcie->xbar); + err = tegra_pcie_get_xbar_config(dev_ofnode(dev), lanes, id, + &pcie->xbar); if (err < 0) { error("invalid lane configuration"); return err; @@ -815,7 +810,7 @@ static int tegra_pcie_setup_translations(struct udevice *bus) /* BAR 0: type 1 extended configuration space */ fpci = 0xfe100000; - size = fdt_resource_size(&pcie->cs); + size = resource_size(&pcie->cs); axi = pcie->cs.start; afi_writel(pcie, axi, AFI_AXI_BAR0_START); @@ -1099,7 +1094,7 @@ static int pci_tegra_ofdata_to_platdata(struct udevice *dev) INIT_LIST_HEAD(&pcie->ports); - if (tegra_pcie_parse_dt(gd->fdt_blob, dev_of_offset(dev), id, pcie)) + if (tegra_pcie_parse_dt(dev, id, pcie)) return -EINVAL; return 0;
Update the tegra pci driver to support a live device tree. Fix the check for nvidia,num-lanes so that an error will actually be detected. Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v3: - Add new patch to convert tegra PCI to device tree Changes in v2: None drivers/pci/pci_tegra.c | 53 ++++++++++++++++++++++--------------------------- 1 file changed, 24 insertions(+), 29 deletions(-)