From: Daniel Vetter <daniel@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/5] DRM device-alloc cleanup
Date: Wed, 9 Oct 2013 10:05:07 +0200 [thread overview]
Message-ID: <20131009080507.GL8303@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9tzd7_UHPQ8d_RE3+Jc+-qAUT-oXFM+iMEK3FmGjiKZ_mA@mail.gmail.com>
On Wed, Oct 09, 2013 at 04:00:00PM +1000, Dave Airlie wrote:
> On Wed, Oct 9, 2013 at 3:31 PM, Dave Airlie <airlied@gmail.com> wrote:
> > On Wed, Oct 2, 2013 at 7:23 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> >> Hi
> >>
> >> This cleans up the bus drivers in DRM. Instead of copying the device alloc/free
> >> semantics into each bus driver (drm_{pci,platform,usb}.c) we now have a central
> >> place in drm_stub.c.
> >>
> >> This introduces drm_dev_{alloc,free,register,unregister}(). They have the same
> >> semantics as most other kernel subsystems. *_alloc() allocates a new device and
> >> populates the static fields and sub-objects. *_free() frees an unregistered
> >> object allocated via *_alloc(). *_register() registers a DRM device and
> >> *_unregister() obviously unregisters a DRM device. A *_free() is still needed
> >> after calling *_unregister() (same as for "struct device"). No ref-counting is
> >> added as it is not required by any driver.
> >>
> >> Note that the bus drivers are modified to use the new helpers directly. However,
> >> I didn't modify the drivers to use *_unregister() and *_free() directly.
> >> Instead, the drm_put_dev() helper was modified to use these. Reason for that is
> >> that I have pending patches to make device hotplugging safer regarding mmaps.
> >> But these aren't ready, yet. Hopefully I can get them ready for rc5 or rc6.
> >>
> >> Tested on nouveau.
> >>
> >
> > Okay I've merged this series, a follow-on to fix the AGP bits like
> > Daniel suggested would be good.
>
> Actually this oopses i915 on startup, I fixed up the lack of passing
> flags into drm_dev_register,
> so it can be passed to load, and it seems to work now, I've squashed
> my fix into the series in my tree
>
> please read/review the series for your learning pleasure.
Oops, shame on me for failing to spot the unconditional 0 passed for
flags. i915.ko really doesn't like that ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2013-10-09 8:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 9:23 [PATCH 0/5] DRM device-alloc cleanup David Herrmann
2013-10-02 9:23 ` [PATCH 1/5] drm: add drm_dev_alloc() helper David Herrmann
2013-10-02 9:23 ` [PATCH 2/5] drm: merge device setup into drm_dev_register() David Herrmann
2013-10-03 13:15 ` Daniel Vetter
2013-10-03 13:19 ` David Herrmann
2013-10-03 13:21 ` Daniel Vetter
2013-10-02 9:23 ` [PATCH 3/5] drm: move drm_lastclose() to drm_fops.c David Herrmann
2013-10-02 9:23 ` [PATCH 4/5] drm: introduce drm_dev_free() to fix error paths David Herrmann
2013-10-02 9:23 ` [PATCH 5/5] drm: move device unregistration into drm_dev_unregister() David Herrmann
2013-10-03 13:18 ` Daniel Vetter
2013-10-09 5:31 ` [PATCH 0/5] DRM device-alloc cleanup Dave Airlie
2013-10-09 6:00 ` Dave Airlie
2013-10-09 8:05 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131009080507.GL8303@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.