Kristian Høgsberg wrote:
> 2009/8/11 Thomas Hellström <tho...@shipmail.org>:
>
>> 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.
>>
>
> There is already a struct device_type mechanism for different types of
> devices under a subsystem. I'm pretty sure that would be the rigth
> thing to use, also for the connector devices.
The device_type methods are called in addition to the class methods.
This means we either have to a) stop the class methods from doing
anything or have them distinguish between device types like in the patch
I just posted.
So if we ditch the class suspend / resume and instead set up a struct
device_type for the "minor" devices to execute the suspend / resume
hooks we'd be fine. I can respin the patch to do that.
FWIW I was planning to use the struct device_type for TTM to implement
the new suspend / resume infrastructure, since when we get the legacy
suspend call it's already too late to evict VRAM buffers.
/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
