[Intel-gfx] [PATCH v2] drm/i915/vlv: Update Wait for FIFO and wait for 20 free entries. v2

[Daniel Vetter]

[Dragging the discussion back to the public.]

I agree that the 20 fifo limit is fairly arbitrary and it's still
racy. Otoh that seems to be a bit that the hw engineers simply
fumbled, so I guess we don't have much choice here.

I've only merged the patch to dinq since there's no real report of
this fixing anything and we have a bit of time to figure out something
better. If there is such a thing even.

Deepak, can you please poke hw engineers a bit how they've thought the
driver should run this exactly?

Thanks, Daniel

On Wed, Dec 4, 2013 at 10:48 AM, S, Deepak <deepak.s at intel.com> wrote:
> Agreed. But if we don't have a threshold,  we might hit a high probability of dropping writes if HW or SW uses all 64 entries right?.
>
> Can we create a wq and check for the fifo entries at a periodic interval, this will reduce the  fifo checking before every mmio write.
>
> Thank
> Deepak S
>
> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Wednesday, December 4, 2013 3:04 PM
> To: S, Deepak
> Cc: Daniel Vetter
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/vlv: Update Wait for FIFO and wait for 20 free entries. v2
>
> On Tue, Dec 03, 2013 at 04:05:07PM +0000, S, Deepak wrote:
>> Hi Daniel/Chris,
>>
>> I spent some time in digging through the specs and also has chatted with couple of people. Below is my understanding of the FIFO.
>>
>> "On SB, Out of 64 FIFO Entries, 20 Entries will be used by HW and remaining 44 will be used by the SW,. I think due to this reason, we have a threshold of 20 Entries."
>>
>> "On VLV, HW and SW can access all 64 fifo entries, I don't think having a threshold of 20 Entries is mandatory on VLV. Also, since both SW and HW can access all 64 Entries. I think on VLV, we need to update the fifo_count before waiting for the FIFO."
>
> But there is also no point in waiting for at least 20 entries either. So the current code does not make sense for VLV in that light. Also note that the code is currently like it is as the mmio read before every write adds significant CPU overhead.  There is also the problem that if the hw can consume the entire FIFO, it can also do so between us checking for a free entry and use performing the mmio. It seems to be broken by design...
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch