Re: [PATCH] drm/i915: Add a bit of locking to intel_dp_hpd_pulse()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>
> ->hpd_pulse() is called from a workqueue via an interrupt so it happens
> asynchronously with modesets. Grab the connection_mutex in
> intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with
> parallel hpd processing.

Nope, not right, we need to lock just not that amount of stuff, since MST
won't work anymore, since it relies on hpd irqs while other threads are
holding the locks to talk to the remote devices. I also think we shouldn't be
locking the the irq processing in intel_dp_check_link_status.

> On my IVB turning off the port during a modeset could result in a
> hpd which would then proceed to link train while the modeset was
> still happening. Suffice to say that didn't go so well.

Does this not point to an ordering issue somewhere, we've turned off the port,
but the device thinks the link should be trained but it currently isn't? maybe
intel_dp_check_link_status needs to be smarter about something
but we should be able to process the irqs fine without locking the modesetting
locks. Or maybe we need to know that we don't want the link trained so don't
retrain when the remote device signals a link status problem.

Daniel, the only way intel_dp->is_mst can get reset is inside this path.

Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux