Re: drm sysfs questions

[Thomas H. <th...@sh...>]

Jesse Barnes wrote:
> On Tue, 11 Aug 2009 20:29:39 +0200
> Thomas Hellström <th...@sh...> wrote:
>
>   
>> Jesse Barnes wrote:
>>     
>>> On Tue, 11 Aug 2009 11:23:09 +0200
>>> Thomas Hellström <th...@sh...> wrote:
>>>
>>>   
>>>       
>>>> Hi!
>>>>
>>>> I'm wondering why we are using a struct device as a sysfs
>>>> representation for connectors instead of a struct kobject?
>>>>
>>>> In particular, what stops the drm_sysfs_[suspend|resume] functions
>>>> to get called for the connectors, having them cast to a struct
>>>> drm_minor and sending the cpu to the bushes?
>>>>     
>>>>         
>>> Hm, maybe we're just getting lucky that the drm minor check fails
>>> for everything but the DRM core device.  
>>>       
>> Yes, I think that's actually the case.
>>     
>>> kobjects might make sense to move
>>> to, unless we can think of other things we'd like to do with a full
>>> device (e.g. runtime power management or some sort of per-connector
>>> suspend/resume).
>>>   
>>>       
>> I can't really think of a case where the device owning the connector 
>> can't handle this?
>> But we'd lose the /sys/drm/xxx symlinks to the connectors, and if
>> that does matter, we'd need to recreate those manually.
>>
>> Anyway, I'd also like to be able to add a virtual ttm device to the
>> drm sysfs hierarchy, the purpose of which would be to do the right
>> thing with uncached / write-combined pages at suspend. The virtual
>> device won't be wrapped in a drm minor so I'm wondering wether we
>> could wrap the struct device like so:
>>
>> struct drm_sysfs_device {
>>     enum drm_sysfs_device_type type;
>>     struct device kdev;
>> }
>>
>> This way the drm sysfs suspend / resume hooks can check the type of
>> the structure embedding the struct device and only call the driver
>> hooks for the relevand device types.
>>     
>
> Yeah, that could work, but it seems like an explicit callout from
> drivers using TTM (or a callout from the core drm suspend/resume
> routines conditional on a DRIVER_HAS_TTM check) would be a bit
> simpler.  Or did you have other TTM info you wanted to expose sysfs as
> well?
>
>   
TTM nowadays is a set of optional subsystems rather than a complete set 
of features, so DRIVER_HAS_TTM can really mean a lot of things.

The idea is to have a ttm subdir (representing the TTM virtual device) 
and in that sysfs directory, other TTM subsystems can register kobjects 
with various attributes. For example the memory accounting subsystem 
with settable / readable limits and readable status, but that will be 
code internal to TTM.

/Thomas