Messages in this thread | | | Date | Thu, 5 Dec 2002 16:05:36 +1100 | From | David Gibson <> | Subject | Re: [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/
| |