Message-Id: <200212061648.gB6GmNX01862@localhost.localdomain>
To: "David S. Miller" <davem@redhat.com>
cc: James.Bottomley@SteelEye.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] generic device DMA implementation
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 06 Dec 2002 10:48:23 -0600
From: James Bottomley <James.Bottomley@steeleye.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1494
Lines: 32

> These systems simply do not exist.

Yes, they do.  The parisc pcxs and pcxt processors are the prime example that 
has annoyed me for a while.  This has no ability to control the cache at the 
page level  (it doesn't even seem to allow fully disabling the processor 
cache---not that you'd want to do that).  The result is that it cannot ever 
return consistent memory, so pci_alloc_consistent always fails (see 
arch/parisc/kernel/pci-dma.c:fail_alloc_consistent).  I have one of these 
machines (A HP9000/715) and I maintain the driver for the SCSI chip, which 
also needs to work efficiently on the intel platform, which is what got me 
first thinking about the problem.

Let me say again:  I don't envisage any driver writer worrying about this edge 
case, unless they're already implementing work arounds for it now.

I plan to maintain the current pci_ DMA API exactly as it is, with no 
deviations.  Thus the dma_ API too can be operated in full compatibility mode 
with the pci_ API.  That's the design intent.  However, I want the dma_ API to 
simplify this driver edge case for me (and for others who have to maintain 
similar drivers), which is why it allows a deviation from the pci_ API *if the 
driver writer asks for it*.

James


-
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/