Re: [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia

From: Adam Jackson <ajax@redhat.com>
To: Andrew Lutomirski <luto@mit.edu>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/gen4: Extra CRT hotplug paranoia
Date: Tue, 25 May 2010 10:46:32 -0400	[thread overview]
Message-ID: <1274798792.25350.20913.camel@atropine.boston.devel.redhat.com> (raw)
In-Reply-To: <AANLkTimjdprsSmpz6OaF0PtIsSckmrQ_krpUDVFyLUUc@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 983 bytes --]

On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote:
> On Mon, May 24, 2010 at 4:46 PM, Adam Jackson <ajax@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.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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