diff mbox

[v3,0/8] arm64: rockchip: Initial GeekBox enablement

Message ID 56DFFA9E.7060602@st.com
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Giuseppe CAVALLARO March 9, 2016, 10:27 a.m. UTC 
Hello Tomeu, Andreas,

On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote:
>> * today's linux-next: probe failed
>>
>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No
>> PHY found' regression: probe succeeded but no network at all
>>
>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No
>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame
>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and
>> nfsroot works for a few seconds before timing out
>
> ok, I was looking at this problem now that seems to related
> the "stmmac: first frame prep at the end of xmit routine"
> that, at first glance, is breaking the gmac 3.50 with normal descriptor.

I have no Hw where to test this use case. So, I wonder if may I ask you 
to test some patch.

This first patch adds a missing barrier to the normal routine that inits 
the descriptor. Barrier was needed to well manage the OWN
descriptor and it was not added in case of normal desc case after
the xmit rework.

Then I will check the algo behind the new xmit and in case of problems,
if you agree, we will decide to revert it because it aimed to add an
optimization.

Let me know if you agree.

Regards
Peppe

Comments

Tomeu Vizoso March 9, 2016, 10:53 a.m. UTC | #1 
On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote:
> Hello Tomeu, Andreas,
>
> On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote:
>>>
>>> * today's linux-next: probe failed
>>>
>>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No
>>> PHY found' regression: probe succeeded but no network at all
>>>
>>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No
>>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame
>>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and
>>> nfsroot works for a few seconds before timing out
>>
>>
>> ok, I was looking at this problem now that seems to related
>> the "stmmac: first frame prep at the end of xmit routine"
>> that, at first glance, is breaking the gmac 3.50 with normal descriptor.
>
>
> I have no Hw where to test this use case. So, I wonder if may I ask you to
> test some patch.
>
> This first patch adds a missing barrier to the normal routine that inits the
> descriptor. Barrier was needed to well manage the OWN
> descriptor and it was not added in case of normal desc case after
> the xmit rework.
>
> Then I will check the algo behind the new xmit and in case of problems,
> if you agree, we will decide to revert it because it aimed to add an
> optimization.
>
> Let me know if you agree.

I'm not sure what you would like to be tested, but just in case, I
have just tried your patch on top of these commits and the result is
the "transmit queue 0 timed out" error during boot:

6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine"
eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch"
e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy"
ef5dd3777876 stmmac: fix MDIO settings
77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression"
7811b4ffc312 Add linux-next specific files for 20160309

Regards,

Tomeu

> Regards
> Peppe
Giuseppe CAVALLARO March 9, 2016, 2:31 p.m. UTC | #2 
Hi Tomeu

On 3/9/2016 11:53 AM, Tomeu Vizoso wrote:
> On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote:
>> Hello Tomeu, Andreas,
>>
>> On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote:
>>>>
>>>> * today's linux-next: probe failed
>>>>
>>>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No
>>>> PHY found' regression: probe succeeded but no network at all
>>>>
>>>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No
>>>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame
>>>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and
>>>> nfsroot works for a few seconds before timing out
>>>
>>>
>>> ok, I was looking at this problem now that seems to related
>>> the "stmmac: first frame prep at the end of xmit routine"
>>> that, at first glance, is breaking the gmac 3.50 with normal descriptor.
>>
>>
>> I have no Hw where to test this use case. So, I wonder if may I ask you to
>> test some patch.
>>
>> This first patch adds a missing barrier to the normal routine that inits the
>> descriptor. Barrier was needed to well manage the OWN
>> descriptor and it was not added in case of normal desc case after
>> the xmit rework.
>>
>> Then I will check the algo behind the new xmit and in case of problems,
>> if you agree, we will decide to revert it because it aimed to add an
>> optimization.
>>
>> Let me know if you agree.
>
> I'm not sure what you would like to be tested, but just in case, I
> have just tried your patch on top of these commits and the result is
> the "transmit queue 0 timed out" error during boot:
>
> 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine"
> eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch"
> e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy"
> ef5dd3777876 stmmac: fix MDIO settings
> 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression"
> 7811b4ffc312 Add linux-next specific files for 20160309

I missed that the issue is not only related the
   "stmmac: first frame prep at the end of xmit routine"
I have to try to test on 3.50 with normal descriptor.
When using enhanced descriptors all works fine on my
side.

I keep you informed.

peppe


