[U-Boot] [Drivers PATCH 14/19] net/macb: workaround for transmission hang issue

Bo Shen voice.shen at atmel.com
Fri Mar 1 04:08:45 CET 2013


Hi All,

On 02/28/2013 08:59 PM, Albert ARIBAUD wrote:
> On Sun, 3 Feb 2013 12:19:26 +0100, Albert ARIBAUD
> <albert.u.boot at aribaud.net>  wrote:
>
>> Hi Vipin,
>>
>> On Fri, 2 Nov 2012 23:09:59 +0530, Vipin Kumar<vipin.kumar at st.com>
>> wrote:
>>
>>> From: Shiraz Hashim<shiraz.hashim at st.com>
>>>
>>> It is observed on SPEAr320S RMII#1 interface that on transmitting
>>> packets the MAC dma hangs randomly and constantly showing busy tx-go
>>> state.
>>>
>>> It comes out if this situation only when Transmission is disabled and
>>> enabled again.
>>>
>>> Since it happens randomly and u-boot doesn't require high performance we
>>> disable TE and re-enable it on each transmission. We also change number
>>> of transmit descriptor to 1 as we would not require more than it, further
>>> it would not alter GMAC notion of transmit descriptor start queue as it
>>> always point to same descriptor.
>>>
>>> Signed-off-by: Shiraz Hashim<shiraz.hashim at st.com>
>>> ---
>>>   drivers/net/macb.c | 38 ++++++++++++++++++++++++++++++++++----
>>>   1 file changed, 34 insertions(+), 4 deletions(-)

Tested on Atmel EK board. It works.

Tested-by: Bo Shen <voice.shen at atmel.com>

BTW, would this be implemented as a workaround only for SPEAr320S?

Best Regards,
Bo Shen

>>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>>> index ac25b52..17bad33 100644
>>> --- a/drivers/net/macb.c
>>> +++ b/drivers/net/macb.c
>>> @@ -55,7 +55,7 @@
>>>
>>>   #define CONFIG_SYS_MACB_RX_BUFFER_SIZE		4096
>>>   #define CONFIG_SYS_MACB_RX_RING_SIZE		(CONFIG_SYS_MACB_RX_BUFFER_SIZE / 128)
>>> -#define CONFIG_SYS_MACB_TX_RING_SIZE		16
>>> +#define CONFIG_SYS_MACB_TX_RING_SIZE		1
>>>   #define CONFIG_SYS_MACB_TX_TIMEOUT		1000
>>>   #define CONFIG_SYS_MACB_AUTONEG_TIMEOUT	5000000
>>>
>>> @@ -226,7 +226,13 @@ static int macb_send(struct eth_device *netdev, void *packet, int length)
>>>   	macb->tx_ring[tx_head].ctrl = ctrl;
>>>   	macb->tx_ring[tx_head].addr = paddr;
>>>   	barrier();
>>> -	macb_writel(macb, NCR, MACB_BIT(TE) | MACB_BIT(RE) | MACB_BIT(TSTART));
>>> +	/*
>>> +	 * Due to issues on SPEAr320 RMII, disable TE first so that
>>> +	 * controller can come out if it is hanged during transmission
>>> +	 */
>>> +	macb_writel(macb, NCR, macb_readl(macb, NCR)&  ~MACB_BIT(TE));
>>> +	macb_writel(macb, NCR, macb_readl(macb, NCR) |
>>> +			MACB_BIT(TE) | MACB_BIT(TSTART));
>>>
>>>   	/*
>>>   	 * I guess this is necessary because the networking core may
>>> @@ -444,6 +450,31 @@ static int macb_phy_init(struct macb_device *macb)
>>>   	}
>>>   }
>>>
>>> +static void macb_reset_hw(struct macb_device *bp)
>>> +{
>>> +	/* Make sure we have the write buffer for ourselves */
>>> +	barrier();
>>> +	/*
>>> +	 * Disable RX and TX (XXX: Should we halt the transmission
>>> +	 * more gracefully?) and we should not close the mdio port
>>> +	 */
>>> +	macb_writel(bp, NCR, 0);
>>> +
>>> +	/* Clear the stats registers (XXX: Update stats first?) */
>>> +	macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
>>> +
>>> +	/* keep the mdio port , otherwise other eth will not work */
>>> +	macb_writel(bp, NCR, MACB_BIT(MPE));
>>> +
>>> +	/* Clear all status flags */
>>> +	macb_writel(bp, TSR, ~0UL);
>>> +	macb_writel(bp, RSR, ~0UL);
>>> +
>>> +	/* Disable all interrupts */
>>> +	macb_writel(bp, IDR, ~0UL);
>>> +	macb_readl(bp, ISR);
>>> +}
>>> +
>>>   static int macb_init(struct eth_device *netdev, bd_t *bd)
>>>   {
>>>   	struct macb_device *macb = to_macb(netdev);
>>> @@ -520,8 +551,7 @@ static void macb_halt(struct eth_device *netdev)
>>>   		tsr = macb_readl(macb, TSR);
>>>   	} while (tsr&  MACB_BIT(TGO));
>>>
>>> -	/* Disable TX and RX, and clear statistics */
>>> -	macb_writel(macb, NCR, MACB_BIT(CLRSTAT));
>>> +	macb_reset_hw(macb);
>>>   }
>>>
>>>   static int macb_write_hwaddr(struct eth_device *dev)
>>
>> This patch did not reappear in later versions of the series, and no
>> other standalone patch seems to match it. Was it dropped?
>
> Ping?
>
> Amicalement,



More information about the U-Boot mailing list