Re: TTM and initialization

[<th...@tu...>]

Jerome Glisse wrote:

> Thomas Hellström wrote:
>
>> Thomas Hellström wrote:
>>
>>> Jerome Glisse wrote:
>>>
>>>  
>>>
>>>> Hi Thomas,
>>>>
>>>> I am in a situation where i need to allocate vram for the gart 
>>>> table ie i can't (in fact i can
>>>> if i avoid using the memory manager and don't let the manager 
>>>> handle this part of stolen
>>>> vram but i prefer to go throught the allocator if possible) 
>>>> initialize ttm until i allocated this
>>>> vram. I have been looking through call chains in drm_ttm.c and 
>>>> drm_bo.c and it seems to
>>>> me that drm_ttm_init might not be call until ttm is firstly used so 
>>>> i think i am fine but as
>>>> i might have miss some calls i would like your expert stance on 
>>>> this :)
>>>>
>>>> So does this looks good for initialization:
>>>> drm_bo_driver_init(dev);
>>>> drm_bo_init_mm(dev, DRM_BO_MEM_VRAM, 0, vramsize);
>>>> ret = drm_buffer_object_create(dev, gart_table_size, 
>>>> drm_bo_type_kernel,
>>>>                                                  DRM_BO_FLAG_READ | 
>>>> DRM_BO_FLAG_WRITE |
>>>>                                                  
>>>> DRM_BO_FLAG_MEM_VRAM |
>>>>                                                  
>>>> DRM_BO_FLAG_NO_EVICT |
>>>>                                                  
>>>> DRM_BO_HINT_DONT_FENCE, 0, 0x1, 0,
>>>>                                                  
>>>> &dev_priv->gart_table);
>>>> /* now and only now create_ttm_backend_entry can be called */
>>>> drm_bo_init_mm(dev, DRM_BO_MEM_TT, 0, numpages);
>>>>
>>>> Cheers,
>>>> Jerome Glisse
>>>>   
>>>
>>>
>>> Hi, Jerome.
>>>
>>> Yes. This is OK. In principle it should be OK to add and remove a 
>>> memory area at any point.
>>>
>>> If you specify a memory type that's not added, let's say you also 
>>> specify also TT in the above create call, it would just not be 
>>> considered.
>>>
>>> Note that the code may still create TTMS for local (system) memory 
>>> buffers. However they should never be moved into the AGP memory area.
>>>
>>> /Thomas
>>>  
>>>
>> Hmm.
>> You should note however, that IF the X server has a policy to clean 
>> out VRAM and TT when you switch virtual terminal, the kernel will 
>> complain about the NO_EVICT buffer and throw it out.
>>
>> This means that if you want the X server to clean this up while 
>> VT-switching you probably need to implement a driver specific IOCTL that
>>
>> 1) Takes the bm_lock in write mode.
>> 2) Cleans the TT memory and removes the TT memory type.
>> 3) Unpins the NO_EVICT VRAM buffer
>> 4) Cleans the VRAM memory.
>>
>> And upon switching VT back,
>>
>> 1) Pins the VRAM buffer.
>> 2) Re-adds the TT memory type.
>> 3) Releases the bm_lock.
>>
>> /Thomas
>>
>>
> Right now i am in the wonderful world of modesetting where VT switch 
> doesn't exist :) just load/unload and
> suspend/resume where i need to take care to backup this table.
>
> Another question is what happen if card_page_size < 
> system_ram_page_size and system_ram_page_size isn't
> a multiple of card_page_size. So if i am right in such situation you 
> can't linearly map system ram ie if you copy
> data from vram to ttm there will be gap in data btw each page, also 
> you would need size_to_map/card_page_size
> pages to be able to copy and this will be higher than 
> size_to_map/system_ram_page_size. I don't think i have
> such case but as i am always assuming the worse :) i am trying to 
> understand if such situation won't be problematic
> for the memory manager.

It probably will. For now We've just ignored this case, but I'd prefer 
to have the TTM backend deal with that situation, though  we probably 
also need to tell the aperture space manager how to deal with alignments 
and sizes.

/Thomas