> Regards,
>
> Tomeu
>
>> Regards
>> Peppe
>
>
Giuseppe CAVALLARO March 9, 2016, 2:53 p.m. UTC | #3 
Hi Tomeu, Dinh, Andreas

I need a sum and help from you to go ahead on the
tx timeout.

The "stmmac: MDIO fixes" seems to be the candidate to
fix the phy connection and I will send the V2 asap (Andreas' comment).

So, supposing the probe is ok and phy is connected,
I need your input ...

  Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
         prep at the end of xmit routine) the network is
         not stable and there is a timeout after a while.
         The box has 3.50 with normal desc settings.

  Dinh: the network is ok, I wonder if you can share a boot
        log just to understand if the normal or enhanced
        descriptors are used.

  Andreas: you are also using 3.50 with normal desc but I have not
           clear if just reverting 0e80bdc9a72d  commit the
           network is ok or you see timeout issues.

In the meantime I am trying to find a box where try normal setup
and I can confirm that enhanced descriptors are ok on my side

Regards
Peppe




On 3/9/2016 3:31 PM, Giuseppe CAVALLARO wrote:
> Hi Tomeu
>
> On 3/9/2016 11:53 AM, Tomeu Vizoso wrote:
>> On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro@st.com>
>> wrote:
>>> Hello Tomeu, Andreas,
>>>
>>> On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote:
>>>>>
>>>>> * today's linux-next: probe failed
>>>>>
>>>>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No
>>>>> PHY found' regression: probe succeeded but no network at all
>>>>>
>>>>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No
>>>>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame
>>>>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and
>>>>> nfsroot works for a few seconds before timing out
>>>>
>>>>
>>>> ok, I was looking at this problem now that seems to related
>>>> the "stmmac: first frame prep at the end of xmit routine"
>>>> that, at first glance, is breaking the gmac 3.50 with normal
>>>> descriptor.
>>>
>>>
>>> I have no Hw where to test this use case. So, I wonder if may I ask
>>> you to
>>> test some patch.
>>>
>>> This first patch adds a missing barrier to the normal routine that
>>> inits the
>>> descriptor. Barrier was needed to well manage the OWN
>>> descriptor and it was not added in case of normal desc case after
>>> the xmit rework.
>>>
>>> Then I will check the algo behind the new xmit and in case of problems,
>>> if you agree, we will decide to revert it because it aimed to add an
>>> optimization.
>>>
>>> Let me know if you agree.
>>
>> I'm not sure what you would like to be tested, but just in case, I
>> have just tried your patch on top of these commits and the result is
>> the "transmit queue 0 timed out" error during boot:
>>
>> 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine"
>> eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a
>> switch"
>> e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy"
>> ef5dd3777876 stmmac: fix MDIO settings
>> 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression"
>> 7811b4ffc312 Add linux-next specific files for 20160309
>
> I missed that the issue is not only related the
>    "stmmac: first frame prep at the end of xmit routine"
> I have to try to test on 3.50 with normal descriptor.
> When using enhanced descriptors all works fine on my
> side.
>
> I keep you informed.
>
> peppe
>
>
>> Regards,
>>
>> Tomeu
>>
>>> Regards
>>> Peppe
>>
>>
>
>
>
Dinh Nguyen March 9, 2016, 4:31 p.m. UTC | #4 
On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> Hi Tomeu, Dinh, Andreas
>
> I need a sum and help from you to go ahead on the
> tx timeout.
>
> The "stmmac: MDIO fixes" seems to be the candidate to
> fix the phy connection and I will send the V2 asap (Andreas' comment).
>
> So, supposing the probe is ok and phy is connected,
> I need your input ...
>
>  Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
>         prep at the end of xmit routine) the network is
>         not stable and there is a timeout after a while.
>         The box has 3.50 with normal desc settings.
>
>  Dinh: the network is ok, I wonder if you can share a boot
>        log just to understand if the normal or enhanced
>        descriptors are used.
>

