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.
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.)
--
Jesse Barnes, Intel Open Source Technology Center
------------------------------------------------------------------------------
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
