Yes, I think you should use GFP_DMA32 instead of GFP_DMA.  GFP_DMA
refers to just the first 16MB of memory.

I'd like to make a similar change in ieee1394/dma.c.  Right now, it
allocates large DMA regions with vmalloc().  One reason why that is bad
is because it often returns physical addresses larger than 32-bits,
causing the hardware to use bounce buffers (and is thus slow, and also
happened to expose a bug in swiotlb).

-David

On Sun, 2007-02-04 at 13:05 +0100, Stefan Richter wrote:
> In order to use OHCI physical DMA, all s/g elements, s/g tables, ORBs,
> and response buffers have to reside within the first 4 GB of the
> FireWire controller's physical address space.  Set the correct mask for
> DMA mappings.
> 
> Also ensure that the memory allocated for command ORBs and s/g tables is
> suitable for DMA.
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> Should I use GFP_DMA32 instead of GFP_DMA?
> 
> 
>  drivers/ieee1394/sbp2.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.20-rc5/drivers/ieee1394/sbp2.c
> ===================================================================
> --- linux-2.6.20-rc5.orig/drivers/ieee1394/sbp2.c
> +++ linux-2.6.20-rc5/drivers/ieee1394/sbp2.c
> @@ -477,7 +477,7 @@ static int sbp2util_create_command_orb_p
>  
>       spin_lock_irqsave(&lu->cmd_orb_lock, flags);
>       for (i = 0; i < orbs; i++) {
> -             cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC);
> +             cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC | GFP_DMA);
>               if (!cmd) {
>                       spin_unlock_irqrestore(&lu->cmd_orb_lock, flags);
>                       return -ENOMEM;
> @@ -757,6 +757,11 @@ static struct sbp2_lu *sbp2_alloc_device
>                       SBP2_ERR("failed to register lower 4GB address range");
>                       goto failed_alloc;
>               }
> +#else
> +             if (dma_set_mask(hi->host->device.parent, DMA_32BIT_MASK)) {
> +                     SBP2_ERR("failed to set 4GB DMA mask");
> +                     goto failed_alloc;
> +             }
>  #endif
>       }
>  
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to