From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Mon, 3 Aug 1998 23:19:33 +0200 (MEST)

Re: Paged modes...

Hi !

> Personally I'm not sure if I like these defines and the way the
> fast_remap handler outthinks you.  For example if you want to
> use a sliding bank you are out of luck because the code
> that calls your page fault set_offset function has decided
> that no matter what value the set_offset function returns for the
> offset, it will set the page to a multiple of psize based on the faulting
> address, so you essentially have sliced the window into N sections and 
> can choose one of them, but you can't place your window half on one 
> section and half on the next.  You are also not allowed to change 
> the size of your window.

BTW: This is something that bothered me for a while now.

Steffen: As you are redesigning KGI, could you maybe try to change the
mmaping callback procedure accordingly ?

This is basically how it worked in old scrdrv (you might remember the
lengthy discuaaion we had on that topic), just abstracted as you wanted 
it (and what is the right thing to do) :

- The callback function should get a logical offset into the area which is
  derived from the address that caused the fault.
  Traditional beahviour/porting old drivers would then just be a matter of
  page=offset/PAGESIZE.
- The callback function should return a struct describing what it actually
  did, i.e. the new "logical->physical" mapping i.e. something that says
  "o.k. - you requested access to logical addr. 0x12345 - thus I mapped 
   the logical addresses 0x10000-0x1ffff to physical bus address
   0xa0000-affff".

I think this would be more flexible for cards with complex page-schemes
and help, if the library side hints the driver for certain operations that
would prefer a "map new page low/high/middle" scenario.

CU,ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =