lkml.org 
[lkml]   [1996]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kmalloc of dma-memory
From
Date
>>>>> "Albert" == Albert Cahalan <albert@ccs.neu.edu> writes:

>> The problem is MAX_DMA_ADDRESS which is used by kmalloc to determine
>> what memory area can be allocated as DMA'able memory. For instance on
>> the Amiga, the DMA-area depends on the actual device and therefore it
>> would be better to specify a DMA-mask as an optional parameter to
>> kmalloc instead of letting kmalloc use a static value as it does now.

[snip]

>> My suggestion is that an extra, optional, parameter is added to
>> kmalloc so it is possible to specify the dma-boundary when calling
>> kmalloc, and then let kmalloc use this boundary to allocate DMA'able
>> memory when the parameter is added to the kmalloc call and let it
>> rely on the old method when it is not.

Albert> Do what the PC does with ISA (16MB max) and PCI (4GB max).
Albert> #define MAX_DMA_ADDRESS 0x1000000 (BTW, isn't that off by one?
Albert> Maybe 0xffffff.)
Albert> For your good card use something else, maybe this:
Albert> __get_free_pages(priority, gfporder, max_addr)

To me the PCI solutions sounds more like a hack than a real solution to
the problem.

Anyway the problem is not in our low-level drivers but rather in the
mid/high-level SCSI-code, for instance in scan_scsis() where mem is
alloc'ed for SCpnt but no check is made to see if SCpnt == NULL, which
results in a nasty crash.

Of course I could hack scsi_init_{malloc,free} for the m68k port, but I
still think that is more a work-around rather than a real solution.
Jes


\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2011 Jasper Spaans