Re: [Linux-fbdev-devel] [PATCH] Tile Blitting

[James S. <jsi...@in...>]

Boy this has been tricky to handle. I have been thinking about how to 
handle image blitting from normal memory to texture mappings to tiles.
Then after that I have to make it abstract to fit all these models. 
Pretty much I have come to the conclusion that we have two models.

Model 1: Consistent mappings. 

	In this model we allocate one time a buffer to store image data.
	The fbcon classic is loadfont. It could also be creating texures
	and saving it in a permentant texture map buffer that is present 
        on the card. Same for tiles. We create a bunch of tiles and save 
        them somewhere. We then use a index of some kind later to draw 
	the image.

Model 2: Streaming mappings. 

	This model has us create a temporary memory pool to store data 
	then draw it. After drawing is complete we release the memory. 
	

As you can see the standard imageblit function falls into model 2. At 
present we allocate a static buffer :-( Now for a PCI DMA based card we 
want a hook to allocate a chunck of memory via pci_alloc_consittent. To 
free the memory we use pci_free_consistent. Also for AGP there could be 
hooks just for it. So model 2 can be broken into 2 parts.

A) Memory mangement. We first allocate the memory needed. After drawing
   the image free the memory.

B) Draw the image. This occurs between the two events in A.


Now for model 1. A example would be the matrox fbdev driver for fast 
fonts. We allocate a region to store the font images before using them.
This buffer is pretty much permanent. Then we use indices to tell which
section of the allocated buffer to have the graphics engine use. 


So this is the model I have come up with. The tricky part I haven't 
figured out yet is working with irqs and how to relate fbcon with it. 
Comments?