On Thu, Mar 26, 2015 at 12:41:07PM -0700, yu.dai@xxxxxxxxx wrote: > From: Alex Dai <yu.dai@xxxxxxxxx> > > 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. There's lots of great comments both in the code and overview text in this coverletter here, but no kerneldoc. Can you please create a patch on top to document the new guc stuff in an overview section and also document the non-static functions you're adding? Thanks, Daniel > > 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 > drm/i915: Notify GuC when RC6 state is changed > > 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. > > 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 | 186 +++++++++ > drivers/gpu/drm/i915/intel_guc_api.h | 218 +++++++++++ > drivers/gpu/drm/i915/intel_guc_client.c | 607 +++++++++++++++++++++++++++++ > drivers/gpu/drm/i915/intel_guc_loader.c | 466 ++++++++++++++++++++++ > drivers/gpu/drm/i915/intel_guc_scheduler.c | 167 ++++++++ > drivers/gpu/drm/i915/intel_lrc.c | 112 ++---- > drivers/gpu/drm/i915/intel_lrc.h | 3 + > drivers/gpu/drm/i915/intel_pm.c | 4 + > drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- > drivers/gpu/drm/i915/intel_uc_loader.c | 220 +++++++++++ > drivers/gpu/drm/i915/intel_uc_loader.h | 82 ++++ > 20 files changed, 2279 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 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
