Hi,
On Mon, Mar 24, 2014 at 4:21 AM, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
> On 03/23/2014 04:13 PM, Ian Campbell wrote:
>> On Sat, 2014-03-22 at 20:22 +0100, Hans de Goede wrote:
>>> One thing that stands out when doing a diff against sunxi-merge-v2014.04-rc2
>>> is this:
>>>
>>> --- u-boot/drivers/net/designware.c 2014-03-21 16:26:42.229522420 +0100
>>> +++ u-boot-sunxi/drivers/net/designware.c 2014-03-22
>>> 17:21:51.907879720 +
>>> @@ -249,10 +249,10 @@
>>> rx_descs_init(dev);
>>> tx_descs_init(dev);
>>>
>>> - writel(FIXEDBURST | PRIORXTX_41 | BURST_16, &dma_p->busmode);
>>> + writel(FIXEDBURST | PRIORXTX_41 | BURST_8, &dma_p->busmode);
This is required. The GMAC IP does not support DMA burst lengths above 8.
>>>
>>> - writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD,
>>> - &dma_p->opmode);
>>> + writel(readl(&dma_p->opmode) | FLUSHTXFIFO | STOREFORWARD |
>>> + TXSECONDFRAME, &dma_p->opmode);
This is a performance improvement change, as seen in the Linux kernel:
csr6 |= DMA_CONTROL_TSF;
/* Operating on second frame increase the performance
* especially when transmit store-and-forward is used.
*/
csr6 |= DMA_CONTROL_OSF;
Though AFAIK we never changed this. Maybe it was changed upstream.
>>>
>>> writel(readl(&dma_p->opmode) | RXSTART | TXSTART, &dma_p->opmode);
>>>
>>>
>>> Which we should probably fix given that you've enabled gmac support.
>>
>> Things work for me without.
>
> IIRC the BURST_8 is necessary to get certain traffic patterns to not cause
> corruption. Don't know about the rest. Wens probably knows best.
See above.
>> I was under the impression that Wens (or
>> someone else) had this under control WRT upstreaming so I was leaving it
>> for now,
>
> I'm not sure wens, or anyone for that matter is actively working on gmac
> u-boot support.
Sorry, no one is actively working on this ATM. If you could do it, that
would be nice. Only a oneliner to change the burst length is required.
>> it can easily go in as an independent fix AFAICT.
>
> It can and it should, but first we need some more info I guess, wens ?
See inline comments above.
I regret that my attention is focused elsewhere ATM, with all that's
happened in the last week (and still ongoing) in my country.
Feel free to run any GMAC related patches by me, though. I will try to
look at it.
Cheers
ChenYu
>>> I also noticed that in include/configs/sunxi-common.h you've a formatting
>>> fix for the CONFIG_PHY_ADDR #define which is not yet in u-boot-sunxi.
>>
>> CONFIG_PHY_ADDR arrived as part of the merge of v2014.04-rc2, so the fix
>> got folded into the merge when I redid it.
>
> Ah, ok.
>
>>
>> I might manage a v3, which will be a couple of cleanups and a lot of
>> clarifications about licensing, today, or I might watch game of thrones
>> and do v3 later in the week, lets see how it goes...
>
> Sounds good. I hope that your license clarification will be good enough
> for upstream, and thanks for working on this.
>
> Regards,
>
> Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
