[U-Boot] [PATCH v3 9/9] net/designware: Reduce DMA burst length

Alexey Brodkin Alexey.Brodkin at synopsys.com
Mon Apr 28 22:18:13 CEST 2014


Hi Marek,

On Mon, 2014-04-28 at 07:55 +0200, Marek Vasut wrote:
> On Monday, April 28, 2014 at 07:51:49 AM, Chen-Yu Tsai wrote:
> > On Mon, Apr 28, 2014 at 2:08 AM, Marek Vasut <marex at denx.de> wrote:
> > > On Sunday, April 27, 2014 at 05:29:29 PM, Chen-Yu Tsai wrote:
> > >> On Sun, Apr 27, 2014 at 11:25 PM, Ian Campbell <ijc at hellion.org.uk> wrote:
> > >> > On Sat, 2014-04-26 at 20:28 +0200, Marek Vasut wrote:
> > >> >> On Friday, April 18, 2014 at 08:05:50 PM, Ian Campbell wrote:
> > >> >> > From: Jens Kuske <jenskuske at gmail.com>
> > >> >> > 
> > >> >> > The GMAC module in Allwinner sunxi SoCs seems to have problems with
> > >> >> > burst lengths > 8.
> > >> >> 
> > >> >> Is there any explanation for the problems please ?
> > >> > 
> > >> > Jens or Wens, can you answer this?
> > >> 
> > >> IIRC, with burst lengths > 8, GMAC doesn't work, no ping, no DHCP.
> > >> I don't remember if it was TX or RX that suffered, or even both.
> > >> 
> > >> Hope this clarifies things a bit.
> > > 
> > > No, it does not at all, sorry. What you describe are symptoms, but what I
> > > want to know is what is the root cause of those symptoms. You did not
> > > explain that.
> > 
> > I can not offer much more explanation. The value was hardcoded in
> > Allwinner's code. The datasheets don't offer much, except this line
> > might be related:
> > 
> >   (DMA) Descriptor architecture, allowing large blocks of data transfer
> >   with minimum CPU intervention; each descriptor can transfer up to
> >   4 KB data.
> > 
> > Also probably related:
> > 
> >   4KB TX FIFO for transmission packets and 16KB RX FIFO for reception
> >   packets.
> > 
> > I'm not an expert in hardware. We could ask Allwinner, but given past
> > inquiries from the linux-sunxi community, I'd say getting a reply on
> > hardware specifics is unlikely to happen.
> > 
> > So my guess is that this is limited by the DWMAC IP Allwinner licensed
> > from Synopsys.

Even though I'm not an expert in DW GMAC I may confirm that it has tons
of settings people may use for fine-tuning performance and I may assume
that there're corner cases when some settings may lead to real problems.

And IMHO if different boards may need different configurations why don't
we satisfy their needs. But it's good to keep others who used to use
existing settings happy too.

If you look in corresponding driver in Linux kernel
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro) you'll see much more complicated code compared to driver in U-Boot. And among other things you may see some GMAC parameters could be set per platform.

And Programmable Burst Length (PBL) is one of them. Look at
stmmac_init_dma_engine() in
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c

You may see default PBL (DEFAULT_DMA_PBL = 8) is used if other value is
not provided by platform.

So I would propose to act this way:

1. Introduce driver-specific config value. Something like
"DW_GMAC_DEFAULT_DMA_PBL" and in "designware.h" set it to "BURST_8". I
hope driver in Linux was used a lot and this value could be treated as
safe.

2. Ask people to try this new setting on existing boards that use DW
GMAC. If everybody is happy there's nothing else to do here.

3. Otherwise if people report regressions add mentioned config option in
board configuration files for problematic boards.

I think with this approach everybody will be happy.

-Alexey


More information about the U-Boot mailing list