> One question is whether to support only one of them, or allow both.
> In either case the DMA-mapping.txt will need to touch on the issue.
>
> Another important issue is from where do these issues originate?
>
> This stuff rarely happens most of the time because block buffers and
> networking buffers are what are fed to the chip.
I think the examples Oliver found related mostly to device control
and status tracking.
> I still think it is crucial that we not put this alignment garbage
> into the drivers themselves. Driver writers are going to get it
> wrong or be confused by it.
I guess I don't see a way around exposing some of it. Do you?
Even the (b) option requires drivers to know they can't pass pointers
to the inside of a structure, AND that memory right after the end of
an I/O buffer is unavailable. That exposes the issue. Although it
doesn't provide help to manage it, as (a) does, or detect it.
Should the dma mapping APIs try to detect the "DMA buffer starts in
middle of non-coherent cacheline" case, and fail? That might be
worth checking, catching some of these errors, even if it ignores
the corresponding "ends in middle of non-coherent cacheline" case.
And it'd handle that "it's a runtime issue on some HW" concern.
Or then there's David Woodhouse's option (disable caching on those
pages while the DMA mapping is active) which seems good, except for
the fact that this issue is most common for buffers that are a lot
smaller than one page ... so lots of otherwise cacheable data would
suddenly get very slow. :)
- Dave
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:22 EST