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?
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
