Re: [RFC] generic device DMA implementation

David Gibson (david@gibson.dropbear.id.au)
Thu, 5 Dec 2002 16:05:36 +1100


On Wed, Dec 04, 2002 at 09:13:33PM -0600, James Bottomley wrote:
> david@gibson.dropbear.id.au said:
> > The point is, there has to be an advantage to using consistent memory
> > if it is available AND the possibility of it not being available.
>
> I'm really thinking of this from the driver writer's point of view. The
> advantage of consistent memory is that you don't have to think about where to
> place all the sync points (sync points can be really subtle and nasty and an
> absolute pain---I shudder to recall all of the problems I ran into writing a
> driver on a fully inconsistent platform).
>
> The advantage here is that you can code the driver only to use consistent
> memory and not bother with the sync points (whatever the cost of this is).
> Most platforms support reasonably cheap consistent memory, so most people
> simply don't want to bother with inconsistent memory if they can avoid it.
>
> If you do the sync points, you can specify the
> DMA_CONFORMANCE_NON_CONSISTENT level and have the platform choose
> what type of memory you get. For a platform which makes memory
> consistent by turning off CPU caching at the page level, it's
> probably better to return non-consistent memory if the driver can
> cope with it.

But if you have the sync points, you don't need a special allocater
for the memory at all - any old RAM will do. So why not just use
kmalloc() to get it.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson
-
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/