On 5/16/07, David Brownell <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
