Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 10月, 2016 3 次提交
    • S
      drm/i915: Support for GuC interrupts · 26705e20
      由 Sagar Arun Kamble 提交于 
      There are certain types of interrupts which Host can receive from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to receive interrupts from GuC but currently
enables & partially handles only the interrupt sent by GuC ukernel.
Future patches will add support for handling other interrupt types.

v2:
- Use common low level routines for PM IER/IIR programming (Chris)
- Rename interrupt functions to gen9_xxx from gen8_xxx (Chris)
- Replace disabling of wake ref asserts with rpm get/put (Chris)

v3:
- Update comments for more clarity. (Tvrtko)
- Remove the masking of GuC interrupt, which was kept masked till the
  start of bottom half, its not really needed as there is only a
  single instance of work item & wq is ordered. (Tvrtko)

v4:
- Rebase.
- Rename guc_events to pm_guc_events so as to be indicative of the
  register/control block it is associated with. (Chris)
- Add handling for back to back log buffer flush interrupts.

v5:
- Move the read & clearing of register, containing Guc2Host message
  bits, outside the irq spinlock. (Tvrtko)

v6:
- Move the log buffer flush interrupt related stuff to the following
  patch so as to do only generic bits in this patch. (Tvrtko)
- Rebase.

v7:
- Remove the interrupts_enabled check from gen9_guc_irq_handler, want to
  process that last interrupt also before disabling the interrupt, sync
  against the work queued by irq handler will be done by caller disabling
  the interrupt.
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      26705e20
    • A
      drm/i915: New structure to contain GuC logging related fields · d6b40b4b
      由 Akash Goel 提交于 
      So far there were 2 fields related to GuC logs in 'intel_guc' structure.
For the support of capturing GuC logs & storing them in a local buffer,
multiple new fields would have to be added. This warrants a separate
structure to contain the fields related to GuC logging state.
Added a new structure 'intel_guc_log' and instance of it inside
'intel_guc' structure.

v2: Rebase.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      d6b40b4b
    • S
      drm/i915: Decouple GuC log setup from verbosity parameter · b1e37103
      由 Sagar Arun Kamble 提交于 
      GuC Log buffer allocation was tied up with verbosity level module param
i915.guc_log_level. User would be given a provision to enable firmware
logging at runtime, through a host2guc action, and not necessarily during
Driver load time. But the address of log buffer can be passed only in
init params, at firmware load time, so GuC has to be reset and firmware
needs to be reloaded to pass the log buffer address at runtime.
To avoid reset of GuC & reload of firmware, allocation of log buffer will
be done always but logging would be enabled initially on GuC side based on
the value of module parameter guc_log_level.

v2: Update commit message to describe the constraint with allocation of
    log buffer at runtime. (Tvrtko)

v3: Rebase.
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      b1e37103
  3. 18 10月, 2016 1 次提交
  5. 14 10月, 2016 5 次提交
  7. 27 9月, 2016 1 次提交
  9. 26 9月, 2016 2 次提交
  11. 15 9月, 2016 2 次提交
  13. 05 9月, 2016 1 次提交
  15. 22 8月, 2016 1 次提交
  17. 15 8月, 2016 3 次提交
  19. 11 8月, 2016 1 次提交
  21. 05 8月, 2016 1 次提交
  23. 21 7月, 2016 1 次提交
  25. 20 7月, 2016 1 次提交
  27. 05 7月, 2016 1 次提交
  29. 04 7月, 2016 3 次提交
  31. 27 6月, 2016 1 次提交
    • D
      drm/i915/guc: don't ever forward VBlank to the GuC · fa7545a4
      由 Dave Gordon 提交于 
      If a context waiting for VBlank were switched out, switching
in the next context and generating a CSB event in the process,
then the GuC would have to put the context back in the queue,
and then observe the subsequent VBlank interrupt so that it
could resubmit the suspended context.

