On 17 Sep 03 at 19:36, Stevie-O wrote:Actually, I specified __get_free_pages(1) 80 times because I don't know if the card's SG can actually support 160 separate buffers (I'm certain it can do at least 80 though).
My thinking is this: I want to use __get_free_pages(1) 80 times to get the
160 pages, then passed those 80 pieces to the card (it's known the card can
handle requests with that many pieces). Then I want to create a *virtually*
contiguous 160-page mapping, so the postprocessing code in the driver can
view the 80 2-page sub-buffers as one big consecutive 160-page buffer. Doing this would (a) make for more efficient use of memory, and (b) leave
the larger piles of contiguous pages to the drivers of cards that actually
require them.
If you'll use __get_free_pages(0) 160 times, you should be able to use
vmap() in 2.[456].x.
I must say that I do not understand why it checks for size > (max_mapnr << PAGE_SHIFT) in 2.4.x, or for count > num_physpages
in 2.6.x (as there is nothing wrong with mapping same page several
thousand times, or is it bad? with 32MB host you have plenty of
unused VA space in the kernel...), but it should not hurt you as you
need distinct physical pages.
On other side, maybe that using SG even for driver operations is not
that complicated. Do not forget that on bigmem boxes you have only
128MB area for vmalloc/vmap/ioremap, so you can quickly find that
there is not 640KB continuous area available.