Subject: Re: CVS commit: syssrc
To: Jason R Thorpe <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 02/24/2001 16:14:36
On Sat, 24 Feb 2001, Jason R Thorpe wrote:
> On Sun, Feb 25, 2001 at 01:30:01AM +0200, Matthew Jacob wrote:
> > Log Message:
> > Now that the underlying code for bus_dmamap_sync appears to do the
> > right thing, don't use the illegal and "just worked by chance" addition
> > of BUS_DMA_COHERENT to bus_dmamap_load_raw. There still is a necessity
> > to add to the architecture to allow one to hint that this should be
> > a cache coherent mapping.
> There is -- when you call bus_dmamem_map(). But, it's only a hint
> (because on some systems, you *can't* make things cache coherent).
Yes. I know.
> When you bus_dmamap_load() memory that's mapped with COHERENT, the
> machdep code could notice that it's loading coherently-mapped memory,
> which could store a flag in the machdep part of the dmamap, which could
> then be tested in bus_dmamap_sync().
I think the problem here is that there's no ordering requirement stated that
says that bus_dmamap_load[_raw] has to occur after bus_dmamem_map. I can see
that this would work okay if this was required.
There's also nothing that can be use to give a hint to bus_dmamem_alloc that
it should make an allocation such that a subsequent bus_dmamem_map with
BUS_DMA_COHERENT would succeed sensibly
That is, unless you count the page-size allocation rule for bus_dmamem_alloc
to be a sufficient guard. I don't- you assume that all you need to do is to
rip a cpu mapping away from a page to guarantee you can make a piece of memory
sync-able. This may not be a reasonable efficient mechanism. It'd be better to
be able to tell bus_dmamem_alloc what you want the memory for to begin with.