[U-Boot] [Drivers PATCH 14/19] net/macb: workaround for transmission hang issue
Vipin Kumar
vipin.kumar at st.com
Fri Mar 1 08:55:46 CET 2013
On 3/1/2013 12:58 PM, Albert ARIBAUD wrote:
> Hi Vipin,
>
> On Fri, 1 Mar 2013 09:11:33 +0530, Vipin Kumar<vipin.kumar at st.com>
> wrote:
>
>> On 2/28/2013 6:29 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(-)
>>>>>
>>>>> 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?
>>>
>>
>> No, I have been busy with something. I would come back to the u-boot
>> development soon
>
> Thanks. Following your discussion with Bo Shen, should I expect a new
> version of this patch in the future, or does it stand as it is?
>
A new version
Vipin
>> Vipin
>
> Amicalement,
More information about the U-Boot
mailing list