However, we always set the CTX_CTRL_INHIBIT_SYN_CTX_SWITCH bit
in the RING_CONTEXT_CONTROL register, so this case cannot occur.
Furthermore we don't use the GuC's internal scheduler or allow
it to auto-resubmit workloads.  Consequently, the GuC doesn't
need to see VBlanks, and by sending them to it we may be waking
it up unnecessarily, which might reduce RC6 residency and
increase power consumption.

So this patch removes the setting of the GFC_FORWARD_VBLANK
field from the code that diverts interrupts towards the GuC.
(The code to direct interrupts to the host, OTOH, continues to
explicitly set the field to "never send VBlanks to the GuC".)

v3:
    Remove the line of code completely (original set the field
    to ALWAYS forward, v1 changed it to CONDITIONAL forwarding,
    v2 explicitly set it to NEVER, v3 just doesn't touch it at
    all, as we know it's already set to NEVER).
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (previous version)
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466780277-23435-1-git-send-email-david.s.gordon@intel.com
      fa7545a4
  33. 13 6月, 2016 2 次提交
  35. 07 6月, 2016 2 次提交
  37. 01 6月, 2016 1 次提交
  39. 23 5月, 2016 2 次提交
    • D
      drm/i915/guc: add enable_guc_loading parameter · fce91f22
      由 Dave Gordon 提交于 
      Split the function of "enable_guc_submission" into two separate
options.  The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default)     whatever the platform default is
 0  DISABLE      don't load/use the GuC
 1  BEST EFFORT  try to load/use the GuC, fallback if not available
 2  REQUIRE      must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.

v4:
    Changed some error-message levels, mostly ERROR->INFO, per
    review comments by Tvrtko Ursulin.

v5:
    Dropped one more error message, disabled GuC submission on
    hypothetical firmware-free devices [Tvrtko Ursulin].

v6:
    Logging tidy by Tvrtko Ursulin:
     * Do not log falling back to execlists when wedging the GPU.
     * Do not log fw load errors when load was disabled by user.
     * Pass down some error code from fw load for log message to
       make more sense.
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Tested-by: NFiedorowicz, Lukasz <lukasz.fiedorowicz@intel.com>
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> (v6)
      fce91f22
    • D
      drm/i915/guc: rename loader entry points · f09d675f
      由 Dave Gordon 提交于 
      The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      f09d675f
  41. 18 5月, 2016 1 次提交
  43. 12 5月, 2016 2 次提交
  45. 05 4月, 2016 2 次提交
    • D
      drm/i915/guc: always reset GuC before loading firmware · d761701c
      由 Dave Gordon 提交于 
      After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loaded the GuC with
firmware, which will then cause this kernel's attempt to (re)load the
firmware to fail (GuC program memory is write-once!). The symptoms
(GuC firmware reload fails after hibernation) are further described
in the Bugzilla reference below.

So let's *always* reset the GuC just before (re)loading the firmware;
the hardware should then be in a well-known state, and we may even
avoid some of the issues arising from unpredictable timing.

Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Cc: Alex Dai <yu.dai@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94390Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      d761701c
    • A
      drm/i915/guc: reset GuC and retry on firmware load failure · 6b332fa2
      由 Arun Siluvery 提交于 
      Due to timing issues in the HW, some of the status bits required for GuC
authentication occasionally don't get set; when that happens, the GuC
cannot be initialized and we will be left with a wedged GPU. The W/A
suggested is to perform a soft reset of the GuC and attempt to reload
the F/W again for few times before giving up.

As the failure is dependent on timing, tests performed by triggering
manual full gpu reset (i915_wedged) showed that we could sometimes hit
this after several thousand iterations, but sometimes tests ran even
longer without any issues. Reset and reload mechanism proved helpful
when we indeed hit f/w load failure, so it is better to include this
to improve driver stability.

This change implements the following WAs,

	WaEnableuKernelHeaderValidFix:skl,bxt
	WaEnableGuCBootHashCheckNotSet:skl,bxt
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Reviewed-by: NAlex Dai <yu.dai@intel.com>
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      6b332fa2