Keith Whitwell wrote:
> Keith Packard wrote:
>> I'm writing up some documentation for internal DRM interfaces and came
>> across a couple of interface inconsistencies that seem like they should
>> get fixed before they start getting used a lot more. If these look like
>> good changes, I'll continue to search out other similar issues. I'll
>> just include the header changes in this message.
>>
>>     Make ttm create/destroy APIs consistent. Pass page_flags in create.
>>     
>>     Creating a ttm was done with drm_ttm_init while destruction was done with
>>     drm_destroy_ttm. Renaming these to drm_ttm_create and drm_ttm_destroy 
>> makes
>>     their use clearer. Passing page_flags to the create function will allow 
>> that
>>     to know whether user or kernel pages are needed, with the goal of 
>> allowing
>>     kernel ttms to be saved for later reuse.
>> --------------------------- linux-core/drm_objects.h 
>> ---------------------------
>> index 1dc61fd..66611f6 100644
>> @@ -297,7 +297,7 @@ struct drm_ttm {
>>  
>>  };
>>  
>> -extern struct drm_ttm *drm_ttm_init(struct drm_device *dev, unsigned long 
>> size);
>> +extern struct drm_ttm *drm_ttm_create(struct drm_device *dev, unsigned long 
>> size, uint32_t page_flags);
>>  extern int drm_bind_ttm(struct drm_ttm *ttm, struct drm_bo_mem_reg *bo_mem);
>>  extern void drm_ttm_unbind(struct drm_ttm *ttm);
>>  extern void drm_ttm_evict(struct drm_ttm *ttm);
>> @@ -318,7 +318,7 @@ extern int drm_ttm_set_user(struct drm_ttm *ttm,
>>   * Otherwise it is called when the last vma exits.
>>   */
>>  
>> -extern int drm_destroy_ttm(struct drm_ttm *ttm);
>> +extern int drm_ttm_destroy(struct drm_ttm *ttm);
>>  
>>  #define DRM_FLAG_MASKED(_old, _new, _mask) {\
>>  (_old) ^= (((_old) ^ (_new)) & (_mask)); \
>>
>>
>>
>>
>>     Document drm_bo_do_validate. Remove spurious 'do_wait' parameter.
>>     
>>     Add comments about the parameters to drm_bo_do_validate, along
>>     with comments for the DRM_BO_HINT options. Remove the 'do_wait'
>>     parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
>> --------------------------- linux-core/drm_objects.h 
>> ---------------------------
>> index 66611f6..1c6ca79 100644
>> @@ -546,7 +546,6 @@ extern struct drm_buffer_object 
>> *drm_lookup_buffer_object(struct drm_file *file_
>>  extern int drm_bo_do_validate(struct drm_buffer_object *bo,
>>                            uint64_t flags, uint64_t mask, uint32_t hint,
>>                            uint32_t fence_class,
>> -                          int no_wait,
>>                            struct drm_bo_info_rep *rep);
>>  
>>  /*
>>
>>
>>     Document drm_bo_handle_validate. Match drm_bo_do_validate parameter 
>> order.
>>     
>>     Document parameters and usage for drm_bo_handle_validate. Change 
>> parameter
>>     order to match drm_bo_do_validate (fence_class has been moved to after
>>     flags, hint and mask values). Existing users of this function have been
>>     changed, but out-of-tree users must be modified separately.
>> --------------------------- linux-core/drm_objects.h 
>> ---------------------------
>> index 1c6ca79..0926b47 100644
>> @@ -535,9 +535,8 @@ extern int drm_bo_clean_mm(struct drm_device *dev, 
>> unsigned mem_type);
>>  extern int drm_bo_init_mm(struct drm_device *dev, unsigned type,
>>                        unsigned long p_offset, unsigned long p_size);
>>  extern int drm_bo_handle_validate(struct drm_file *file_priv, uint32_t 
>> handle,
>> -                              uint32_t fence_class, uint64_t flags,
>> -                              uint64_t mask, uint32_t hint,
>> -                              int use_old_fence_class,
>> +                              uint64_t flags, uint64_t mask, uint32_t hint,
>> +                              uint32_t fence_class, int use_old_fence_class,
>>                                struct drm_bo_info_rep *rep,
>>                                struct drm_buffer_object **bo_rep);
> 
> These all look sensible.
> 
> It's a pity that the change above looks like it will allow users of the 
> old argument order to continue to compile without error despite the 
> change.  It's a bit hard to know how to achieve that though.

Could a temporary/dummy parameter be added for a while?  Callers that 
weren't updated would get an error/warning about too few arguments. 
Then remove the dummy at some point in the future.

-Brian

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to