Re: [PATCH 2/3] drm/i915: Do only one posting read on forcewake put sequence

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 28, 2015 at 03:28:56PM +0200, Mika Kuoppala wrote:
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> 
> > On Wed, Jan 28, 2015 at 02:43:25PM +0200, Mika Kuoppala wrote:
> >> commit 05a2fb157e44a53c79133805d30eaada43911941
> >> Author: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> >> Date:   Mon Jan 19 16:20:43 2015 +0200
> >> 
> >>     drm/i915: Consolidate forcewake code
> >> 
> >> introduced domain handling where each domain has it's own posting
> >> read registers. This changed the forcewake sequence on 'put' side when
> >> there is multiple domains as there would be extra read between the domain
> >> puts. Any posting read should be enough to flush all the changes.
> >> 
> >> Do a posting read only once, at the end of the sequence and for
> >> the first domain. Like it was before.
> >> 
> >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> >> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx>
> >
> > fwiw, I would argue that the posting read in _get() is superfluous as we
> > will serialise the fw with not only the ack, but any subsequent mmio.
> >
> > On the _put() side we do want to flush the write so that the hw can
> > power down as early as possible. So just kill the posting read from _get
> > and otherwise drop the patch. :)
> 
> Yes, both put/get patches should be dropped. I posted a patch removing
> the posting read on get side and with your explanations in commit message.
> 
> This all starts to make so much sense that some gen is bound to break ;)

IIRC the posting read from same cache line actually fixed real bugs. So
I'm a bit worried about dropping them. But I suppose it's possible only
the _put side was important for those bugs.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux