[Intel-gfx] [PATCH v2 00/18] *** Command submission via GuC for SKL ***
yu.dai at intel.com
yu.dai at intel.com
Fri Apr 3 11:08:26 PDT 2015
From: Alex Dai <yu.dai at intel.com>
v2:
1. Add kernel-doc patch. All comments here have been moved into source code.
2. Change the way to load fw because a signed firmware has different layout.
3. One previous patch to notify GuC about RC6 feature is dropped for future
submission. Need to double check the potential racing condition.
v1: This series of patch is to enable ExecList submission via GuC. Here are
some key points related to this series, not in particular order.
*** i915_guc_client ***
We use the term client to avoid confusion with contexts. A i915_guc_client is
equivalent to GuC object guc_context_desc. This context descriptor is allocated
from a pool of 1024 entries. Kernel driver will allocate doorbell and workqueue
for it. Also the process descriptor (guc_process_desc), which is mapped to
client space. So the client can write Work Item then ring the doorbell.
To simplify the implementation, we allocate one gem object that contains all
pages for doorbell, process descriptor and workqueue.
*** intel_guc ***
Top level structure of guc. It handles firmware loading and manages client pool
and doorbells. intel_guc owns a i915_guc_client to do the legacy submission.
** The Scratch registers ***
There are 16 MMIO-based registers start from 0xC180. The kernel driver writes a
value to the action register (SOFT_SCRATCH_0) along with any data. It then
triggers an interrupt on the GuC via another register write (0xC4C8). Firmware
writes a success/fail code back to the action register after processes the
request. The kernel driver polls waiting for this update and then proceeds.
Details in intel_guc_action()
*** Work Items ***
There are several types of work items that the host may place into a workqueue,
each with its own requirements and limitations. Currently only WQ_TYPE_INORDER
is used to support legacy submission via GuC, which represents in-order queue.
The kernel driver packs ring tail pointer and an ELSP context descriptor dword
into Work Item.
Details in add_workqueue_item()
*** Doorbells ***
Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
mapped into process space.
Details in ring_doorbell()
*** Firmware versioning ***
The firmware build process will generate a version header file with major and
minor version defined. The versions are built into CSS header of firmware too.
i915 kernel driver set the minimal firmware version required by each platform.
The firmware installation package will install (symbolic link) proper version
of firmware.
*** Firmware log ***
Firmware log is enabled by setting i915.guc_log_level to non-negative level.
Log data is printed out via reading debugfs i915_guc_log_dump. Reading from
i915_guc_load_status will print out firmware loading status and scratch
registers value.
TODO: the buffer works like a ring. To not missing any data, driver should
handle a GuC2Host interrupt (triggered when log buffer is half full) from GuC.
*** Ring buffer size ***
It is up to 16K (4 pages) per LRC. Not HW limitation but firmware is setup in
this way.
*** GuC address space ***
GuC is not expecting any gfx GGTT address that falls into range [0, WOPCM_TOP),
which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address is
512K in order to fit in big HuC firmware.
In order to exclude 0-512K address space from GGTT, all gfx objects used by GuC
is pinned with PIN_OFFSET_BIAS along with size of WOPCM.
Alex Dai (13):
drm/i915: Add guc firmware interface headers
drm/i915: GuC firmware loader
drm/i915: Add firmware version check
drm/i915: Make several execlist helper functions external
drm/i915: Add functions to allocate / release gem obj for GuC
drm/i915: Functions to support command submission via GuC
drm/i915: Integration of GuC client
drm/i915: Interrupt routing for GuC scheduler
drm/i915: Enable commands submission via GuC
drm/i915: debugfs of GuC status
drm/i915: Enable GuC firmware log
drm/i915: Ring Context allocating for GuC
Documentation/drm: kerneldoc for GuC
Dave Gordon (2):
drm/i915: Unified firmware loading mechanism
drm/i915: Defer default hardware context initialisation until first
open
Michael H. Nguyen (2):
drm/i915: Add i915_gem_object_write() to i915_gem.c
drm/i915: Move execlists defines from .c to .h
Sagar Kamble (1):
drm/i915: Taking forcewake during GuC load.
Documentation/DocBook/drm.tmpl | 19 +
drivers/gpu/drm/i915/Makefile | 8 +-
drivers/gpu/drm/i915/i915_debugfs.c | 102 +++++
drivers/gpu/drm/i915/i915_dma.c | 6 +
drivers/gpu/drm/i915/i915_drv.h | 17 +
drivers/gpu/drm/i915/i915_gem.c | 39 +-
drivers/gpu/drm/i915/i915_gem_context.c | 35 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 10 +
drivers/gpu/drm/i915/i915_params.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 83 +++-
drivers/gpu/drm/i915/intel_guc.h | 192 +++++++++
drivers/gpu/drm/i915/intel_guc_api.h | 217 ++++++++++
drivers/gpu/drm/i915/intel_guc_client.c | 645 +++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_guc_loader.c | 537 ++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_guc_scheduler.c | 164 ++++++++
drivers/gpu/drm/i915/intel_lrc.c | 112 ++---
drivers/gpu/drm/i915/intel_lrc.h | 3 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_uc_loader.c | 247 +++++++++++
drivers/gpu/drm/i915/intel_uc_loader.h | 82 ++++
20 files changed, 2432 insertions(+), 97 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_api.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_client.c
create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
create mode 100644 drivers/gpu/drm/i915/intel_guc_scheduler.c
create mode 100644 drivers/gpu/drm/i915/intel_uc_loader.c
create mode 100644 drivers/gpu/drm/i915/intel_uc_loader.h
--
1.9.1
More information about the Intel-gfx
mailing list