[U-Boot] Ethernet i210 (e1000 driver) on tegra K1

Bin Meng
2015-11-05T03:49:43Z

On Thu, Nov 5, 2015 at 2:54 AM, Stephen Warren <swarren@wwwdotorg.org> 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