Greg KH wrote:
> On Wed, Aug 12, 2009 at 04:48:33PM -0700, Jesse Barnes wrote:
>
>> On Wed, 12 Aug 2009 16:24:58 -0700
>> Greg KH <g...@kroah.com> wrote:
>>
>>
>>> On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
>>>
>>>> On Wed, 12 Aug 2009 08:21:24 +0200
>>>> Thomas Hellström <tho...@shipmail.org> wrote:
>>>>
>>>>
>>>>> Jesse Barnes wrote:
>>>>>
>>>>>> On Tue, 11 Aug 2009 20:29:39 +0200
>>>>>> Thomas Hellström <tho...@shipmail.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>> 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.
>>>>>
>>> Don't use raw kobjects if at all possible please. Use a real struct
>>> device, it's much better in the long run for a wide variety of
>>> reasons, not the least being that you are dealing with virtual
>>> devices here.
>>>
>>>
>>>> Ah ok, so the approach you suggested sounds pretty good. The only
>>>> thing that comes to mind is whether other class devices do something
>>>> similar; i.e. maybe this code belongs in the device core instead.
>>>>
>>>> Greg? (See above for some background.)
>>>>
>>> I'm sorry, but I fail to see how this concerns the driver core.
>>> Perhaps I'm just slow this afternoon... Anyone want to explain it
>>> better?
>>>
>> So right now we have a DRM class device. The various DRM devices are
>> registered with it... and now that I think about it we should probably
>> just restructure things so that they each have their own suspend/resume
>> routines? I'm not sure how that interacts with the class device
>> though; will both the class device suspend/resume get called along with
>> each device?
>>
>
> Yes. They will be called first, like they should. Just like network
> devices are.
>
>
>> Thomas's thought was to identify each sub-device uniquely so we could
>> do the right thing in the class device suspend/resume routines, but it
>> seems like that wouldn't be necessary if moved things around a bit
>> more...
>>
>
> Yeah, it sounds like the infrastructure is all there for you already :)
>
I don't think we can do pm per device but we can do it per struct
device_type, so anyone wanting to customize a drm sysfs device can just
implement and point to a new struct device_type before registering it,
and, as pointed out in the mail to Kristian, we should probably make the
class methods noops.
/Thomas.
> thanks,
>
> greg k-h
>
------------------------------------------------------------------------------
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
