Re: tg3 support broken on PPC, a workaround

["Michael Chan" <mchan@broadcom.com>]

On Tue, 2005-05-10 at 12:12 -0700, David S.Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Subject: Re: tg3 support broken on PPC, a workaround
> Date: Tue, 10 May 2005 09:52:46 -0700
> 
> > In the new code, the DMA write bursts will disconnect at multiples of
> > cache lines instead of 1 cache line. And DMA read bursts will not
> > disconnect at cache line boundaries.
> 
> We really should be disconnecting at single cacheline boundaries
> on RISC systems.  The PCI controllers on RISC machines are
> going to disconnect the tg3 when it crosses a cache line
> boundary, so all these setting do is waste PCI bandwidth.
> 
> From the sparc64 PCI controller programmer's manual:
> 
> "When a DMA burst transfer attempts to go past a cache line (64B)
>  boundary, U2P generates a disconnect.  This should cause the
>  master device to attempt the transaction again beginning at the
>  address of the next untransferred data."
> 

This should be fine. If the bridge requires termination at every cache
line, the bridge (target) will initiate disconnect and data will
terminate.

There is clear benefit in doing longer bursts when the bridge can handle
it.

It was explained to me that on some risc systems such as ppc, and
assuming the bridge can handle long DMA bursts, it is still best to
disconnect at page or cache line boundaries. The reason is that if the
burst stops at any arbitrary address, the bridge has to refetch the
cache line and often the mapping information. Disconnecting at multiple
cache lines is to address this problem while still achieving longer DMA
bursts.