On Thu, Nov 5, 2015 at 2:54 AM, Stephen Warren <[email protected]> wrote: > On 10/30/2015 05:07 AM, Ivan Mercier wrote: >> >> Hi, >> >> I'm using a ethernet controller intel i210 >> (http://www.commell.com.tw/product/Surveillance/MPX-210.htm) on my >> nvidia tegra k1 jetson. > > > (You didn't actually CC anyone involved with Tegra, so I only accidentally > noticed this while I was looking at my mailing list folder) > >> I not an expert with pci, but the only way to make it working in u-boot >> (upstream) is with the workaround below. >> >> E1000 is very common, so finding a critical bug in this driver seems >> weird... >> Do you think there is a bug in e1000.c or in tegra pci layer? > > >> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c > > >> @@ -5186,7 +5186,7 @@ static int _e1000_transmit(struct e1000_hw *hw, >> void *txpacket, int length) >> txp = tx_base + tx_tail; >> tx_tail = (tx_tail + 1) % 8; >> >> - txp->buffer_addr = cpu_to_le64(virt_to_bus(hw->pdev, nv_packet)); >> + txp->buffer_addr = cpu_to_le64((unsigned long) nv_packet); >> txp->lower.data = cpu_to_le32(hw->txd_cmd | length); >> txp->upper.data = 0; > > > In order to work out what's going on, perhaps you could print out the values > of nv_packet and virt_to_bus(hw->pdev, nv_packet). > > It's not terribly surprising that removing the call to virt_to_bus works, > since IIRC U-Boot on Tegra uses the same address setup for the PCIe bus as > for CPU physical addresses as for CPU virtual addresses. > > So, the question is: what is virt_to_bus() doing, and is it the right API to > call?
virt_to_bus() is to translate cpu virtual address to pci bus physical address. Basically two levels of translation. > > I see that virt_to_bus() is defined as: > > e1000.c: > > #define virt_to_bus(devno, v) pci_virt_to_mem(devno, (void *) (v)) > > pci.h: > > #define pci_virt_to_mem(dev, addr) \ > pci_virt_to_bus((dev), (addr), PCI_REGION_MEM) > > #define pci_virt_to_bus(dev, addr, flags) \ > pci_hose_phys_to_bus(pci_bus_to_hose(PCI_BUS(dev)), \ > (virt_to_phys(addr)), (flags)) > > I know that the RTL8169 driver works on the same board (it's soldered down > and attached to the other PCIe root port on the SoC). For what looks like > the same "use case", it seems to call pci_mem_to_phys() which is: > > pci.h: > > #define pci_mem_to_phys(dev, addr) \ > pci_bus_to_phys((dev), (addr), PCI_REGION_MEM) > > #define pci_bus_to_phys(dev, addr, flags) \ > pci_hose_bus_to_phys(pci_bus_to_hose(PCI_BUS(dev)), (addr), \ > (flags)) > > That's odd, since one of those does a phys -> bus translation and the other > does a bus -> phys translation. That's the opposite direction, so both can't > possibly be right. I wonder if those mapping functions are no-ops on Indeed these address translation macros in pci.h are confusing. But most SoC defines 1:1:1 mapping so these are not needed. The reason why it fails on Tegra is probably due to the addresses are not 1:1:1 mapped? > whatever architectures the e1000 driver has been used on (and hence have > caused no issues), but fail for some reason on ARM? > > (The other difference is the call to virt_to_phys(), but that's a no-op on > ARM as far as I can tell). Regards, Bin _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
