[Intel-gfx] [PATCH] drm/i915 : Removed the unconditional cross engine/ring update of MBOX registers

[Gupta, Sourab]

On Tue, 2014-06-10 at 20:15 +0530, sourab gupta wrote:
> On Tue, 2014-06-10 at 07:24 +0000, Chris Wilson wrote:
> > On Tue, Jun 10, 2014 at 12:48:44PM +0530, sourab.gupta at intel.com wrote:
> > > From: Akash Goel <akash.goel at intel.com>
> > > 
> > > Removed the unconditional cross engine/ring update of MBOX registers.
> > > The MBox update will done only when needed when the actual inter ring
> > > dependency has been ascertained. Although this late sync could affect
> > > the Media performance slightly but it shall improve the residency time
> > > of individual power wells in C6 state.
> > 
> > NAK. Did you even consider the deadlocks above and beyond the issues with
> > latency? Maybe suggest that the hardware guys consider a reordering write
> > FIFO next time like elsewhere on the chip.
> > -Chris
> > 
> Hi Chris,
> We had thought about the deadlock scenarios between two rings but it
> didn't seem plausible. Below scenario was considered:
> Let us say Ring1 has to sync for obj1 which is being processed on Ring2.
> So it inserts Wait command on Ring1 and corresponding Signal command on
> Ring2.
> Now, Ring1 will be deadlocked only in the case when Ring2 is waiting for
> some obj2 to be processed on Ring1. That would mean that Ring2 would
> have inserted a corresponding signal command on Ring1. Now, this signal
> command for obj2 on Ring1 has to be has to be there before the wait
> command for obj1 on Ring1 (because wait/signal command pair is inserted
> together). So, Ring2 should go ahead to process the Signal command for
> obj1.
> 
> Are there any missing points in this scenario we considered? Or, some
> other scenario for deadlock?
> 
> Thanks,
> Sourab
> 
Hi Chris,

We're sorry to bother you but could you please point out to flaws here.
It would help us in understanding the missing scenarios for  deadlock
arising in this implementation w.r.t. the earlier one.

Thanks,
Sourab