[Intel-gfx] [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia

[Andrew Lutomirski]

On Tue, May 25, 2010 at 10:46 AM, Adam Jackson <ajax at redhat.com> wrote:
> On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote:
>> On Mon, May 24, 2010 at 4:46 PM, Adam Jackson <ajax at redhat.com> wrote:
>> > Disable the CRT plug interrupt while doing the force cycle, explicitly
>> > clear any CRT interrupt we may have generated, and restore when done.
>> > Should mitigate interrupt storms from hotplug detection.
>> >
>>
>> Is there any locking in here to protect PORT_HOTPLUG_EN?  I'm asking
>> because I *still* can't use mainline kernels reliably without
>> commenting out digital output initialization, and that's one place
>> where a bug might be lurking.
>
> At least in d-i-n, PORT_HOTPLUG_EN is only ever written to from ->detect
> in the connector vtable, and from IRQ setup.  I don't have a firm
> understanding of the locking around either path, but I'd be rather
> surprised if it was racy in any practical sense, since neither of those
> should get called from interrupt context and you typically only have one
> app doing setup.

->detect seems to be called from status_show in drm_sysfs.c, which
makes its way into intel_crt_detect_hotplug, which plays with
PORT_HOTPLUG_EN without any locking.  If another detect function (or
the same one, even) is called at the same time, PORT_HOTPLUG_EN can be
left in a bad state.

There should probably be a mutex protecting PORT_HOTPLUG_EN.

--Andy

>
> - ajax
>