[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1180018752.3692.16.camel@mulgrave.il.steeleye.com>
Date: Thu, 24 May 2007 09:59:12 -0500
From: James Bottomley <James.Bottomley@...elEye.com>
To: "Salyzyn, Mark" <mark_salyzyn@...ptec.com>
Cc: Aubrey Li <aubreylee@...il.com>,
Christoph Lameter <clameter@....com>,
Bernhard Walle <bwalle@...e.de>, linux-scsi@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: RE: [PATCH] [scsi] Remove __GFP_DMA
On Thu, 2007-05-24 at 09:24 -0400, Salyzyn, Mark wrote:
> So, is the sequence:
>
> p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
> . . .
> addr = pci_map_single(dev->pdev, p, upsg->sg[i].count,
> data_dir);
>
> Going to ensure that we have a 31 bit (not 32 bit) physical address?
No, unfortunately. Implementing kmalloc_mask() and kmalloc_dev() was
something I said I'd do ... about two years ago.
> If not, then I reject this patch. We can not consider replacement with
> pci_alloc_consistent until it works on AMD respecting the DMA masks.
It should, I believe ... x86_64 has a complex allocation scheme where
for masks < 32 bit it first tries in GFP_DMA32 and sees if it gets lucky
before falling back to GFP_DMA. i386 just goes straight to GFP_DMA.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists