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

[Kuo-Jung Su]

2013/2/19 Stefan Hajnoczi <address@hidden>:
> 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.
>

Descriptor based Ethernet MAC usually triggers the Rx DMA by the
hardware MII pin
called CRS (MII Carier Sense), so most of them, only has a Tx Poll
register, no Rx Poll.

For example:

1. BCM963xx builtin Ethernet mac

    
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/net/ethernet/broadcom/bcm63xx_enet.c;h=39387d67b7222beee3a5fd122218c645851f90c6;hb=19f949f52599ba7c3f67a5897ac6be14bfcb1200

2. RealTek 8139C+:

    
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/net/ethernet/realtek/8139cp.c;h=5ac93323a40cfa40995fbbaa3a4bc5ce0c3bea0a;hb=19f949f52599ba7c3f67a5897ac6be14bfcb1200

3. RDC R6040:

    
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=drivers/net/ethernet/rdc/r6040.c;h=63c13125db6c9d0a58dcc70438d4af4058bcfd1e;hb=19f949f52599ba7c3f67a5897ac6be14bfcb1200

It's also a mystery to me that why we have a Rx Poll register in
Faraday Ethernet MACs.
They're all designed long before I participate in Faraday. I guess
this rx poll register might be
designed for test purpose only.

> 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



--
Best wishes,
Kuo-Jung Su