Here it is:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc6-next-20160304-00001-g092eb23
(dinguyen@linux-builds1) (gcc version 4.7.3 2013022
6 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 -
Linaro GCC 2013.03) ) #1 SMP Wed Mar 9 10:22:14 CST 2
016
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine model: Altera SOCFPGA Cyclone V SoC Development Kit
[    0.000000] cma: Reserved 64 MiB at 0x3c000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 13 pages/cpu @ef7cc000 s23808 r8192
d21248 u53248
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 260608
[    0.000000] Kernel command line: console=ttyS0,115200
root=/dev/mmcblk0p2 rw rootwait ip=dhcp
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 955932K/1048576K available (9522K kernel code,
1142K rwdata, 4124K rodata, 2048K init, 342K bss,
 27108K reserved, 65536K cma-reserved, 196608K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0208000 - 0xc1053830   (14639 kB)
[    0.000000]       .init : 0xc1100000 - 0xc1300000   (2048 kB)
[    0.000000]       .data : 0xc1300000 - 0xc141da80   (1143 kB)
[    0.000000]        .bss : 0xc141f000 - 0xc1474920   ( 343 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000]  RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 erratum 769419 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 1 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x76060001
[    0.000000] clocksource: timer1: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604467 ns
[    0.000005] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps
every 21474836475ns
[    0.000015] Switching to timer-based delay loop, resolution 10ns
[    0.000268] Console: colour dummy device 80x30
[    0.000290] Calibrating delay loop (skipped), value calculated
using timer frequency.. 200.00 BogoMIPS (lpj=500000)
[    0.000301] pid_max: default: 32768 minimum: 301
[    0.000374] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000382] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000879] CPU: Testing write buffer coherency: ok
[    0.001062] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.001207] Setting up static identity map for 0x300000 - 0x300098
[    0.003872] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.003946] Brought up 2 CPUs
[    0.003959] SMP: Total of 2 processors activated (400.00 BogoMIPS).
[    0.003965] CPU: All CPU(s) started in SVC mode.
[    0.004672] devtmpfs: initialized
[    0.008193] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[    0.008609] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 9556302231375000 ns
[    0.011733] pinctrl core: initialized pinctrl subsystem
[    0.013149] NET: Registered protocol family 16
[    0.014993] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.029850] cpuidle: using governor menu
[    0.035166] No ATAGs?
[    0.035199] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.035207] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.037795] Serial: AMBA PL011 UART driver
[    0.064193] vgaarb: loaded
[    0.064994] SCSI subsystem initialized
[    0.065377] usbcore: registered new interface driver usbfs
[    0.065427] usbcore: registered new interface driver hub
[    0.065471] usbcore: registered new device driver usb
[    0.065637] soc:usbphy@0 supply vcc not found, using dummy regulator
[    0.066917] pps_core: LinuxPPS API ver. 1 registered
[    0.066925] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[    0.066948] PTP clock support registered
[    0.067075] EDAC MC: Ver: 3.0.0
[    0.068905] clocksource: Switched to clocksource timer1
[    0.077130] NET: Registered protocol family 2
[    0.077598] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.077675] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.077789] TCP: Hash tables configured (established 8192 bind 8192)
[    0.077850] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.077892] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.078045] NET: Registered protocol family 1
[    0.078313] RPC: Registered named UNIX socket transport module.
[    0.078322] RPC: Registered udp transport module.
[    0.078327] RPC: Registered tcp transport module.
[    0.078332] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.079971] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.080491] workingset: timestamp_bits=28 max_order=18 bucket_order=0
[    0.088552] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.089257] NFS: Registering the id_resolver key type
[    0.089295] Key type id_resolver registered
[    0.089302] Key type id_legacy registered
[    0.089357] ntfs: driver 2.1.32 [Flags: R/O].
[    0.090460] bounce: pool size: 64 pages
[    0.090644] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 248)
[    0.090659] io scheduler noop registered
[    0.090670] io scheduler deadline registered
[    0.090702] io scheduler cfq registered (default)
[    0.101187] dma-pl330 ffe01000.pdma: Loaded driver for PL330 DMAC-341330
[    0.101202] dma-pl330 ffe01000.pdma:         DBUFF-512x8bytes
Num_Chans-8 Num_Peri-32 Num_Events-8
[    0.148800] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.150717] console [ttyS0] disabled
[    0.150752] ffc02000.serial0: ttyS0 at MMIO 0xffc02000 (irq = 35,
base_baud = 6250000) is a 16550A
[    0.760760] console [ttyS0] enabled
[    0.764930] ffc03000.serial1: ttyS1 at MMIO 0xffc03000 (irq = 36,
base_baud = 6250000) is a 16550A
[    0.774702] SuperH (H)SCI(F) driver initialized
[    0.779746] msm_serial: driver initialized
[    0.783950] STMicroelectronics ASC driver initialized
[    0.789977] [drm] Initialized drm 1.1.0 20060810
[    0.804439] brd: module loaded
[    0.812215] loop: module loaded
[    0.815664] at24 0-0051: 4096 byte 24c32 EEPROM, writable, 32 bytes/write
[    0.827372] libphy: Fixed MDIO Bus: probed
[    0.832015] CAN device driver interface
[    0.836848] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[    0.843792] igb: Copyright (c) 2007-2014 Intel Corporation.
[    0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
[    0.855570]  Ring mode enabled
[    0.858611]  DMA HW capability register supported
[    0.863128]  Enhanced/Alternate descriptors
[    0.867482]  Enabled extended descriptors
[    0.871482]  RX Checksum Offload Engine supported (type 2)
[    0.876948]  TX Checksum insertion supported
[    0.881204]  Enable RX Mitigation via HW Watchdog Timer
[    0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
[    0.899090] libphy: stmmac: probed
[    0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
[    0.909742] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB
Ethernet driver
[    0.917175] usbcore: registered new interface driver pegasus
[    0.922873] usbcore: registered new interface driver asix
[    0.928300] usbcore: registered new interface driver ax88179_178a
[    0.934422] usbcore: registered new interface driver cdc_ether
[    0.940294] usbcore: registered new interface driver smsc75xx
[    0.946078] usbcore: registered new interface driver smsc95xx
[    0.951848] usbcore: registered new interface driver net1080
[    0.957529] usbcore: registered new interface driver cdc_subset
[    0.963470] usbcore: registered new interface driver zaurus
[    0.969098] usbcore: registered new interface driver cdc_ncm
[    0.975810] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.982335] ehci-pci: EHCI PCI platform driver
[    0.986814] ehci-platform: EHCI generic platform driver
[    0.992147] ehci-omap: OMAP-EHCI Host Controller driver
[    0.997446] ehci-orion: EHCI orion driver
[    1.001534] SPEAr-ehci: EHCI SPEAr driver
[    1.005623] ehci-st: EHCI STMicroelectronics driver
[    1.010577] ehci-exynos: EHCI EXYNOS driver
[    1.014845] ehci-atmel: EHCI Atmel driver
[    1.018930] tegra-ehci: Tegra EHCI driver
[    1.023017] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.029198] ohci-pci: OHCI PCI platform driver
[    1.033671] ohci-platform: OHCI generic platform driver
[    1.038999] ohci-omap3: OHCI OMAP3 driver
[    1.043076] SPEAr-ohci: OHCI SPEAr driver
[    1.047166] ohci-st: OHCI STMicroelectronics driver
[    1.052119] ohci-atmel: OHCI Atmel driver
[    1.056540] usbcore: registered new interface driver usb-storage
[    1.063604] mousedev: PS/2 mouse device common for all mice
[    1.071372] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
[    1.078720] i2c /dev entries driver
[    1.088558] sdhci: Secure Digital Host Controller Interface driver
[    1.094733] sdhci: Copyright(c) Pierre Ossman
[    1.099926] Synopsys Designware Multimedia Card Interface Driver
[    1.106160] dw_mmc ff704000.dwmmc0: IDMAC supports 32-bit address mode.
[    1.112832] dw_mmc ff704000.dwmmc0: Using internal DMA controller.
[    1.119003] dw_mmc ff704000.dwmmc0: Version ID is 240a
[    1.124161] dw_mmc ff704000.dwmmc0: DW MMC controller at irq 30,32
bit host data width,1024 deep fifo
[    1.133484] dw_mmc ff704000.dwmmc0: Got CD GPIO
[    1.163951] dw_mmc ff704000.dwmmc0: 1 slots initialized
[    1.169801] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.176752] ledtrig-cpu: registered to indicate activity on CPUs
[    1.183123] usbcore: registered new interface driver usbhid
[    1.188689] usbhid: USB HID core driver
[    1.196305] NET: Registered protocol family 10
[    1.201510] sit: IPv6 over IPv4 tunneling driver
[    1.206748] NET: Registered protocol family 17
[    1.211203] can: controller area network core (rev 20120528 abi 9)
[    1.217420] NET: Registered protocol family 29
[    1.221867] can: raw protocol (rev 20120528)
[    1.226139] can: broadcast manager protocol (rev 20120528 t)
[    1.231793] can: netlink gateway (rev 20130117) max_hops=1
[    1.237633] Key type dns_resolver registered
[    1.242056] ThumbEE CPU extension supported.
[    1.246339] Registering SWP/SWPB emulation handler
[    1.252996] rtc-ds1307 0-0068: setting system clock to 2000-01-01
10:28:48 UTC (946722528)
[    1.283660] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot
req 50000000Hz, actual 50000000HZ div = 0)
[    1.293419] mmc0: new high speed SDHC card at address 0007
[    1.299260] mmcblk0: mmc0:0007 SD4GB 3.71 GiB
[    1.305075]  mmcblk0: p1 p2 p3 p4
[    1.336767] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.324487] socfpga-dwmac ff702000.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[    5.333591] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    5.343917] Sending DHCP requests ., OK
Giuseppe CAVALLARO March 10, 2016, 9:13 a.m. UTC | #5 
On 3/9/2016 5:31 PM, Dinh Nguyen wrote:
> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
> <peppe.cavallaro@st.com> wrote:
>> Hi Tomeu, Dinh, Andreas
>>
>> I need a sum and help from you to go ahead on the
>> tx timeout.
>>
>> The "stmmac: MDIO fixes" seems to be the candidate to
>> fix the phy connection and I will send the V2 asap (Andreas' comment).
>>
>> So, supposing the probe is ok and phy is connected,
>> I need your input ...
>>
>>   Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
>>          prep at the end of xmit routine) the network is
>>          not stable and there is a timeout after a while.
>>          The box has 3.50 with normal desc settings.
>>
>>   Dinh: the network is ok, I wonder if you can share a boot
>>         log just to understand if the normal or enhanced
>>         descriptors are used.
>>
>
> Here it is:
...
> [    0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
> [    0.855570]  Ring mode enabled
> [    0.858611]  DMA HW capability register supported
> [    0.863128]  Enhanced/Alternate descriptors
> [    0.867482]  Enabled extended descriptors
> [    0.871482]  RX Checksum Offload Engine supported (type 2)
> [    0.876948]  TX Checksum insertion supported
> [    0.881204]  Enable RX Mitigation via HW Watchdog Timer
> [    0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
> [    0.899090] libphy: stmmac: probed
> [    0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active

Thx Dinh, so you are using the Enhanced/Alternate descriptors
I am debugging on my side on a setup with normal descriptors, I let you
know

peppe
Dinh Nguyen March 10, 2016, 4:47 p.m. UTC | #6 
On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 3/9/2016 5:31 PM, Dinh Nguyen wrote:
>>
>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
>> <peppe.cavallaro@st.com> wrote:
>>>
>>> Hi Tomeu, Dinh, Andreas
>>>
>>> I need a sum and help from you to go ahead on the
>>> tx timeout.
>>>
>>> The "stmmac: MDIO fixes" seems to be the candidate to
>>> fix the phy connection and I will send the V2 asap (Andreas' comment).
>>>
>>> So, supposing the probe is ok and phy is connected,
>>> I need your input ...
>>>
>>>   Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
>>>          prep at the end of xmit routine) the network is
>>>          not stable and there is a timeout after a while.
>>>          The box has 3.50 with normal desc settings.
>>>
>>>   Dinh: the network is ok, I wonder if you can share a boot
>>>         log just to understand if the normal or enhanced
>>>         descriptors are used.
>>>
>>
>> Here it is:
>
> ...
>>
>> [    0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
>> [    0.855570]  Ring mode enabled
>> [    0.858611]  DMA HW capability register supported
>> [    0.863128]  Enhanced/Alternate descriptors
>> [    0.867482]  Enabled extended descriptors
>> [    0.871482]  RX Checksum Offload Engine supported (type 2)
>> [    0.876948]  TX Checksum insertion supported
>> [    0.881204]  Enable RX Mitigation via HW Watchdog Timer
>> [    0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
>> [    0.899090] libphy: stmmac: probed
>> [    0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
>
>
> Thx Dinh, so you are using the Enhanced/Alternate descriptors
> I am debugging on my side on a setup with normal descriptors, I let you
> know
>

Doesn't the printout "Enhanced/Alternate descriptors"  mean that I'm using
Enhanced/Alternate descriptors?

Dinh
diff mbox

Patch

diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index e13228f..4392610 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -210,7 +210,7 @@  static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
 		tdes1 &= ~TDES1_FIRST_SEGMENT;
 
 	if (likely(csum_flag))
-		tdes1 |= (TX_CIC_FULL) << TDES1_CHECKSUM_INSERTION_SHIFT;
+		tdes1 |= (TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT);
 	else
 		tdes1 &= ~(TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT);
 
@@ -220,6 +220,13 @@  static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len,
 	if (tx_own)
 		tdes1 |= TDES0_OWN;
 
+	if (is_fs & tx_own)
+		/* When the own bit, for the first frame, has to be set, all
+		 * descriptors for the same frame has to be set before, to
+		 * avoid race condition.
+		 */
+		wmb();
+
 	p->des1 = tdes1;
 }