2009/8/13 Thomas Hellström <tho...@shipmail.org>:
> 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.
Yup, I think that's a great approach.
cheers,
Kristian
------------------------------------------------------------------------------
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
