Jesse Barnes wrote:
> On Tue, 11 Aug 2009 11:23:09 +0200
> Thomas Hellström <tho...@shipmail.org> 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.

/Thomas











------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to