[Intel-gfx] [PATCH] drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI

[Daniel Vetter]

On Mon, Jul 29, 2013 at 03:50:14PM +0100, Chris Wilson wrote:
> On Mon, Jul 29, 2013 at 04:20:28PM +0300, Jani Nikula wrote:
> > On Fri, 26 Jul 2013, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > Otherwise we get flooded by the kernel warning us that we are doing
> > > long sequences of IO without serialisation. For example,
> > >
> > >  WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef()
> > >  Modules linked in:
> > >  CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G        W    3.11.0-rc2+ #4
> > >  Call Trace:
> > >   [<c2028564>] ?  warn_slowpath_common+0x63/0x78
> > >   [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
> > >   [<c20285dd>] ?  warn_slowpath_null+0xf/0x13
> > >   [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
> > >   [<c227b060>] ?  vlv_dpio_write+0x1c/0x21
> > >   [<c2262b3b>] ?  intel_dp_set_signal_levels+0x24a/0x385
> > >   [<c2264909>] ?  intel_dp_complete_link_train+0x25/0x1d1
> > >   [<c2264c55>] ?  intel_dp_check_link_status+0xf7/0x106
> > >   [<c2238ced>] ?  i915_hotplug_work_func+0x17b/0x221
> > >   [<c203a204>] ?  process_one_work+0x12e/0x210
> > >   [<c203a5e4>] ?  worker_thread+0x116/0x1ad
> > >   [<c203a4ce>] ?  rescuer_thread+0x1cb/0x1cb
> > >   [<c203d8f5>] ?  kthread+0x67/0x6c
> > >   [<c2457ebb>] ?  ret_from_kernel_thread+0x1b/0x30
> > >   [<c203d88e>] ?  init_completion+0x18/0x18
> > >
> > > v2: Retire the locking in vlv_crtc_enable() and do it close to the
> > > meat.
> > 
> > Grumble about throwing the fix and the refactoring together for no real
> > reason, and having a slightly misleading subject. But since we have the
> > warnings in place, the patch is small, and the end result is what we
> > want, I'll let it pass. Just this once. ;)
> 
> Meh, easier than working which paths were covered by the current locking
> scheme and which weren't - which I suppect conflict anyway. The
> intention was just to do as the subject said, but then I had to fix the
> deadlock presented by the patch...

Queued for -next, thanks for the patch. And I agree that in this case
splitting stuff further is just more awkward ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch