TTM questions.

James Simmons jsimmons at
Tue Dec 28 13:27:45 PST 2010


	So I recently got my new motherboard with a AGP port for continued 
development of 3Dfx KMS. Well this board comes with a built in VIA 
based IGP. Well that chipset is poorly supported so I started to work on 
the via drm driver. Currently I'm porting it to the TTM infrastructure.
	So the first step is a xxx_ttm_global_init. In fact I made a 
"generic" function for this. Will submit a patch at a later date. Second 
step was to create the ttm_bo_device via ttm_bo_device_init. This appears 
to be map to each graphics card in the system. After this you begin 
calling ttm_bo_init_mm for each different memory region of the card. So 
for the via chipset I managed to do this for the framebuffer,mmio region, 
and AGP. That was the easy part.
	Now I'm attemping to create the needed ttm_buffer_object for when 
the user request a memory region via ttm_bo_init, actually I'm using 
ttm_bo_create. So currently the driver fails to create the ttm_buffer_object
due to having a invalid placement. To fix this issue I need to sort some 
things out. What I have noticed is in ttm_buffer_object we have a field,
struct ttm_mem_reg mem, which appears to represent the region this 
ttm_buffer_object represents. We also have ttm_bus_placement which is 
apart of ttm_mem_reg. ttm_mem_reg represents some memory region handled 
by one of the ttm_mem_type_managers. Now the confusing part is ttm_bo_mem_compat.
How  does the placement relate to the ttm_mem_reg? Also I noticed in the 
radeon and nouveau driver you have something like this in a xxx_bo struct.

strcut ttm_placement placement
u32 placements[3];
u32 busy_placements[3];

Do each of those placements map to the different type of memory regions 
that where registered via ttm_bo_init_mm? If that is the case why are
placements not apart of ttm_mem_type_manager. Their seems to be a relation 
to the ttm_mem_type_manager flags and the flags to the placements. Is this 
correct? Could then placements be generated from the flags of the 

More information about the dri-devel mailing list