On Wed, 2007-05-23 at 20:38 +0100, Alan Cox wrote:
> On Wed, 23 May 2007 15:17:08 -0400
> "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
>
> > The 31 bit limit for some of these cards is a problem, we currently only
> > do __GFP_DMA for bounce buffer sg elements allocated for user supplied
> > referen
On Thu, 2007-05-24 at 10:22 -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, James Bottomley wrote:
>
> > The idea was basically to match an allocation to a device mask. I was
> > going to do a generic implementation (which would probably kmalloc,
> > check the physaddr and fall back to GFP
On Thu, 24 May 2007, James Bottomley wrote:
> The idea was basically to match an allocation to a device mask. I was
> going to do a generic implementation (which would probably kmalloc,
> check the physaddr and fall back to GFP_DMA if we were unlucky) but
> allow the architectures to override.
H
On Thu, 2007-05-24 at 10:00 -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, James Bottomley wrote:
>
> > > 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 ... abou
On Thu, 24 May 2007, James Bottomley wrote:
> > 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.
Tell me more about these ideas.
-
To unsubscribe from
On Thu, 24 May 2007, 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?
Only if you ha
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?
N
Cc: Bernhard Walle; [EMAIL PROTECTED]; Andrew
> Morton; linux-kernel@vger.kernel.org; James Bottomley
> Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
>
>
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
>
> > That didn't used to work right on the AMD boards when I tried it last as
> > we ended up with a buffer that was mapped by the IOMMU for some reason
> > and that was not below 2GB.
>
> The physical address you mean? If that is still happening then it needs
> to get fixed. The allocation should
Alan Cox wrote:
On Wed, 23 May 2007 15:17:08 -0400
"Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
The 31 bit limit for some of these cards is a problem, we currently only
do __GFP_DMA for bounce buffer sg elements allocated for user supplied
references in ioctls.
I figure we should be using pci_al
On Wed, 23 May 2007 15:17:08 -0400
"Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
> The 31 bit limit for some of these cards is a problem, we currently only
> do __GFP_DMA for bounce buffer sg elements allocated for user supplied
> references in ioctls.
>
> I figure we should be using pci_alloc_consi
; Bernhard Walle; [EMAIL PROTECTED];
Andrew Morton; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [scsi] Remove __GFP_DMA
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
&
On Wed, 2007-05-23 at 11:55 -0400, Robert P. J. Day wrote:
> On Wed, 23 May 2007, James Bottomley wrote:
>
> > I'll defer to Mark on this one. However, please remember that you
> > can't just blindly remove GFP_DMA ... there are some cards which
> > require it.
> >
> > Aacraid is one example ...
On Wed, 23 May 2007, James Bottomley wrote:
> I'll defer to Mark on this one. However, please remember that you
> can't just blindly remove GFP_DMA ... there are some cards which
> require it.
>
> Aacraid is one example ... it has a set of cards that can only DMA
> to 31 bits. For them, the GFP_
On Wed, 2007-05-23 at 10:41 +0800, Aubrey Li wrote:
> On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 21 May 2007, Bernhard Walle wrote:
> >
> > > [PATCH] [scsi] Remove __GFP_DMA
> > >
> > > After 821de3a27bf33f11ec878562577c586c
On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
> DMA buffer any more in sd.c.
>
> Signed-o
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
> a
> DMA buffer any more in sd.c.
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Great tha
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
drivers/scsi/sd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/driver
18 matches
Mail list logo
