[Intel-gfx] [Patch 5/5] multiple ring buffer support, fix a irq enable logic for BSD

[Zou, Nanhai]

Hi Eric,
	I found the reason, 
Although user interrupt in BSD ring and Render ring has different represent
bit in GTIMR, they should share 1 usr_irq_lock, 
otherwise race condition may happen when 2 requests from different rings were submitted at the same time.
I have change the patches and cleanup write space issue and retarget to latest 
drm-intel-next 

please review

Thanks
Zou Nan hai


>>-----Original Message-----
>>From: Anholt, Eric
>>Sent: 2010年4月20日 1:25
>>To: Zou, Nanhai; intel-gfx at lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [Patch 5/5] multiple ring buffer support, fix a irq
>>enable logic for BSD
>>
>>On Mon, 19 Apr 2010 09:34:42 +0800, "Zou, Nanhai" <nanhai.zou at intel.com> wrote:
>>> >>-----Original Message-----
>>> >>From: Anholt, Eric
>>> >>Sent: 2010年4月13日 2:29
>>> >>To: Zou, Nanhai; intel-gfx at lists.freedesktop.org
>>> >>Subject: Re: [Intel-gfx] [Patch 5/5] multiple ring buffer support, fix a
>>irq
>>> >>enable logic for BSD
>>> >>
>>> >>On Wed, 7 Apr 2010 14:28:39 +0800, "Zou, Nanhai" <nanhai.zou at intel.com>
>>wrote:
>>> >>> Fix the BSD ring related IRQ logic on Ironlake.
>>> >>> Without this patch, we sometimes see IRQ lost
>>> >>> When playing H.264 content.
>>> >>
>>> >>This patch looks crazy.  Why do we need to do this?  How did you come up
>>> >>with it?  What prevents races between IIR clear and IER or IMR enable (if
>>> >>that's what the IIR clear is about).
>>> >>
>>>
>>> Yes, it looks a little strange.
>>> However HW spec from VCG do says IIR should be cleared before enable and
>>disable interrupt.
>>> We thought this patch fixed the interrupt lost issue seen when playing movie.
>>But now we found it just make the issue much harder to reproduce, so ignore
>>this patch until we found a real fix.
>>
>>Before enable, sure, that makes sense -- otherwise you'd trigger an
>>interrupt right away when you know you don't need it.  But we do
>>unmasking, not enabling.