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 :)
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
