lkml.org 
[lkml]   [2002]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] generic device DMA implementation
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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.078 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site