[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

yes you are absolutely correct and the change I have done in other area i.e
drivers/usb/storage/uas.c.In gpu drivers assert_spin_locked() make
more sense.

Regards
Sanjeev Sharma


On Tue, Aug 12, 2014 at 12:25 PM, Daniel Vetter <daniel at ffwll.ch> wrote:

> On Mon, Aug 11, 2014 at 04:38:50PM -0700, David Rientjes wrote:
> > On Mon, 11 Aug 2014, Rob Clark wrote:
> >
> > > > I'm suggesting that if you don't want to incur the cost of the
> conditional
> > > > everytime you call a certain function with assert_spin_locked() that
> you
> > > > could covert these to lockdep_assert_held() so the check is only
> done when
> > > > lockdep is enabled for debugging.
> > >
> > > not sure about the nouveau parts, but for the omap and msm hunks, this
> > > code getting called at potentially vblank rate (so maybe once or twice
> > > per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> > > so I don't always have it enabled.  So it sounds like for those two at
> > > least assert_spin_locked() is a better option.
> > >
> >
> > Unless there's a bug, assert_spin_locked() is just going to incur an
> > unnecessary cost every time it is called at runtime.  My suggestion was
> to
> > limit that check only to debugging kernels that include enabling lockdep
> > when tracking down problems rather than needlessly evaluating the
> > conditional every time when there are no bugs.
>
> My experience with gpu drivers (i915) has been that hw and the software
> running it is varied enough that almost always it's better to
> unconditionally enable this stuff. I much prefer assert_spin_locked and
> friends over the lockdep versions since enabling full lockdep is not
> something you usually do. Especially not normal users, and we rely upon
> them for testing the old stuff. Furthermore for the modeset code the
> overhead is totally irrelevant since we're doing metric piles of register
> reads and writes in there anyway.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140812/55b29765/attachment.html>