Re: [PATCH] Jazzsonic driver updates

[Finn Thain <fthain@telegraphics.com.au>]

On Wed, 15 Jun 2005, Ralf Baechle wrote:

> On Thu, Jun 16, 2005 at 12:02:33AM +1000, Finn Thain wrote:
> 
> > > The Jazz DMA hardware is an MMU that translates virtual DMA to 
> > > physical addresses.  It's virtual DMA address space is 16MB in size, 
> > > it's page size is 4kB.  That's a set of capabilities that nicely 
> > > translates into the DMA API.
> > 
> > I gather that someone has already put this hardware under the control 
> > of the generic DMA API?
> 
> That's being worked on.

OK, I guess I should code for it then. It is difficult to avoid converting 
the sonic core to the DMA API if I'm going to adopt it for macsonic. It 
just means that my changes to jazzsonic can't be tested yet, and so my 
work will remain out-of-tree.

> > > > Would I be right to say that vdma_{alloc,free}() can be changed to 
> > > > dma_{,un}map_single? The other Jazz specific routine that sonic 
> > > > uses is vdma_log2phys, and I don't know if that has a better 
> > > > alternative.
> > > 
> > > The use of that call should simply be eleminated entirely.  DMA API 
> > > functions such as dma_alloc_coherent or dma_map_single will return a 
> > > dma_handle which along with the virtual address returned is 
> > > everything ever needed to program a DMA engine.
> > 
> > The sonic chip stores packets inside a "receive resource area" at a 
> > physical address that depends on the packets it previously stored 
> > there.
> > 
> > So the chip determines that address and the driver has to convert it 
> > from a physical to a virtual address with KSEG1ADDR(vdma_log2phys(x)), 
> > in order to memcpy the received packet.
> 
> Wrong.  The Sonic only does DMA to DMA addresses which will be 
> translated to physical addresses by the IOMMU.  That is it never ever 
> deals with physical addresses directly.

OK.

> When transmitting or receiving a buffer it has to be mapped into the DMA 
> controller's address space first, for example through dma_map_single.
> 
> As the result you will obtain a DMA address which you will feed to the 
> Sonic or put into a rx or tx ring, whatever.  And you need to remember 
> it in the driver private data, just like the virtual address of the 
> buffer or the struct sk_buff pointer.  So all you need is to look at 
> your private data to find that virtual address you need for memcpy.

Not quite. The virtual address you are talking about is the beginning of 
the receive resource area, which is mapped as you describe. But, the chip 
then decides where in that area the recieved packet gets buffered, and the 
chip reports the address of that packet as a pointer. And this is why 
vdma_log2phys is used to convert the location of the packet (in IOMMU 
virtual address space) into CPU virtual address where the packet can be 
found by memcpy. And that is why I was asking for an alternative to 
vdma_log2phys. But I think calculating the offset of the packet with some 
IOMMU virtual pointer arithmetic will suffice in this case, since the 
initial mapping is probably going to be linear.

-f

> tg3 is a reasonable example of a driver - albeit not a simple one.
> 
> > >From what code I've looked at, and from what you've told me, I'm guessing 
> > that bus_to_virt() won't cut it here (?)
> 
> bus_to_virt and virt_to_bus are shooting offences these days, no less.
> 
>   Ralf
> -
> To unsubscribe from this list: send the line "unsubscribe linux-mips" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/