From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 22 Feb 1999 11:53:54 +1100

Re: RFC: Abstract register handling in KGI

Jon M. Taylor writes:

>  	I belive I have come up with a decent design for such a framework.  
>  It consists of the following basic underlying abstractions:
>  
>  * Register I/O spaces.  This is already handled by the underlying KGI
>  bus/system abstraction, which will be even better in Steffen's new KGI 0.9. 
>  It needs virtualization, however.  A register I/O space is a linear chunk of
>  registers and sub-I/O spaces with associated metadata.  Think of I/O spaces
>  as register sets with common properties or behaviors.
  
OK, but how are the spaces defined, and how are they programmed with ?
Something like this: ?

   #define REGSPACE_VGA_SEQ  0x1234
   #define REGSPACE_VGA_GRC  0x4567
   ....

>  * Registers, which are bitstrings of arbitrary length.  A register can be
>  physical or virtual.  Physical registers are those which are directly
>  adressable as a single unit by the hardware.  Virtual registers are composed
>  of a set of bitstrings, each of which can come from any set of bits in any
>  register(s), physical or virtual.  Virtual registers can be super-registers
>  (like a PLL M value composed of 22 bits in three 8-bit registers) or
>  sub-registers (like when the top four bits of an 8-bit register hold the DAC
>  mode and the lower three hold clock control bits or something).  Registers
>  also have associated metadata.
  
Sounds good, but again how are they defined and used ?  More #defines
(one for each meta-register) ?

Also, does each register-set contain a fixed set of registers (so that
register-sets exist globally between all drivers), or is each register-
set just local to a particular driver ?

>  * I/O operations.  These are basic primitive operations that can be 
>  applied to physical and virtual I/O spaces and physical and virtual 
>  registers: Read, write, read-modify-write, remap, etc.  Each op has a 
>  function hook associated with it, much as a kgi_display can have a 
>  set_origin() hook.
 
How do you handle read-only and write-only registers ?  

I don't know how KGI does it, but I think for write-only registers there
should be an in-memory copy of the last value written (which is returned
by a subsequent read).

Read only is easy I suppose: have a dummy write function that always
returns an error, yeah ?

>  * Metadata.  Registers and register I/O spaces can represent an almost
>  infinite number of different data types, and furthermore each data type can
>  be handled in a number of different ways.  In order for the driver to be able
>  to divide the hardware resources into whatever resource abstractions it needs
>  to and still be able to do everything it needs to do with those 
>  resources, a matadata hook must be provided.
 
This bit I don't understand -- aren't you just abstracting each register
into an integer of so-many-bits ?

>  	Hierarchical state maintanance and coordinated flushing of this
>  complexity is a nightmare to make work correctly when things like interrupts
>  come into play, because the number of potential state domain clashes grows
>  very large very rapidly.  The only way to be able to coordinate all that 
>  crap without losing your mind and/or having your driver loaded with edge 
>  condition bugs is to abstract the hardware and formalize the maintenance 
>  and representation of hardware state domains.
  
Yes I definitely agree that you need to abstract the hardware (thinly of
course), so I want to understand your proposal as much as possible.
What I have in mind (which may be complete crap) is having a COM
interface for each video card (well the modular bits anyway, like KGI)
with a great big set of functions of reading and writing each
meta-register (e.g. vertical total).

Something else just came to mind, will you treat the framebuffer (and
other buffers) like one REALLY BIG register ?  (or maybe a register-set
where each register (numerically indexed) is a pixel ??).

>  END OF SPEW
>  
>  	Whew.  Feedback on this stuff is most welcome.  I have high hopes for
>  this idea.  I intend to begin implementing such a scheme, bit by bit, in the
>  KGI driver I am working on at Creative right now.

BTW, you'll be working on this at Creative, so what are the chances that
Creative will look at your scheme (when finished) and say "Hey this is
great stuff ! I think we'll use it in all our drivers, and the open
source community can go and get stuffed !" ? :-)

Cheers,
___________________________________________________
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/