Re: [PATCH] atmel_spi: Pass correct DMA address to controller

["Håvard Skinnemoen" <hskinnemoen@gmail.com>]

On 5/16/07, David Brownell <david-b@pacbell.net> wrote:
> On Wednesday 16 May 2007, Haavard Skinnemoen wrote:
> > -     tx_dma = xfer->tx_dma;
> > -     rx_dma = xfer->rx_dma;
> > +     tx_dma = xfer->tx_dma + xfer->len - len;
> > +     rx_dma = xfer->rx_dma + xfer->len - len;
> >
> >       /* use scratch buffer only when rx or tx data is unspecified */
> > -     if (rx_dma == INVALID_DMA_ADDRESS) {
> > +     if (!xfer->rx_buf) {
>
> This test ...
>
> >               rx_dma = as->buffer_dma;
> >               if (len > BUFFER_SIZE)
> >                       len = BUFFER_SIZE;
> >       }
> > -     if (tx_dma == INVALID_DMA_ADDRESS) {
> > +     if (!xfer->tx_buf) {
>
> ... and this one must not assume that the relevant buffer
> is always NULL when the tx_dma has been set up.  Keep the
> test against INVALID_DMA_ADDRESS, but fetch the address
> from the spi_transfer.

No it doesn't -- it's the other way around. It assumes that if
xfer->tx_buf is NULL, the user didn't provide a buffer so it has to
use the scratch buffer instead. The driver never does PIO transfers,
so if tx_buf is valid, tx_dma ought to be valid  too. This is taken
care of elsewhere by calling dma_map_single() if the user provided a
virtual pointer but not a dma address.

Checking for an invalid cpu-virtual pointer really should be
equivalent to checking for an invalid DMA address at this point.

I could perhaps add else blocks to those two ifs and add the offset to
the respective dma addresses there instead if it makes it clearer. The
tests are supposed to be the same as before, but I had to change them
one way or another because of the added offset (which would make an
invalid dma address non-invalid.)

> It's legit to set up cpu-virtual (for PIO) and dma addresses
> for each buffer, since the upper layer driver has no way to
> know if the underlying controller driver is DMA-capable, or
> for that matter PIO-capable.

Yes, but are there any drivers that will provide a valid dma address
and a NULL cpu-virtual pointer? That would indeed break my
assumptions, but it would also break any PIO-only drivers, wouldn't
it?

Haavard