On Mon, Mar 24, 2014 at 4:39 PM, Ian Campbell <[email protected]> wrote:
> On Mon, 2014-03-24 at 12:55 +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Mon, Mar 24, 2014 at 4:21 AM, Hans de Goede <[email protected]> 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.
>
> Should this be a per-platform option or should it be reduced for
> everyone? Having to make that call is one of the main reasons I've been
> leaving it alone since I just don't have the necessary context.
Reducing it for everyone shouldn't break anything. As for the performance
decrease, does anyone actually use U-boot to transfer loads of data?
>> >>> - 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,
>
> What sort of magnitude is it? e.g. I'm not sure how important a few
> percent would be in a bootloader, but if it were a 200% improvement then
> well.
>
> In any case I think I won't tackle this bit as part of the initial
> upstreaming attempt.
A quick blame shows this was removed in
92a190a net/designware - switch driver to phylib usage
The whole section was reworked. I don't know if it was purposely left
out, or it was just an error. The commit log doesn't mention it.
As for the performance improvement, I don't think it would be up
to 200%, but I haven't tested it.
Cheers,
ChenYu
>> >> 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.
>
> I'll add it (the burst setting) to my list, but I may not do it until
> after the initial effort has gone upstream.
>
> Ian.
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
