On Thu, 11 Jan 2001, Paul Powell wrote:
> Our driver is trying to allocate a DMA buffer to flash
> an adapter's firmware. This can require as much as
> 512K ( of contiguous DMA memory ). We are using the
> function __get_free_pages( GFP_KERNEL | GFP_DMA, order
> ) . The call is failing if 'order' is greater than 6.
> The problem is seen on systems with system memory of
> only 64MB. It works fine on systems with more memory.
> Does it make sense that a system with 64MB would not
> have 512K ( contiguous ) available? The most that can
> be allocated successfully on the 64MB system appears
> to be 256K. (Nothing else is running that would eat
> up 64MB of memory).
>
> Does this make sense and/or is there another way that
> the DMA memory could be allocated successfully?
>
Are you sure it needs memory? Usually, you need address-space
to flash firmware. Also, in recent months, I've evaluated a
lot of NVRAM from flash to single-bit SEEPROM. I have never
seen anything that would `know` how to flash from DMA.
Typically, with NVRAM, you scribble some 0xaaa, 0x555, 0xetc, at some
specified offset, then you write a single byte/word/longword (depending
upon its addressing), at the location to program. Then you loop, waiting
for it to "take", then you do the next. All stuff you would never do with
DMA.
If all you need is a kernel buffer to store the stuff that will be
written to NVRAM, then just use kmalloc(). It is virtual and will
seem contiguous to your driver.
If you have to 'bus-master' data from your buffer to the NVRAM, you
just do it one page at a time, using the same page.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
