public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: jaeyong.yoo@samsung.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: Question regarding forcewake in i915
Date: Tue, 06 Jan 2015 15:19:12 +0000	[thread overview]
Message-ID: <54ABFCF0.3020208@intel.com> (raw)
In-Reply-To: <507709752.66831419251184872.JavaMail.weblogic@epmlwas06a>

On 22/12/14 12:26, 유재용 wrote:
> Hello intel-gfx,
> 
> I'm reading i915 gpu drivers and find myself quite hard to understand
> about forcewake concepts.
> 
> I understand that it is something with the energy efficiency so related
> to ACPI. And it looks like forcewake is working as a pair (get and put).
> In the "get" part, what it first does it waiting on FORCEWAKE_ACK_HSW
> register (in case of haswell).
> And then, it writes something to FORCEWAKE_MT register, read from ECOBUS.
> And again, it waits on FORCEWAKE_ACK_HSW again!
> It becomes more confusing when it comes to put.
> In the "put" part, what it does it writing to FORCEWAKE_MT register and
> read from ECOBUS.
> 
> I tried to find some good reading materials about this forcewake, but
> what I found was a series of patches in this mailing list. (which are
> quite hard to follow from the begining)
> Could you explain about the concept of FORCEWAKE and possibly the magic
> tricks on these get and put?
> 
> Thanks,
> Jaeyong

Hi Jaeyong,

FORCEWAKE details vary a little from one chip to another, so this is
only a general description, but essentially setting one or more bits in
the FORCEWAKE register(s) prevents some or all of the power domains from
going into the deeper idle (sleep) states (and forces them out of the
sleep state if they're already asleep). Clearing the bit(s) allows the
affected parts to go to sleep again.

The FORCEWAKE_ACK register(s) contain one or more bits which reflect the
internal state, and so acknowledge that the most recent write to the
corresponding FORCEWAKE register has been accepted and acted upon. It
can take a while for a portion of the chip to wake up, so after setting
a FORCEWAKE bit we have to spin-wait until it's taken effect.

So, the general algorithm for accessing some part of the chip that may
be asleep is:
	1) set the relevant bit of (a) FORCEWAKE register
	2) poll (matching) FORCEWAKE_ACK until the write is acknowledged
	3) access the chip (this can encompass several reads and writes)
	4) clear the FORCEWAKE bit that we set earlier
	5) poll FORCEWAKE_ACK again until this write is acknowledged

Now for extra confusion, there are a few more details:
	* because reads and writes can in some cases be reordered, we
	  need to force the write to FORCEWAKE to complete before the
	  busy-polling of FORCEWAKE_ACK. This is the sole purpose of the
	  read of the ECOBUS register, which is used just because it
	  happens to lie in the same cacheline as FORCEWAKE.

	* we can choose not to poll for FORCEWAKE_ACK clear in step (5).
          Instead, we can just leave the chip to go back to sleep while
	  we get on with other things. But in that case, we might come
	  back and try to wake the chip again before it's finished
	  responding to the write in step (4). So if we don't poll at
	  the end of the sequence, we have to poll at the beginning
	  instead; in other words, move step (5) to before step (1).

IIRC, gen6 had a single FORCEWAKE register containing a single effective
bit, gen7 has a single register containing multiple bits (so that they
can be controlled by different agents) which are OR-ed together to
produce a combined wakeup signal (this also applies to HSW, although the
FORCEWAKE_ACK is in a different place from earlier chips); and VLV has
multiple registers for different power domains (e.g. MEDIA vs RENDER).

Hope this helps!
Dave
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-01-06 15:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 12:26 Question regarding forcewake in i915 유재용
2015-01-06 15:19 ` Dave Gordon [this message]
2015-01-07  8:13   ` Jaeyong Yoo
2015-01-12 17:47     ` Dave Gordon
2015-01-15  7:38       ` Debugging registers (INSTPS, CSCMDOP, CSCMDVLD, ...) Jaeyong Yoo
2015-01-19 12:52         ` Dave Gordon
2015-01-19 13:31         ` Dave Gordon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54ABFCF0.3020208@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jaeyong.yoo@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox