Re: [Qemu-devel] [PATCH v3 15/20] arm: add Faraday FTMAC110 10/100Mbps ethernet support

[Stefan Hajnoczi]

On Tue, Feb 19, 2013 at 09:43:27AM +0800, Kuo-Jung Su wrote:
> 2013/2/19 Kuo-Jung Su <address@hidden>:
> > 2013/2/18 Stefan Hajnoczi <address@hidden>:
> >> On Mon, Feb 18, 2013 at 05:44:38PM +0800, Kuo-Jung Su wrote:
> >>> 2013/2/18 Stefan Hajnoczi <address@hidden>:
> >>> > On Wed, Feb 06, 2013 at 05:45:19PM +0800, Kuo-Jung Su wrote:
> >>> >> From: Kuo-Jung Su <address@hidden>
> >>> >>
> >>> >> The FTMAC110 is an Ethernet controller that provides AHB master 
> >>> >> capability
> >>> >> and is in full compliance with the IEEE 802.3 10/100 Mbps 
> >>> >> specifications.
> >>> >> Its DMA controller handles all data transfers between system memory
> >>> >> and on-chip memories.
> >>> >> It supports half-word data transfer for Linux. However it has a weird 
> >>> >> DMA
> >>> >> alignment issue:
> >>> >>
> >>> >> (1) Tx DMA Buffer Address:
> >>> >>     1 bytes aligned: Invalid
> >>> >>     2 bytes aligned: O.K
> >>> >>     4 bytes aligned: O.K
> >>> >>
> >>> >> (2) Rx DMA Buffer Address:
> >>> >>     1 bytes aligned: Invalid
> >>> >>     2 bytes aligned: O.K
> >>> >>     4 bytes aligned: Invalid (It means 0x0, 0x4, 0x8, 0xC are invalid)
> >>> >>
> >>> >> Signed-off-by: Kuo-Jung Su <address@hidden>
> >>> >> ---
> >>> >>  hw/arm/Makefile.objs  |    1 +
> >>> >>  hw/arm/faraday_a360.c |   10 +
> >>> >>  hw/arm/ftmac110.c     |  681 
> >>> >> +++++++++++++++++++++++++++++++++++++++++++++++++
> >>> >>  hw/arm/ftmac110.h     |  131 ++++++++++
> >>> >>  4 files changed, 823 insertions(+)
> >>> >>  create mode 100644 hw/arm/ftmac110.c
> >>> >>  create mode 100644 hw/arm/ftmac110.h
> >>> >
> >>> > Hi Kuo-Jung,
> >>> > Is there a datasheet and/or driver programming guide for this Ethernet
> >>> > controller?
> >>> >
> >>>
> >>> The datasheet distribution is prohibited in Faraday, while it's 
> >>> absolutely O.K
> >>> to deliver software codes along with register description.
> >>>
> >>> So, I can't share the datasheets with you, but I can add register 
> >>> description
> >>> to the source files. Is this what you need?
> >>
> >> I'm asking because I'd like to confirm that the device keeps checking
> >> for available receive descriptors via DMA reads (owner bit) and there is
> >> no hw register access to kick the Ethernet controller?
> >>
> >
> > In a descriptor based ethernet MAC, there is usually a dedicated
> > register to kick-off DMA
> > engine, and of course, FTMAC110/FTGMAC100 has such register, too.
> >
> > They are:
> >
> > 1. ftgmac100:
> >     1-1. REG_TXPD (0x18):  Kick-off Tx DMA engine
> >     1-2. REG_RXPD (0x1c): Kick-off Rx DMA engine
> >     1-3. REG_HPTXPD (0x28): Kick-off High Priority Tx DMA engine
> >
> > 2. ftmac110:
> >     2-1. REG_TXPD (0x18):  Kick-off Tx DMA engine
> >     2-2. REG_RXPD (0x1c): Kick-off Rx DMA engine
> >
> > Writing an arbitrary value to these registers would trigger the
> > corresponding DMA engine.
> >
> >> You work at Faraday, so maybe you have the definitive answer to this :).
> >>
> >> Stefan
> 
> If you're looking for a basic example code, I'll recommend the u-boot drivers,
> The files are available from my own github:
> 
> https://github.com/dantesu1218/u-boot/blob/master/drivers/net/ftgmac100.c
> https://github.com/dantesu1218/u-boot/blob/master/drivers/net/ftmac110.c

Both your u-boot and the Linux driver for ftmac110 do not kick the NIC.
They simply set the hw owner bit in the rx descriptor.

As Peter and Anthony discussed previously, this design does not lend
itself nicely to emulation because QEMU has to poll or try to trap
memory accesses (which we don't do today).

Normally, we'd like to stop host tap device rx when the emulated NIC has
no rx buffers.  When the guest refills rx buffers we can restart rx.
All this happens without polling if the guest kicks the NIC to refill rx
buffers.

I think Peter's suggestion earlier in this thread needs to be used.

Stefan