[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 <deepa...@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:ch...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx