2013/2/19 Stefan Hajnoczi <stefa...@gmail.com>:
> On Tue, Feb 19, 2013 at 09:43:27AM +0800, Kuo-Jung Su wrote:
>> 2013/2/19 Kuo-Jung Su <dant...@gmail.com>:
>> > 2013/2/18 Stefan Hajnoczi <stefa...@gmail.com>:
>> >> On Mon, Feb 18, 2013 at 05:44:38PM +0800, Kuo-Jung Su wrote:
>> >>> 2013/2/18 Stefan Hajnoczi <stefa...@gmail.com>:
>> >>> > On Wed, Feb 06, 2013 at 05:45:19PM +0800, Kuo-Jung Su wrote:
>> >>> >> From: Kuo-Jung Su <dant...@faraday-tech.com>
>> >>> >>
>> >>> >> 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 <dant...@faraday-tech.com>
>> >>> >> ---
>> >>> >> 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
