at91sam9g20: Upcoming Patches

[Bernd Walter]

On Mon, Jul 19, 2010 at 06:22:02PM -0600, M. Warner Losh wrote:
> In message: <AANLkTilj6crfPkCfViYU8LkFxZ6LY8WxRAghiZXaSDn_ at mail.gmail.com>
>             Yohanes Nugroho <yohanes at gmail.com> writes:
> : On Mon, Jul 19, 2010 at 10:36 PM, Bernd Walter <ticso at cicely7.cicely.de> wrote:
> : >> if_ate.c:
> : >>
> : >>    * Support for sam9 "EMAC" controller.
> : >>    * Support for rmii interface to phy.
> : >
> : > RM9200 ate requires specific DMA alignment, which required a few
> : > realign copys.
> : > This isn't neccessary for most other AT91 devices and for sure
> : > not with any AT91SAM9x device.
> : > Not sure if all of them are automatically avoided - you might want
> : > to verify the code about this point.
> : > There is also RBNA workaround, which should be RM9200 specifc,
> : > which shouldn't be triggered with others, but you might want to save
> : > a few bytes codespace.
> : 
> : And looking at Linux's code, they separate for the RM9200 driver and
> : newer AT9 (macb) drivers. I haven't looked deeply, but it seems that
> : if we are going to support all variations of RM9200 PHY for link
> : checking purpose, there will a lot of RM9200 specific code.
> 
> Unlike Linux, all that's abstracted out in FreeBSD, so it is easy to
> support dozens of different PYHs.  In fact, I don't think there's any
> PHY specific code in the current ATE driver...

No there isn't - at least not with the SAM9260.
I know the ATE in SAM7X256/512 very well and beside that some revs of
them have broken RMII support it is the same ATE as in SAM9260.

> : I agree that there are many things in common between these two
> : drivers, but I don't know if it is a good idea to keep everything in
> : one file.
> 
> Yea, I worry about the performance on newer parts of the older code,
> which has stinky performance due to hardware limitations.

The performance has two reasons.
First the fact that the RM9200 ATE can't DMA into non 4-byte aligned
buffers, which requires copying and memory bandwidth is rather slow,
which especially sucks because of the required copy'ing.
IP headers are no n*4 bytes, so you want a 2 byte offset in your
receive buffers otherwise IP code copy'es received buffers.
On sending AFAIK the ATE driver copy'es data into 4 alignment.
The memory interface on SAM9 is much faster because it is DDR,
higher clocked and with it's bus matrix e.g. DMA can access DDRAM
and CPU IO in parallel.
I don't see a technical reason to have different source files.
A few things can be tuned on compiletime, but this is only
a win to save code size - from the runtime point a few rev-checks
in hybrid kernel shouldn't hurt.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.